Aller au contenu
FRENDécrivez votre besoin

DevSecOps : définition, différence avec le DevOps, et par où commencer

Le DevSecOps intègre la sécurité au travail quotidien des équipes qui développent et livrent un logiciel. La différence avec le DevOps, les contrôles automatiques (SAST, DAST, SCA, secrets), les cadres de référence et les premières étapes.

Par Publié le 5 octobre 2026

Le DevSecOps consiste à intégrer la sécurité au travail quotidien des équipes qui développent et exploitent un logiciel, plutôt que de la contrôler juste avant la mise en production. Des vérifications automatiques tournent à chaque modification du code, et le développement, la sécurité et l’exploitation partagent la responsabilité du résultat.

DevSecOps et DevOps : quelle différence ?

Le DevOps rapproche le développement (Dev) et l’exploitation (Ops) pour livrer plus souvent et plus sûrement, grâce à l’automatisation. Le DevSecOps ajoute la sécurité (Sec) à cette même chaîne : ce n’est ni une équipe de plus ni un outil, c’est la sécurité traitée comme les tests, automatiquement et du début à la fin du cycle.

On parle aussi de « shift left » : décaler la sécurité vers la gauche, c’est-à-dire vers le début du cycle. Une faille repérée pendant l’écriture du code se corrige dans la foulée ; la même faille découverte en production demande une analyse, un correctif en urgence et parfois une communication de crise.

Pourquoi la sécurité ne peut plus attendre la fin

  • Les failles sont la première porte d’entrée. Dans le rapport Verizon 2026 sur les fuites de données (mai 2026), l’exploitation d’une faille devient la première porte d’entrée des attaquants, dans 31 % des fuites étudiées contre 20 % un an plus tôt. Près d’une fuite sur deux (48 %) implique un tiers, fournisseur ou partenaire.
  • Les composants open source sont visés. Une application s’appuie sur de nombreuses bibliothèques écrites par d’autres. L’éditeur Sonatype a recensé plus de 454 600 nouveaux paquets malveillants en 2025 sur les grands dépôts open source, pour plus de 1,23 million au total.
  • La chaîne de fabrication elle-même. Le 29 mars 2024, une porte dérobée a été signalée dans XZ Utils, une bibliothèque de compression présente sur de nombreux systèmes Linux : le code malveillant, caché dans les archives des versions publiées et non dans le code visible du dépôt, pouvait compromettre l’accès à distance par OpenSSH sur certains systèmes.
  • Les secrets fuient. GitGuardian a détecté plus de 28,6 millions de nouveaux secrets (mots de passe, clés d’accès) dans des modifications publiques sur GitHub en 2025, 34 % de plus qu’en 2024 ; plus de 64 % des secrets valides en 2022 l’étaient encore en janvier 2026.

Dans l’édition 2025 de son rapport sur le coût des fuites de données (juillet 2025), IBM classe la démarche DevSecOps en tête des facteurs qui réduisent ce coût : environ 227 000 dollars de moins en moyenne, pour un coût moyen mondial de 4,44 millions de dollars.

Les contrôles automatiques de la chaîne de livraison

La chaîne de livraison (CI/CD, pour intégration et déploiement continus) construit, teste et déploie le logiciel à chaque modification. Le DevSecOps y branche des contrôles, chacun à sa place :

  • Le SAST (analyse statique) : il lit le code source sans l’exécuter et repère les erreurs de sécurité courantes, comme une requête à la base de données construite avec une saisie de l’utilisateur, dès la demande de fusion.
  • La SCA (analyse de la composition logicielle) : elle recense les bibliothèques utilisées et leurs versions, et alerte quand une faille connue en touche une. Elle produit aussi l’inventaire des composants, le SBOM, présenté dans notre article sur le SBOM et le Cyber Resilience Act.
  • La détection de secrets : elle repère les mots de passe et les clés d’accès dans le code et son historique, avant qu’ils ne partent dans un dépôt partagé.
  • L’analyse de l’infrastructure décrite en code : elle vérifie les fichiers qui décrivent les serveurs, les accès et le stockage, et repère par exemple une base de données ouverte à tous ou un espace de stockage public par erreur.
  • L’analyse des images de conteneurs : elle cherche les failles connues dans le système et les bibliothèques embarqués dans chaque image.
  • Le DAST (analyse dynamique) : il teste l’application en marche, de l’extérieur, comme le ferait un attaquant, sur un environnement de test.

L’ANSSI résume les bonnes pratiques dans sa fiche « Les Essentiels DevSecOps » (février 2024) : tests de sécurité automatiques dans la chaîne, secrets hors du code et rangés dans un gestionnaire propre à chaque environnement, double authentification sur les dépôts, signature des modifications, chaînes de développement et de production séparées, et actions sur la production traitées comme de l’administration.

Les cadres de référence : NIST SSDF, SLSA, OWASP

  • Le SSDF du NIST (Secure Software Development Framework, SP 800-218, version 1.1 de février 2022), cadre américain de développement sécurisé, range les pratiques en quatre familles : préparer l’organisation, protéger le logiciel, produire un logiciel bien sécurisé, répondre aux failles. Une version 1.2 est en projet depuis décembre 2025.
  • SLSA (Supply-chain Levels for Software Artifacts), porté par l’OpenSSF, fixe des niveaux de garantie sur la fabrication du logiciel : au niveau 1, une trace de la façon dont il a été construit ; au niveau 2, une trace signée, produite par une plateforme de construction hébergée ; au niveau 3, une plateforme de construction durcie. Version 1.2 depuis novembre 2025.
  • L’OWASP publie le Top 10 des risques des applications web ; son édition 2025 place en troisième position les défaillances de la chaîne d’approvisionnement logicielle, une catégorie élargie par rapport à 2021. Elle publie aussi l’ASVS (version 5.0, mai 2025), une liste d’exigences de sécurité à vérifier, et SAMM, un modèle pour mesurer et faire progresser sa démarche.

Pour un produit vendu en Europe, le Cyber Resilience Act fait d’une partie de ces pratiques une obligation à partir de décembre 2027 : sécurité dès la conception, traitement des failles, SBOM.

Ne pas noyer les développeurs sous les alertes

Un DevSecOps qui bloque tout est vite contourné. Ce qui fonctionne :

  • commencer en mode alerte, sans bloquer, le temps de trier les faux positifs ;
  • bloquer ensuite sur peu de règles, fixées avec l’équipe sécurité : une faille critique qui a un correctif, un secret dans le code ;
  • montrer le résultat dans les outils des développeurs, au moment de la relecture, avec l’explication et la correction proposée ;
  • traiter la dette existante à part, par ordre de risque, plutôt que d’exiger de tout corriger d’un coup.

Cette dette s’accumule vite : selon l’éditeur Veracode (février 2026), 82 % des organisations gardent des failles non corrigées depuis plus d’un an, et 60 % en gardent de critiques.

Le code écrit par l’IA passe les mêmes contrôles

Une partie du code est désormais écrite par des assistants et des agents de code. Ce code passe par la même chaîne que le reste : analyse, dépendances vérifiées (un assistant peut proposer un paquet qui n’existe pas), relecture humaine. Nos articles sur le vibe coding et sur le déploiement des agents de code détaillent ces règles.

Par où commencer

  • Faire le point : quelles applications, quelle chaîne, quels contrôles existent déjà.
  • Commencer par les secrets et les dépendances : ils se branchent vite et donnent peu de faux positifs.
  • Ajouter l’analyse du code et de l’infrastructure, d’abord en simple alerte.
  • Fixer avec l’équipe sécurité les règles qui bloquent une mise en production.
  • Suivre quelques indicateurs : le délai de correction des failles critiques, les secrets trouvés, les exceptions accordées.

C’est la démarche de notre offre La sécurité dans chaque livraison, souvent menée avec Une chaîne de livraison commune à vos équipes. Le platform engineering permet d’intégrer ces contrôles dans des modèles prêts à l’emploi, pour que la voie simple soit aussi la voie sûre. Voir aussi DevOps et CI/CD. Pour en parler avec un ingénieur : la journée de cadrage offerte.

Questions fréquentes

SAST et DAST, quelle différence ?

Le SAST lit le code sans l’exécuter, dès qu’il est écrit ; le DAST teste l’application qui tourne, de l’extérieur. Le premier trouve tôt et montre la ligne en cause, le second voit ce qu’un attaquant verrait. Les deux se complètent.

Le DevSecOps ralentit-il les livraisons ?

Un peu au début, le temps de régler les contrôles. Ensuite, des contrôles automatiques et rapides remplacent les vérifications de dernière minute et limitent les correctifs en urgence, à condition de garder peu de règles bloquantes, claires et expliquées.

Faut-il une équipe sécurité dédiée ?

Pas forcément au départ. Il faut une personne qui fixe les règles et arbitre les exceptions, et des développeurs formés aux erreurs courantes ; les contrôles automatiques prennent en charge le travail répétitif.

Par quel contrôle commencer ?

Par les secrets et les dépendances : ils se mettent en place vite, produisent peu de faux positifs et couvrent des causes fréquentes de fuite. L’analyse du code et le DAST viennent ensuite.

Sources

Faits et chiffres vérifiés le 4 octobre 2026.