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. 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é.
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 :
| É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 :
- Coût de correction x100 : une faille en production coûte 100 fois plus 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
- 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é :
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é
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 :
| 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.
3. Sécurité continue
Section intitulée « 3. Sécurité continue »La sécurité ne s’arrête pas au déploiement. En production :
- Monitoring de sécurité pour détecter les anomalies
- Tests dynamiques (DAST) sur l’application réelle
- Réponse aux incidents préparée
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”.
| 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. Chacun répond à une question différente.
Tests de sécurité automatisés
Section intitulée « Tests de sécurité automatisés »L’analogie : les contrôles qualité dans une usine automobile
Dans une usine automobile, on ne vérifie pas la qualité uniquement à la fin de la chaîne. On contrôle :
- Les matières premières à leur arrivée (les pièces sont-elles conformes ?)
- Pendant l’assemblage (les soudures sont-elles solides ?)
- Sur le véhicule fini (les freins fonctionnent-ils ?)
En développement logiciel, c’est pareil. Quatre types de tests couvrent différentes étapes :
| Type | L’analogie usine | Ce qu’il fait | Exemple concret |
|---|---|---|---|
| SCA | Contrôle des pièces fournisseurs | Vérifie les bibliothèques tierces | ”Cette version de Log4j a une faille critique” |
| SAST | Contrôle de l’assemblage | Analyse le code source sans l’exécuter | ”Cette fonction SQL est vulnérable à l’injection” |
| DAST | Test du véhicule complet | Teste l’application en fonctionnement | ”Le formulaire de login accepte des caractères dangereux” |
| Secrets scanning | Détecteur de fuite | 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’analogie : le sas de sécurité à l’aéroport
À 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é) :
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 »L’analogie : la traçabilité alimentaire
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 | L’analogie alimentaire | Ce que ça fait |
|---|---|---|
| SBOM | Liste des ingrédients | Inventaire complet de tous les composants logiciels |
| Signature | Sceau d’authenticité | Preuve cryptographique que l’artefact vient de vous |
| Provenance | Traçabilité “de la ferme à l’assiette” | 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.
Les principes de sécurité sous-jacents
Section intitulée « Les principes de sécurité sous-jacents »Sécurité by design
Section intitulée « Sécurité by design »L’analogie : construire une maison
Vous pouvez :
- Construire la maison, puis ajouter une alarme et des barreaux aux fenêtres
- Concevoir la maison avec une porte blindée, des serrures solides et un éclairage dissuasif dès le départ
L’option 2 est moins chère et plus efficace. C’est la sécurité by design : intégrer la sécurité dès la conception, pas après coup.
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 »L’analogie : l’assurance habitation
Quand vous assurez votre maison, vous évaluez :
- Les menaces : cambriolage, incendie, inondation
- Les vulnérabilités : porte fragile, absence de détecteur de fumée, zone inondable
- Les risques : probabilité × impact financier
Vous n’investissez pas autant pour protéger un vélo que pour protéger des bijoux de famille. C’est la gestion des risques : concentrer les efforts sur ce qui compte.
| 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 “bijoux de famille” (données clients, secrets métier) 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.
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 aux OWASP Top 10 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 critique 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 »L’analogie : le tableau de bord de votre voiture
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.
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.
À 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
- Progressivité = commencer par les pre-commit hooks