En 2017, Equifax découvre qu'une faille dans Apache Struts a exposé les données de 147 millions de personnes. Le correctif existait depuis deux mois. En 2021, Log4Shell affecte des millions d'applications Java, les équipes avec des scans automatisés corrigent en heures, les autres en semaines. Ces crises ont un point commun : la sécurité traitée comme une étape finale, pas comme une préoccupation continue.
Le DevSecOps change cette logique. Au lieu de vérifier la sécurité juste avant la release, on l'intègre à chaque moment du cycle de développement logiciel (le SDLC, Software Development Life Cycle : toutes les étapes qui vont de l'idée au logiciel en production). Ce n'est pas un outil ni une équipe dédiée : c'est une manière de travailler où chaque personne qui touche au code porte une part de responsabilité sur sa sécurité. Ce guide s'adresse aux développeurs, ops et responsables sécurité débutants en DevSecOps : il détaille les trois piliers du modèle, les pratiques concrètes (tests automatisés, pipeline sécurisé, supply chain security) et une feuille de route progressive pour démarrer sans tout bouleverser d'un coup.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Distinguer le DevSecOps du DevOps classique et ce que ce changement implique concrètement pour chaque rôle
- Repérer les quatre types de tests de sécurité automatisés (SCA, SAST, DAST, secrets scanning) et ce que chacun détecte
- Construire un pipeline avec des security gates qui bloquent le critique sans freiner le reste des livraisons
- Prioriser une feuille de route DevSecOps réaliste sur six mois, du quick win à la maturité
- Choisir les métriques (MTTD, MTTR, taux de détection) qui prouvent une progression réelle
Le problème que DevSecOps résout
Section intitulée « Le problème que DevSecOps résout »Dans un projet classique, la sécurité arrive en fin de cycle, une fois le code déjà écrit, testé fonctionnellement et prêt à partir en production. Le tableau suivant résume ce schéma et pourquoi il pose problème à chaque étape.
| Étape | Ce qui se passe | Problème |
|---|---|---|
| Développement | Code écrit pendant des semaines | Aucun contrôle de sécurité |
| QA | Tests fonctionnels | Sécurité ignorée |
| Pré-release | Audit sécurité de dernière minute | Failles découvertes tard |
| Release | Réécriture de code, retards | Budget explose, frustration |
Ce schéma crée des problèmes concrets, qui se répètent d'un projet à l'autre indépendamment de la taille de l'équipe :
- Coût de correction x100 : une faille en production coûte 100 fois plus cher qu'une faille détectée pendant l'écriture
- Conflits d'équipes : les développeurs voient la sécurité comme un frein, la sécurité voit les développeurs comme des risques. Ce mécanisme est détaillé dans pourquoi la sécurité échoue en pratique
- Failles acceptées : sous pression du calendrier, des vulnérabilités sont acceptées "temporairement", et ne sont jamais corrigées
Le DevSecOps casse ce cycle en déplaçant la sécurité vers le début, c'est le principe du shift-left.
Les trois piliers du DevSecOps
Section intitulée « Les trois piliers du DevSecOps »Le DevSecOps repose sur trois piliers complémentaires qui transforment la façon dont les organisations abordent la sécurité : une responsabilité qui n'appartient plus à une seule équipe, une automatisation pensée pour ne pas être contournée, et une vigilance qui ne s'arrête pas au déploiement.
1. Responsabilité partagée
Section intitulée « 1. Responsabilité partagée »La sécurité n'est pas le travail d'une équipe isolée. Chaque personne qui modifie le système porte une part de responsabilité :
- Le développeur qui ajoute une dépendance vérifie ses vulnérabilités
- L'ops qui ouvre un port réseau évalue le risque
- Le product owner qui demande une fonctionnalité comprend les implications sécurité
Le guide sur les responsabilités partagées détaille qui fait quoi concrètement, entre développeurs, ops et équipe sécurité.
2. Automatisation intelligente
Section intitulée « 2. Automatisation intelligente »L'automatisation permet de scanner chaque commit, pas juste avant la release. Mais elle doit être configurée intelligemment, sous peine d'être contournée par les équipes qu'elle est censée protéger.
| Situation | Action | Pourquoi |
|---|---|---|
| Secret détecté | Bloquer | Risque immédiat et critique |
| CVE critique (CVSS ≥ 9) | Bloquer | Exploitation probable |
| CVE moyenne (CVSS 4-6) | Alerter | Évaluer le contexte |
| Bonne pratique non suivie | Informer | Amélioration continue |
Un pipeline qui bloque trop souvent sera contourné. Un pipeline trop permissif ne sert à rien : l'équilibre entre les deux est le vrai travail d'ingénierie du DevSecOps.
3. Sécurité continue
Section intitulée « 3. Sécurité continue »La sécurité ne s'arrête pas au déploiement : une application en production reste exposée à de nouvelles vulnérabilités découvertes après coup, à des tentatives d'intrusion et à des dérives de configuration. Trois pratiques couvrent cette phase :
- Monitoring de sécurité pour détecter les anomalies, un complément spécialisé de l'observabilité générale
- Tests dynamiques (DAST) sur l'application réelle, en conditions proches de la production
- Réponse aux incidents préparée, avec un processus documenté comme celui décrit dans le guide incidents et postmortems
DevOps vs DevSecOps : la vraie différence
Section intitulée « DevOps vs DevSecOps : la vraie différence »Le DevOps rapproche développeurs et opérationnels. Le DevSecOps ajoute la sécurité dans cette boucle, mais pas comme "juste un scan de plus" : c'est un changement de qui porte la responsabilité, et à quel moment on la porte.
| Aspect | DevOps classique | DevSecOps |
|---|---|---|
| Qui s'occupe de la sécurité | Équipe dédiée, en fin de cycle | Tout le monde, à chaque étape |
| Quand on détecte les failles | Avant la release | Dès le commit |
| Formation sécurité | Optionnelle | Intégrée au parcours dev |
| Gestion des dépendances | "Ça marche" suffit | Vulnérabilités vérifiées |
| Secrets | Parfois en dur dans le code | Jamais en dur, externalisés |
La vraie différence : la responsabilité. Un développeur qui introduit une dépendance vulnérable n'est pas "couvert" par l'équipe sécurité. L'équipe sécurité devient un support, pas un contrôleur.
Les pratiques DevSecOps
Section intitulée « Les pratiques DevSecOps »Le DevSecOps s'articule autour de trois axes de pratiques qui se complètent : les tests automatisés qui détectent les failles, le pipeline qui décide quoi faire de ces détections, et la supply chain qui garantit que ce qui est livré est bien ce qui a été construit.
Tests de sécurité automatisés
Section intitulée « Tests de sécurité automatisés »Le contrôle ne se fait pas à un seul moment du cycle, mais à chaque étape où une faille peut entrer : à l'arrivée des dépendances tierces, pendant l'écriture du code, et sur l'application une fois démarrée. Ces trois moments ne révèlent pas les mêmes défauts, d'où la nécessité de plusieurs outils.
Quatre types de tests couvrent ces étapes du cycle de développement, chacun avec un rôle précis que le guide dédié aux tests de sécurité automatisés détaille avec des exemples d'outils :
| Type | Ce qu'il fait | Exemple concret |
|---|---|---|
| SCA | Vérifie les bibliothèques tierces | "Cette version de Log4j a une faille critique" |
| SAST | Analyse le code source sans l'exécuter | "Cette fonction SQL est vulnérable à l'injection" |
| DAST | Teste l'application en fonctionnement | "Le formulaire de login accepte des caractères dangereux" |
| Secrets scanning | Cherche les mots de passe oubliés dans le code | "Clé API AWS en dur dans le fichier config.py" |
Pourquoi tous les quatre ? Chaque test trouve des problèmes différents :
- SCA détecte les vulnérabilités connues dans vos dépendances (80% du code d'une application moderne vient de bibliothèques tierces)
- SAST trouve les erreurs dans votre code (injections SQL, XSS, etc.)
- DAST découvre les problèmes visibles uniquement quand l'application tourne (mauvaise configuration, headers manquants)
- Secrets scanning évite la catastrophe des clés API publiées sur GitHub
Pipeline sécurisé
Section intitulée « Pipeline sécurisé »À l'aéroport, vous passez par des contrôles successifs : vérification d'identité, scanner de bagages, détecteur de métaux. Si un contrôle échoue, vous ne passez pas.
Le pipeline CI/CD fonctionne pareil avec des security gates (portes de sécurité), un mécanisme que le guide sur le pipeline sécurisé explique en détail avec des exemples d'implémentation :
Les trois règles d'un pipeline sécurisé :
| Règle | Pourquoi | Exemple |
|---|---|---|
| Bloquer le critique | Un secret exposé = compromission immédiate | Secret détecté → build échoue |
| Alerter le reste | Tout bloquer = pipeline contourné | CVE moyenne → ticket créé, build passe |
| Ne jamais stocker de secrets en dur | Le code est versionné, donc visible | Utiliser un vault (HashiCorp Vault, AWS Secrets Manager) |
Supply chain security
Section intitulée « Supply chain security »Quand vous achetez de la viande, l'étiquette indique : origine, date d'abattage, numéro de lot. Si un problème sanitaire survient, on peut remonter toute la chaîne et rappeler les produits concernés.
En logiciel, c'est le même principe. Une application moderne contient des centaines de composants. Savez-vous lesquels ? En cas de faille (comme Log4Shell), pouvez-vous répondre en minutes à "sommes-nous affectés ?" ?
| Concept | Ce que ça fait |
|---|---|
| SBOM | Inventaire complet de tous les composants logiciels |
| Signature | Preuve cryptographique que l'artefact vient de vous |
| Provenance | Qui a construit quoi, quand, comment |
Pourquoi c'est crucial ? L'attaque SolarWinds (2020) a montré qu'un attaquant peut compromettre la chaîne de build et injecter du code malveillant dans un logiciel légitime. Sans SBOM ni vérification de provenance, vous faites confiance aveuglément. Ce sujet a pris une telle ampleur que l'OWASP Top 10:2025 (édition finale publiée en janvier 2026) lui consacre désormais une catégorie à part entière, Software Supply Chain Failures (A03:2025), qui remplace et élargit l'ancienne catégorie « composants vulnérables et obsolètes » de l'édition 2021 : elle couvre non seulement les CVE connues, mais aussi la compromission des dépôts, des pipelines de build et des mécanismes de distribution. La sécurité de la chaîne d'approvisionnement logicielle n'est plus un sujet périphérique : le guide dédié à la supply chain security détaille SBOM, signature et provenance avec des exemples d'outillage.
Les principes de sécurité sous-jacents
Section intitulée « Les principes de sécurité sous-jacents »Les outils changent, ces principes non. Ils précèdent le DevSecOps et lui survivront : ce sont eux qui déterminent si une chaîne outillée protège réellement quelque chose, ou si elle se contente d'empiler des scanners.
Sécurité by design
Section intitulée « Sécurité by design »Deux moments sont possibles pour traiter la sécurité : à la conception, ou après coup sur un système déjà construit. Le second coûte plus cher parce qu'il oblige à revenir sur des choix structurants, souvent hérités : un modèle de données qui n'isole pas les tenants, une authentification greffée sur une API qui n'en prévoyait pas. La sécurité by design consiste à porter ces décisions au moment où elles sont encore réversibles, un principe que le guide sécurité by design vs sécurité a posteriori développe avec des cas concrets.
Les 3 principes fondamentaux :
| Principe | Ce que ça signifie | Exemple |
|---|---|---|
| Moindre privilège | Ne donner que les droits strictement nécessaires | Un service qui lit une base n'a pas besoin des droits d'écriture |
| Défense en profondeur | Plusieurs couches de protection | Firewall + authentification + chiffrement + monitoring |
| Sécurisé par défaut | La configuration de base est sécurisée | Ports fermés par défaut, HTTPS obligatoire |
Comprendre les menaces et les risques
Section intitulée « Comprendre les menaces et les risques »Trois termes reviennent en permanence et sont régulièrement confondus, alors qu'ils désignent des objets distincts. Le guide menaces, risques, vulnérabilités donne une définition propre à chacun :
- La menace est l'acteur ou l'événement susceptible de nuire. Elle existe indépendamment de vous et vous ne la contrôlez pas.
- La vulnérabilité est la faiblesse exploitable de votre système. C'est le seul des trois sur lequel vous avez prise directe.
- Le risque croise les deux et les pondère par l'impact : une vulnérabilité critique sur un service interne sans donnée sensible pèse moins qu'une faille moyenne sur la base clients.
C'est ce calcul qui fonde la gestion des risques : les budgets étant finis, la protection se concentre là où l'impact serait le plus lourd.
| Concept | Question | Exemple en IT |
|---|---|---|
| Menace | Qui pourrait attaquer ? | Hackers, employés malveillants, États |
| Vulnérabilité | Quelle faiblesse peut être exploitée ? | Injection SQL, mot de passe faible |
| Risque | Quel impact si ça arrive ? | Fuite de données clients = amende RGPD + réputation |
La règle d'or : vous ne pouvez pas tout protéger au même niveau. Identifiez vos actifs critiques (données clients, secrets métier, clés de signature) et concentrez vos efforts dessus.
Par où commencer ?
Section intitulée « Par où commencer ? »L'adoption du DevSecOps est un voyage progressif. Ne cherchez pas à tout faire d'un coup, commencez par ce qui a le meilleur ROI. Si vous voulez dérouler cette feuille de route étape par étape avec des critères d'évaluation, le guide maturité et roadmap DevSecOps approfondit chaque palier.
Mois 1-2 : Les quick wins
Section intitulée « Mois 1-2 : Les quick wins »Ces actions ont un impact immédiat pour un effort minimal :
- Pre-commit hooks pour les secrets, un secret bloqué avant le commit coûte 5 minutes. Le même secret en production peut coûter des millions.
- Scan de dépendances (SCA) dans la CI, vous utilisez probablement des bibliothèques avec des CVE connues. Sachez lesquelles.
- Formation de base, 2h de sensibilisation à l'OWASP Top 10 appliqué au DevSecOps changent les réflexes.
Mois 3-4 : L'automatisation
Section intitulée « Mois 3-4 : L'automatisation »Intégrez la sécurité dans le flux normal de développement :
- SAST sur les pull requests, les développeurs voient les problèmes avant de merger
- Scan d'images conteneur, vos images Docker contiennent souvent des CVE héritées de l'image de base
- Séparation des environnements, dev, staging et prod avec des secrets distincts
Mois 5-6 : La maturité
Section intitulée « Mois 5-6 : La maturité »Passez de "on scanne" à "on peut prouver" :
- Signature d'artefacts, avec Cosign/Sigstore, prouvez que vos builds sont authentiques
- Génération de SBOM, répondez en minutes à "sommes-nous affectés par cette CVE ?"
- Monitoring de sécurité en production, détectez les comportements anormaux
Au-delà : L'excellence
Section intitulée « Au-delà : L'excellence »Pour les organisations avec des exigences élevées :
- SLSA niveau 3, provenance vérifiable de vos artefacts
- Réponse automatisée, un CVE avec un score CVSS critique détecté par votre veille déclenche automatiquement un ticket et une alerte
- Partage des pratiques, contribuez à la communauté, formez en interne
Métriques DevSecOps
Section intitulée « Métriques DevSecOps »Vous ne conduisez pas sans compteur de vitesse ni jauge d'essence. En DevSecOps, vous avez besoin de métriques pour savoir si vous progressez. Le guide des KPIs sécurité DevSecOps va plus loin sur la mise en place concrète de ces indicateurs.
Les 5 métriques essentielles
Section intitulée « Les 5 métriques essentielles »| Métrique | Ce qu'elle mesure | Pourquoi c'est important | Cible |
|---|---|---|---|
| MTTD (Mean Time To Detect) | Temps pour détecter une vulnérabilité | Plus c'est court, moins les attaquants ont de temps | < 24h pour critique |
| MTTR (Mean Time To Remediate) | Temps pour corriger une vulnérabilité | Une CVE connue non corrigée = cible facile | < 7 jours pour critique |
| Taux de détection par phase | Où sont trouvées les failles | L'objectif : maximum en CI, minimum en prod | > 80% en CI |
| Taux de faux positifs | Alertes non pertinentes | Trop de bruit = les alertes sont ignorées | < 10% |
| Couverture de scan | % du code/dépendances analysés | Ce qui n'est pas scanné n'est pas protégé | > 90% |
Comment interpréter ces métriques
Section intitulée « Comment interpréter ces métriques »| Si vous observez... | Ça signifie... | Action |
|---|---|---|
| MTTD élevé | Les vulnérabilités passent inaperçues | Ajouter des scans automatiques |
| MTTR élevé | Les correctifs traînent | Prioriser les CVE critiques, automatiser les tickets |
| Beaucoup de failles en prod | Les contrôles CI sont insuffisants | Renforcer les security gates |
| Taux de faux positifs élevé | Les développeurs ignorent les alertes | Affiner les règles, réduire le bruit |
Ces métriques s'alignent avec les métriques DORA : une bonne posture de sécurité accélère la livraison au lieu de la freiner. Le rapport DORA a lui-même évolué sur ce point dans son édition 2025 : au-delà des quatre métriques historiques, il ajoute un taux de reprise (part des déploiements non planifiés) et déplace le MTTR vers la famille "throughput" sous le nom de temps de récupération après échec de déploiement. Le message reste le même pour la sécurité : vitesse et stabilité se mesurent ensemble, elles ne s'opposent pas.
À retenir
Section intitulée « À retenir »- DevSecOps = sécurité intégrée, pas ajoutée à la fin
- Shift-left = détecter les problèmes au plus tôt (coût x100 évité)
- Responsabilité partagée = tout le monde contribue à la sécurité
- Automatisation intelligente = bloquer le critique, alerter le reste
- Quatre tests complémentaires = SCA, SAST, DAST et secrets scanning couvrent des angles différents
- Supply chain security = une catégorie à part entière depuis l'OWASP Top 10:2025
- Progressivité = commencer par les pre-commit hooks