5 min de lecture<\/p>\n
Int\u00e9grer la s\u00e9curit\u00e9 \u00e0 la fin du cycle de d\u00e9veloppement a toujours \u00e9t\u00e9 co\u00fbteux. D\u00e9sormais, cela devient aussi ill\u00e9gal. La directive NIS2, le R\u00e8glement sur la cybers\u00e9curit\u00e9 (Cyber Resilience Act) et une prise de conscience croissante des risques li\u00e9s \u00e0 la cha\u00eene d\u2019approvisionnement obligent les \u00e9quipes logicielles \u00e0 int\u00e9grer la s\u00e9curit\u00e9 d\u00e8s la premi\u00e8re ligne de code. DevSecOps est la voie \u00e0 suivre – mais la transformation culturelle p\u00e8se plus lourd que n\u2019importe quel outil.<\/strong><\/p>\n Les chiffres sont sans appel : la majorit\u00e9 des vuln\u00e9rabilit\u00e9s logicielles<\/a> d\u00e9coulent d\u2019erreurs commises durant la phase de d\u00e9veloppement – mais d\u00e9tect\u00e9es uniquement en production. Une vuln\u00e9rabilit\u00e9 corrig\u00e9e lors de la phase de conception co\u00fbte, selon l\u2019IBM Systems Sciences Institute, six fois moins cher qu\u2019une correction effectu\u00e9e apr\u00e8s d\u00e9ploiement. Pourtant, dans de nombreuses \u00e9quipes de d\u00e9veloppement allemandes, la s\u00e9curit\u00e9 intervient encore trop souvent \u00e0 la toute fin du cycle – sous forme de tests d\u2019intrusion avant la mise en production ou d\u2019audits avant la certification.<\/p>\n DevSecOps rompt avec ce sch\u00e9ma. Cette approche int\u00e8gre directement les contr\u00f4les de s\u00e9curit\u00e9 dans la pipeline CI\/CD : chaque commit<\/em> est automatiquement analys\u00e9 \u00e0 la recherche de vuln\u00e9rabilit\u00e9s connues, de pratiques de codage non s\u00e9curis\u00e9es et de d\u00e9pendances open source vuln\u00e9rables. L\u2019objectif ? Faire de la s\u00e9curit\u00e9 une composante quotidienne du travail des d\u00e9veloppeurs, et non une exception r\u00e9serv\u00e9e aux derniers instants avant la mise en production.<\/p>\n La directive NIS2<\/a>, qui devait \u00eatre transpos\u00e9e dans le droit national d\u2019ici octobre 2024, a \u00e9t\u00e9 int\u00e9gr\u00e9e au droit allemand en d\u00e9cembre 2025. Cette directive \u00e9largit consid\u00e9rablement le cercle des entreprises concern\u00e9es. Outre les infrastructures critiques, elle couvre d\u00e9sormais \u00e9galement les entreprises des secteurs de la production, de l\u2019agroalimentaire, de la gestion des d\u00e9chets, de la poste et de la chimie – le BSI (Office f\u00e9d\u00e9ral de la s\u00e9curit\u00e9 informatique) estime \u00e0 environ 30 000 le nombre total d\u2019organisations allemandes concern\u00e9es.<\/p>\n Trois exigences de NIS2 rev\u00eatent une importance particuli\u00e8re pour le d\u00e9veloppement logiciel :<\/p>\n Gestion des risques dans la cha\u00eene d\u2019approvisionnement :<\/strong> Les entreprises doivent \u00e9valuer la s\u00e9curit\u00e9 de leurs fournisseurs – y compris de leurs fournisseurs de logiciels. Celui qui utilise des biblioth\u00e8ques open source sans conna\u00eetre leur statut de s\u00e9curit\u00e9 viole potentiellement la directive.<\/p>\n D\u00e9claration des incidents :<\/strong> Les incidents de s\u00e9curit\u00e9 doivent \u00eatre signal\u00e9s dans un d\u00e9lai de 24 heures. Sans d\u00e9tection automatis\u00e9e int\u00e9gr\u00e9e \u00e0 la pipeline, les vuln\u00e9rabilit\u00e9s ne sont souvent d\u00e9couvertes qu\u2019au moment de leur exploitation.<\/p>\n Obligation de preuve :<\/strong> Les entreprises doivent pouvoir d\u00e9montrer qu\u2019elles ont mis en \u0153uvre des mesures techniques appropri\u00e9es. Une pipeline DevSecOps document\u00e9e, incluant des analyses automatis\u00e9es, constitue une telle preuve.<\/p>\n Parall\u00e8lement, le R\u00e8glement sur la cybers\u00e9curit\u00e9 (Cyber Resilience Act, CRA) de l\u2019UE, applicable \u00e0 partir de 2027, imposera aux fabricants l\u2019obligation de garantir la s\u00e9curit\u00e9 des produits comportant des \u00e9l\u00e9ments num\u00e9riques tout au long de leur cycle de vie. Pour les \u00e9diteurs de logiciels, cela signifie que la \u00ab s\u00e9curit\u00e9 par conception \u00bb (Security by Design<\/em>) devient une obligation l\u00e9gale.<\/p>\n Les trois piliers de la s\u00e9curit\u00e9 automatis\u00e9e du code peuvent \u00eatre int\u00e9gr\u00e9s dans toute pipeline CI\/CD moderne – souvent en quelques jours seulement :<\/p>\n SAST (Static Application Security Testing)<\/strong> analyse le code source sans l\u2019ex\u00e9cuter. Des outils tels que SonarQube, Checkmarx ou Semgrep recherchent des motifs connus de programmation non s\u00e9curis\u00e9e : injections SQL, scripts intersites (XSS), identifiants cod\u00e9s en dur, cryptographie non s\u00e9curis\u00e9e. Le SAST s\u2019ex\u00e9cute id\u00e9alement \u00e0 chaque pull request<\/em>, offrant un retour imm\u00e9diat aux d\u00e9veloppeurs avant que le code ne soit fusionn\u00e9.<\/p>\n DAST (Dynamic Application Security Testing)<\/strong> teste l\u2019application en cours d\u2019ex\u00e9cution depuis l\u2019ext\u00e9rieur. Des outils comme OWASP ZAP ou Burp Suite simulent des attaques contre l\u2019application d\u00e9ploy\u00e9e afin de d\u00e9tecter des vuln\u00e9rabilit\u00e9s visibles uniquement \u00e0 l\u2019ex\u00e9cution – telles qu\u2019une authentification d\u00e9faillante, des points de terminaison API expos\u00e9s ou des mauvaises configurations serveur. Le DAST s\u2019ex\u00e9cute typiquement dans l\u2019environnement de pr\u00e9production, dans le cadre de la pipeline de livraison.<\/p>\n SCA (Software Composition Analysis)<\/strong> analyse les d\u00e9pendances d\u2019une application – paquets npm, d\u00e9pendances Maven, biblioth\u00e8ques Python – \u00e0 la recherche de vuln\u00e9rabilit\u00e9s connues. Compte tenu du fait que les applications modernes sont constitu\u00e9es \u00e0 80 \u00e0 90 % de code tiers, l\u2019analyse de composition n\u2019est pas un \u00ab bonus \u00bb, mais une n\u00e9cessit\u00e9 absolue. Des outils comme Snyk, Dependabot ou Mend (anciennement WhiteSource) signalent les CVE connues et proposent souvent imm\u00e9diatement le correctif correspondant.<\/p>\n La combinaison de ces trois approches couvre la grande majorit\u00e9 des vuln\u00e9rabilit\u00e9s d\u00e9tectables automatiquement. Selon Veracode, le temps moyen de rem\u00e9diation (Mean Time to Remediation<\/em>, MTTR) diminue de 60 % chez les entreprises disposant d\u2019une s\u00e9curit\u00e9 int\u00e9gr\u00e9e dans leur pipeline, compar\u00e9 \u00e0 celles qui ne r\u00e9alisent que des audits p\u00e9riodiques.<\/p>\n La v\u00e9ritable difficult\u00e9 r\u00e9side dans la transformation culturelle. La technique peut \u00eatre r\u00e9solue – mais les d\u00e9veloppeurs qui per\u00e7oivent la s\u00e9curit\u00e9 comme un obstacle trouveront in\u00e9vitablement des moyens de contourner les outils.<\/p>\n \n”<\/span><\/p>\n Int\u00e9grer la s\u00e9curit\u00e9 \u00e0 la fin du cycle de d\u00e9veloppement a toujours \u00e9t\u00e9 co\u00fbteux. D\u00e9sormais, cela devient aussi ill\u00e9gal.<\/p>\n<\/blockquote>\n<\/figure>\n Allianz Technology :<\/strong> La filiale IT d\u2019Allianz a lanc\u00e9 en 2024 un programme formant chaque d\u00e9veloppeur au r\u00f4le de \u00ab champion de la s\u00e9curit\u00e9 \u00bb. Chaque \u00e9quipe d\u00e9signe une personne charg\u00e9e d\u2019\u00eatre le point de contact pour toutes les questions li\u00e9es \u00e0 la s\u00e9curit\u00e9, \u00e0 qui 20 % de son temps de travail est consacr\u00e9. Ces champions de la s\u00e9curit\u00e9 d\u00e9cident conjointement avec l\u2019\u00e9quipe centrale AppSec quelles r\u00e8gles SAST doivent bloquer la pipeline (Breaking<\/em>) et lesquelles doivent simplement g\u00e9n\u00e9rer un avertissement (Warning<\/em>).<\/p>\n SAP :<\/strong> En tant que plus grand \u00e9diteur de logiciels europ\u00e9en, SAP exploite l\u2019une des pipelines DevSecOps les plus \u00e9tendues d\u2019Allemagne. Chaque commit<\/em> dans la base de code produit subit automatiquement des analyses SAST, SCA et de conteneurs. Les r\u00e9sultats sont directement visibles par les d\u00e9veloppeurs dans leur environnement de d\u00e9veloppement int\u00e9gr\u00e9 (IDE) – et non uniquement dans un tableau de bord de s\u00e9curit\u00e9 s\u00e9par\u00e9. Le principe ? Le retour sur la s\u00e9curit\u00e9 doit arriver l\u00e0 o\u00f9 le code est \u00e9crit.<\/p>\n PME :<\/strong> De nombreuses petites et moyennes entreprises allemandes adoptent une approche pragmatique. Une m\u00e9thode courante consiste \u00e0 introduire d\u2019abord l\u2019analyse de composition (SCA) comme premier outil (temps de mise en \u0153uvre : un jour), puis \u00e0 activer le SAST dans la pipeline (une semaine), et enfin \u00e0 ajouter le DAST pour les applications critiques (deux \u00e0 quatre semaines). La variante open source – SonarQube Community, OWASP ZAP, Trivy – ne co\u00fbte aucun budget, seulement du temps de mise en \u0153uvre.<\/p>\n L\u2019exp\u00e9rience montre que les entreprises qui mettent en \u0153uvre DevSecOps uniquement via des outils<\/a> \u00e9chouent plus fr\u00e9quemment que celles qui priorisent la transformation culturelle. Trois principes se sont av\u00e9r\u00e9s efficaces :<\/p>\n Ne pas sanctionner les d\u00e9veloppeurs :<\/strong> Si la pipeline de s\u00e9curit\u00e9 bloque une compilation, le retour fourni doit \u00eatre constructif. Le d\u00e9veloppeur doit disposer du contexte – quelle est la nature du risque, comment le corriger, pourquoi cela importe. Des outils qui ne font que renvoyer \u00ab d\u00e9couverte critique \u00bb sans explication ni proposition de correctif g\u00e9n\u00e8rent de la frustration, non de la s\u00e9curit\u00e9.<\/p>\n Renforcer progressivement les seuils :<\/strong> Au d\u00e9part, configurer uniquement les d\u00e9couvertes critiques (Critical<\/em>) et importantes (High<\/em>) comme blocages de la pipeline. Traiter les d\u00e9couvertes mod\u00e9r\u00e9es (Medium<\/em>) et faibles (Low<\/em>) comme simples avertissements, suivies dans un backlog<\/em> s\u00e9par\u00e9. Seulement lorsque les \u00e9quipes auront acquis de l\u2019exp\u00e9rience, resserrer progressivement les seuils.<\/p>\n Rendre la s\u00e9curit\u00e9 visible :<\/strong> Des tableaux de bord montrant l\u2019\u00e9volution du nombre de vuln\u00e9rabilit\u00e9s dans le temps, la rapidit\u00e9 de correction des anomalies d\u00e9tect\u00e9es, ou encore les performances particuli\u00e8rement remarquables de certaines \u00e9quipes. Le renforcement positif fonctionne mieux que la pression r\u00e9glementaire.<\/p>\n Les entreprises qui mettent en \u0153uvre DevSecOps uniquement via des outils \u00e9chouent plus fr\u00e9quemment que celles qui priorisent la transformation culturelle. Trois principes se sont av\u00e9r\u00e9s efficaces :<\/p>\n Ne pas sanctionner les d\u00e9veloppeurs :<\/strong> Si la pipeline de s\u00e9curit\u00e9 bloque une compilation, le retour fourni doit \u00eatre constructif. Le d\u00e9veloppeur doit disposer du contexte – quelle est la nature du risque, comment le corriger, pourquoi cela importe. Des outils qui ne font que renvoyer \u00ab d\u00e9couverte critique \u00bb sans explication ni proposition de correctif g\u00e9n\u00e8rent de la frustration, non de la s\u00e9curit\u00e9.<\/p>\n Renforcer progressivement les seuils :<\/strong> Au d\u00e9part, configurer uniquement les d\u00e9couvertes critiques (Critical<\/em>) et importantes (High<\/em>) comme blocages de la pipeline. Traiter les d\u00e9couvertes mod\u00e9r\u00e9es (Medium<\/em>) et faibles (Low<\/em>) comme simples avertissements, suivies dans un backlog<\/em> s\u00e9par\u00e9. Seulement lorsque les \u00e9quipes auront acquis de l\u2019exp\u00e9rience, resserrer progressivement les seuils.<\/p>\n Rendre la s\u00e9curit\u00e9 visible :<\/strong> Des tableaux de bord montrant l\u2019\u00e9volution du nombre de vuln\u00e9rabilit\u00e9s dans le temps, la rapidit\u00e9 de correction des anomalies d\u00e9tect\u00e9es, ou encore les performances particuli\u00e8rement remarquables de certaines \u00e9quipes. Le renforcement positif fonctionne mieux que la pression r\u00e9glementaire.<\/p>\n DevSecOps n\u2019est pas un \u00e9tat \u00e0 atteindre, mais un processus qui m\u00fbrit. Les entreprises qui entament cette d\u00e9marche aujourd\u2019hui prennent de l\u2019avance – non seulement sur le plan r\u00e9glementaire, mais aussi sur celui de la qualit\u00e9 de leur code.<\/p>\n DevOps int\u00e8gre d\u00e9veloppement et exploitation dans un processus continu. DevSecOps \u00e9tend cette approche en int\u00e9grant la s\u00e9curit\u00e9 comme une dimension \u00e9gale – les contr\u00f4les de s\u00e9curit\u00e9 ne sont pas report\u00e9s, mais int\u00e9gr\u00e9s \u00e0 chaque \u00e9tape de la pipeline.<\/p>\n<\/details>\n NIS2 s\u2019applique aux entreprises comptant au moins 50 employ\u00e9s ou r\u00e9alisant un chiffre d\u2019affaires annuel d\u2019au moins 10 millions d\u2019euros dans 18 secteurs d\u00e9finis. Des entreprises plus petites peuvent \u00e9galement \u00eatre concern\u00e9es si elles agissent comme fournisseurs d\u2019infrastructures critiques. Une v\u00e9rification contre la liste des secteurs publi\u00e9e par le BSI est recommand\u00e9e.<\/p>\n<\/details>\n La variante open source (SonarQube Community, OWASP ZAP, Trivy, Dependabot) ne g\u00e9n\u00e8re aucun co\u00fbt de licence – uniquement des frais de mise en \u0153uvre. Les plateformes commerciales comme Snyk, Checkmarx ou Veracode commencent \u00e0 environ 10 000 euros par an pour les petites \u00e9quipes. Le retour sur investissement (ROI) provient de la r\u00e9duction des co\u00fbts li\u00e9s aux incidents et de l\u2019acc\u00e9l\u00e9ration des cycles de livraison.<\/p>\n<\/details>\n Source de l’image : Pexels \/ Tima Miroshnichenko<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<\/span>L’essentiel<\/h2>\n
\n
NIS2 et la pression r\u00e9glementaire<\/h2>\n
Le triangle SAST-DAST-SCA<\/h2>\n
Pratique : comment les \u00e9quipes allemandes mettent en \u0153uvre DevSecOps<\/h2>\n
Ce qui reste : la culture d\u00e9vore les outils<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Quelle est la diff\u00e9rence entre DevOps et DevSecOps ?<\/strong><\/summary>\n
Toutes les entreprises doivent-elles appliquer NIS2 ?<\/strong><\/summary>\n
Quel est le co\u00fbt de la mise en \u0153uvre de DevSecOps ?<\/strong><\/summary>\n
Lectures compl\u00e9mentaires<\/h2>\n
\n
Plus de contenus du r\u00e9seau m\u00e9dia MBF<\/h2>\n
\n