DevSecOps et certification FPGA en aéronautique
trait de séparation
Temps de lecture : 7-9 minutes - Juin 2026
La cybersécurité est devenue un enjeu central pour les systèmes aéronautiques critiques. Avec l’introduction de la norme ED‑203A, les autorités exigent désormais que les risques cyber soient maîtrisés dès la conception, au même titre que la sûreté de fonctionnement.
Dans ce contexte, les composants FPGA occupent une place stratégique : utilisés pour des fonctions sensibles (chiffrement, filtrage, communication, interfaces critiques), ils reposent sur du code HDL (VHDL/Verilog) qui peut contenir des vulnérabilités exploitables. Or, les approches traditionnelles issues de la norme DO‑254 se concentrent essentiellement sur la sûreté, sans adresser explicitement les menaces cyber.
L’article de référence montre qu’une approche DevSecOps adaptée au hardware, combinée à l’analyse statique et aux méthodes formelles, permet de répondre efficacement aux exigences ED‑203A tout en améliorant la qualité globale des conceptions FPGA.
Les limites des approches traditionnelles DO 254 face aux risques cyber
La norme DO‑254 fournit un cadre robuste pour démontrer la sûreté de fonctionnement des composants matériels complexes. Cependant, elle ne couvre pas explicitement les scénarios de cyberattaques ciblant le comportement logique interne des FPGA.
Parmi les risques identifiés dans l’article :
D’où la nécessité d’une approche complémentaire, orientée cybersécurité, intégrée dès les premières phases de conception.
Parmi les risques identifiés dans l’article :
- Accès mémoire ou vecteurs hors limites pouvant mener à des corruptions ou exécutions non maîtrisées
- États non atteignables ou branches de code mortes pouvant masquer des erreurs ou backdoors
- Machines à états présentant des dead states, livelocks ou comportements ambigus
- Violations de règles de codage sécuritaires (initialisation, gestion des transitions, signaux combinatoires critiques)
D’où la nécessité d’une approche complémentaire, orientée cybersécurité, intégrée dès les premières phases de conception.
Intégrer la cybersécurité FPGA avec une approche DevSecOps conforme ED 203A
Pour répondre aux objectifs de l’ED‑203A, l’article propose une méthodologie innovante fondée sur trois piliers complémentaires :
Secure by Design grâce au DevSecOps
Revues indépendantes et traçables
Traçabilité et preuves pour les audits
Secure by Design grâce au DevSecOps
- Détection continue des vulnérabilités dès l’écriture du code HDL
- Intégration native de la sécurité dans le flow de conception FPGA
- Automatisation des contrôles à chaque modification (CI/CD matériel)
Revues indépendantes et traçables
- Utilisation systématique des Pull/Merge Requests
- Revues indépendantes exigées par les normes de certification
- Conservation des preuves de conformité (checklists, corrections, validations)
Traçabilité et preuves pour les audits
- Lien direct entre règles de sécurité, code, analyses et résultats
- Génération automatique d’évidences exploitables lors des audits ED‑203A (EASA, DGA)
Linty : sécuriser et certifier les FPGA par l’analyse statique et les méthodes formelles
Linty, un outil au cœur de l’approche
Linty est un outil d’analyse statique avancée dédié au code VHDL, conçu pour les environnements critiques. Intégré directement dans l’environnement de développement (ex. VS Code), il permet une détection en temps réel de vulnérabilités matérielles.
Détection automatisée des failles HDL
Linty identifie notamment :
Vulgarisation et automatisation des méthodes formelles
Un apport clé de Linty est de rendre les méthodes formelles accessibles aux designers FPGA :
Résultat : des preuves mathématiques robustes, intégrées naturellement dans le flow DevSecOps.
Linty est un outil d’analyse statique avancée dédié au code VHDL, conçu pour les environnements critiques. Intégré directement dans l’environnement de développement (ex. VS Code), il permet une détection en temps réel de vulnérabilités matérielles.
Détection automatisée des failles HDL
Linty identifie notamment :
- Accès mémoire ou index hors limites
- Ports non connectés, constants ou non registrés
- Code mort, branches inaccessibles, comportements suspects
- Violations des règles de codage sécuritaires
Vulgarisation et automatisation des méthodes formelles
Un apport clé de Linty est de rendre les méthodes formelles accessibles aux designers FPGA :
- Génération automatique d’assertions mathématiques
- Preuve d’absence de vulnérabilités critiques (ex. débordements, FSM incorrectes)
- Détection formelle de dead states, unreachable states, livelocks, états redondants
Résultat : des preuves mathématiques robustes, intégrées naturellement dans le flow DevSecOps.
Bénéfices industriels et retour d’expérience : vers une certification accélérée
L’application concrète de cette approche, notamment sur le projet CNES – Athena X‑IFU, a permis :
- Une réduction drastique des défauts résiduels dans le code VHDL
- Une détection très précoce de vulnérabilités cyber
- Une accélération des cycles de validation, vérification et certification (jusqu’à +300 %)
- Une meilleure continuité entre DO‑254 (sûreté) et ED‑203A (cyber)
Cette approche démontre qu’il est possible de concilier exigences réglementaires, cybersécurité et agilité dans la conception de composants FPGA critiques, en s’appuyant sur une approche DevSecOps outillée, et notamment sur la solution Linty.
Pour comprendre en détail la méthodologie, les mécanismes techniques, les exemples de vulnérabilités et les preuves de conformité ED‑203A / DO‑254, nous vous invitons à consulter l’article complet.
Pour comprendre en détail la méthodologie, les mécanismes techniques, les exemples de vulnérabilités et les preuves de conformité ED‑203A / DO‑254, nous vous invitons à consulter l’article complet.
