La culture agile au service de la sécurité 

Le DevSecOps, en étendant les principes du DevOps à la sécurité, a pour objectif d’intégrer la sécurité by design et de l’automatiser à chaque étape du cycle de développement et opérationnel d’un projet. Il apporte ainsi pour chaque partie prenante du projet une responsabilité vis à vis de la sécurité qui doit l’intégrer dans leurs process. L’objectif principal est d’avoir un cycle de livraison du produit plus rapide et de rétroaction plus court, tout en prévenant les failles de sécurité en production et donc d’avoir un coût global réduit. 

 

Des systèmes embarqués de plus en plus connectés et de plus en plus nombreux au sein de vos écosystèmes…

Un système embarqué est un objet contenant des éléments numériques, il est composé d’une partie matérielle et logicielle ayant une connexion de données directe ou indirecte, logique ou physique, avec un appareil ou un réseau. La prolifération des systèmes embarqués dans le monde actuel (22,3 milliards de connexions IoT fin 2025 et plus de 47 milliards attendues en 2031 selon l’Ericsson Mobility Report de juin 2026) élargit la surface d’attaque, et ces objets sont de plus en plus visés : selon le 2026 Cyber Protect Report de SonicWall, les attaques ciblant l’IoT ont progressé de 11 % en 2025. Des secteurs critiques comme l’automobile, l’aéronautique, la santé ou l’énergie sont directement concernés. 

… mais aussi de plus en plus vulnérables 

Les systèmes embarqués deviennent la cible d’attaques exploitant aussi bien les failles des piles logicielles embarquées que les vulnérabilités des communications réseau, notamment lorsque les mécanismes de chiffrement ou d’authentification sont insuffisants. L’absence de vérification de l’intégrité du firmware et le manque de suivi des composants tiers, propriétaires ou open source, constituent également des points de fragilité. Par ailleurs, lorsque l’accès matériel est possible, les interfaces physiques (ports de débogage, bus internes, etc.) représentent des vecteurs d’attaques supplémentaires. Enfin, les processus de mise à jour, de déploiement et d’approvisionnement logiciel s’imposent comme des maillons critiques : la compromission d’un firmware, d’une mise à jour OTA ou d’un élément de la supply chain peut permettre l’introduction de code malveillant au cœur même du système. 

Ainsi, la surface d’attaque des systèmes embarqués ne se limite plus à un composant isolé, mais s’étend à l’ensemble de leurs briques logicielles, matérielles, de communication et de chaîne d’approvisionnement, renforçant leur vulnérabilité au sein d’écosystèmes toujours plus interconnectés. 

Il est donc critique d’intégrer le plus efficacement possible la sécurité dans les systèmes embarqués.

Pourquoi le DevSecOps permet de relever les défis de sécurité actuels pour l’embarqué ? 

La mise en œuvre d’une approche DevSecOps dans le développement de systèmes embarqués est une solution face à ces enjeux, en apportant de l’agilité dans le développement. Concrètement, cette approche permet de : 

1. Anticiper, prévenir et répondre plus efficacement aux failles de sécurité 
   • Grâce à une intégration continue de la sécurité, les failles sont détectées beaucoup plus tôt dans le cycle de vie du produit, souvent avant même que le code ne soit déployé sur le matériel. Par exemple, des analyses statiques ou des scans de dépendances automatisés peuvent repérer une vulnérabilité dès la phase de développement, évitant ainsi des correctifs coûteux une fois le produit sur le terrain. 
2. Anticiper, prévenir et répondre plus efficacement aux attaques
   •  La démarche permet aussi de réagir plus vite lorsqu’une attaque survient. L’inventaire des composants logiciels (SBOM) permet d’identifier immédiatement les produits concernés, la centralisation des logs facilite la détection d’un comportement anormal, et le pipeline automatisé permet de livrer un correctif testé et signé par une mise à jour à distance (OTA), sans attendre le prochain cycle de livraison. 
3. Intégrer de la sécurité en tant que code via des outils d’automatisation 
   • Cela signifie que les politiques, tests et contrôles de sécurité deviennent eux aussi automatisables et versionnables, au même titre que le code applicatif. Les outils d’analyse, de signature, de composition logicielle ou de tests de conformité peuvent être intégrés directement dans la chaîne CI/CD, garantissant que chaque build passe par des vérifications systématiques et reproductibles.

Cette automatisation change la donne : elle permet aux équipes embarquées de sécuriser leur produit sans dépendre exclusivement d’audits manuels ou de validations externes.

De plus, corriger une faille découverte en production peut coûter 29 à 1500 fois plus cher que si cette faiblesse avait été identifiée dès les premières phases de conception, selon une étude de la NASA. Cette approche conduit donc naturellement à une réduction globale des coûts liés à la sécurité.

Une adoption qui demande plus qu’un simple changement d’outils 

Cependant, la théorie se heurte à la réalité : l’application du DevSecOps aux systèmes embarqués fait face à des contraintes différentes de celles rencontrées dans l’IT classique : 

Des contraintes matérielles

Là où les infrastructures cloud peuvent être redimensionnées et corrigées presque instantanément, les contraintes de mémoire et de puissance de calcul en embarqué rendent ces opérations beaucoup plus difficiles. Un logiciel embarqué doit être optimisée, ce qui complique l’intégration d’outils de sécurité souvent conçus pour des environnements plus puissants. 

 À cela s’ajoute une diversité matérielle importante : il existe nombreux systèmes d’exploitation, architectures ou outils de compilation différents qui ont leurs applications propres. Il est donc bien plus complexe de mettre en place une approche DevSecOps uniforme. 

Des contraintes de mises à jour 

Les mises à jour sécurisées Over-The-Air (OTA) constituent un autre point sensible : elles doivent être fiables, authentifiées et capables de revenir à une version précédente (rollback) en cas d’échec. Si un serveur peut être patché en quelques secondes, un équipement embarqué nécessite quant à lui une logistique de déploiement bien plus lourde.

De plus, les systèmes isolés (sans connectivité fiable ou continue), posent un défi supplémentaire. Il est en effet complexe de leur transmettre les mises à jour de façon fiable et sécurisée. 

Quant aux systèmes intégrés en production, leur mise à jour implique souvent des arrêts. Il est donc nécessaire de minimiser l’interruption, de garantir une reprise immédiate et de s’assurer que la mise à jour n’impactera pas la continuité opérationnelle une fois déployée. 

Des contraintes réglementaires 

Les enjeux réglementaires sont également de plus en plus importants. Des textes comme le CRA en Europe imposent des exigences de sécurité strictes pour les objets connectés, comme la garantie de mises à jour de sécurité pendant plusieurs années. Dans le domaine automobile, la réglementation UNECE R155 impose la mise en place d’un management continu des risques, des tests réguliers de sécurité, tandis que l’UNR156 et le Software Update Management System imposent des processus de mise à jour sécurisés. Ainsi, l’hétérogénéité des normes selon les secteurs industriels, le manque d’outils adaptés, les limitations matérielles et logicielles complexifient la définition d’une stratégie DevSecOps unifiée. 

Des contraintes organisationnelles 

Enfin, il existe des défis humains et organisationnels : les équipes embarquées ne disposent pas toujours de profils spécialisés en cybersécurité, et les rôles de Security Champions (relais sécurité au sein des équipes produits) sont encore rares. Il faut donc investir dans la formation, la sensibilisation et la collaboration entre développeurs, testeurs et ingénieurs systèmes. 

Tous ces facteurs rendent le retour sur investissement difficile à estimer. Les coûts initiaux en outils, en formation et en temps d’intégration peuvent paraître élevés, alors que les bénéfices (réduction du risque, meilleure résilience, conformité) ne se mesurent souvent qu’à long terme. 

Autrement dit, appliquer les pratiques DevSecOps à des systèmes aussi contraints nécessite d’adapter les outils, les processus, et parfois même la culture d’équipe.

Surmonter les difficultés grâce à une feuille de route claire et des technologies adaptées 

Heureusement, ces obstacles ne sont pas insurmontables : il existe aujourd’hui des solutions concrètes pour accompagner la mise en œuvre du DevSecOps dans l’embarqué. Des outils modernes comme les systèmes de build automatisés (Yocto, Buildroot, etc.), les plateformes CI/CD intégrées ou encore des services SaaS spécialisés, permettent de sécuriser le cycle de développement sans alourdir les contraintes matérielles. 

L’approche la plus efficace consiste à avancer par étapes, en commençant par automatiser les tâches les plus répétitives et à forte valeur ajoutée (analyse statique du code, signature automatique des images, génération de SBOM, etc.), puis en intégrant progressivement des outils de contrôle de sécurité adaptés à l’environnement cible. L’objectif n’est pas d’être parfait tout de suite, mais d’améliorer continuellement la sécurité. 

L’intelligence artificielle décuple par ailleurs ces possibilités d’automatisation : tri et priorisation des alertes remontées par les analyses statiques, proposition de correctifs, génération de tests unitaires ou de scénarios de fuzzing, assistance à la revue de code. Ces usages ne dispensent pas d’une validation humaine, mais ils réduisent l’effort demandé aux équipes et rendent la démarche plus accessible. 

En parallèle, instaurer une culture de collaboration et de montée en compétences, par exemple en désignant des référents sécurité et en s’appuyant sur des formations spécifiques, facilite l’appropriation des nouvelles pratiques.

Ainsi, avec une feuille de route claire, des choix technologiques adaptés et une sensibilisation importante des responsables des équipes produit, il devient possible de franchir ces barrières techniques et organisationnelles, et de tirer pleinement parti des bénéfices du DevSecOps dans l’embarqué.

En définitive, le DevSecOps ne représente pas une contrainte de plus pour l’embarqué, mais un changement indispensable qui doit s’opérer de façon progressive et maîtrisée. Il est essentiel d’accepter cette évolution comme une opportunité de renforcer durablement la sécurité tout en accompagnant les équipes dans cette transformation.