DevSecOps
Intégrer la sécurité au cycle, sans en faire un point de blocage.
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 disposant de 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.
En bref
Le DevSecOps intègre la sécurité à chaque moment du cycle de vie logiciel au lieu de la vérifier juste avant la mise en production. Ce n'est ni 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 le DevSecOps résout
| Étape | Ce qui se passe | Problème |
|---|---|---|
| Développement | du code écrit pendant des semaines | aucun contrôle de sécurité |
| Recette | tests fonctionnels | sécurité ignorée |
| Pré-livraison | audit de sécurité de dernière minute | failles découvertes tard |
| Livraison | réécriture de code, retards | le budget explose, la frustration monte |
Le schéma classique — et pourquoi il échoue à chaque étape.
Trois conséquences se répètent d'un projet à l'autre, indépendamment de la taille de l'équipe. Le coût de correction : une faille corrigée après livraison coûte de l'ordre de cent fois ce qu'elle aurait coûté en phase d'exigences --- rapport établi par Boehm et Basili (IEEE Computer, 2001), qui précisent toutefois qu'il tombe à environ cinq pour un sur les petits projets non critiques. Le chapitre revient sur ce chiffre, souvent cité de travers. Les conflits d'équipe : les développeurs voient la sécurité comme un frein, la sécurité voit les développeurs comme des risques. Les failles acceptées : sous pression du calendrier, des vulnérabilités sont admises « temporairement », et ne sont jamais corrigées.
Shift-left
Déplacer les contrôles — tests, sécurité, qualité — vers le début du cycle de développement au lieu de les concentrer à la fin. Plus un problème est détecté tôt, moins il coûte cher à corriger. Le chapitre montre la courbe de coût correspondante.
Les trois piliers
Responsabilité partagée
La sécurité n'est pas le travail d'une équipe isolée. Le développeur qui ajoute une dépendance en vérifie les vulnérabilités l'ops qui ouvre un port réseau évalue le risque le responsable produit qui demande une fonctionnalité en comprend les implications.
C'est d'abord un changement culturel
Les outils viennent après. Une équipe motivée avec des outils basiques fera mieux qu'une équipe réticente équipée des meilleurs scanners.
Automatisation intelligente
L'automatisation permet de scanner chaque commit plutôt que la veille de la livraison. Encore faut-il la calibrer, 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 |
| vulnérabilité critique (score ≥ 9) | bloquer | exploitation probable |
| vulnérabilité moyenne (score 4 à 6) | alerter | évaluer le contexte |
| bonne pratique non suivie | informer | amélioration continue |
Un pipeline qui bloque trop souvent sera contourné trop permissif, il ne sert à rien. L'équilibre est le vrai travail d'ingénierie.
Sécurité continue
La sécurité ne s'arrête pas au déploiement : une application en production reste exposée à des vulnérabilités découvertes après coup, à des tentatives d'intrusion et à des dérives de configuration. Trois pratiques couvrent cette phase : la supervision de sécurité pour détecter les anomalies, les tests dynamiques sur l'application réelle, et une réponse aux incidents préparée et documentée.
DevOps et DevSecOps : la vraie différence
| Aspect | DevOps classique | DevSecOps |
|---|---|---|
| Qui s'occupe de la sécurité | une équipe dédiée, en fin de cycle | tout le monde, à chaque étape |
| Quand on détecte les failles | avant la livraison | dès le commit |
| Formation à la sécurité | optionnelle | intégrée au parcours |
| 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 porte sur la responsabilité : l'équipe sécurité devient un support, pas un contrôleur.
Les pratiques
Quatre familles de tests
Le contrôle ne se fait pas à un seul moment, mais à chaque étape où une faille peut entrer. Ces moments ne révèlent pas les mêmes défauts, d'où la nécessité de plusieurs outils — le chapitre les détaille.
| Type | Ce qu'il fait | Exemple de verdict |
|---|---|---|
| SCA | vérifie les bibliothèques tierces | « cette version de Log4j a une faille critique » |
| SAST | analyse le code sans l'exécuter | « cette requête SQL est vulnérable à l'injection » |
| DAST | teste l'application en fonctionnement | « le formulaire de connexion accepte des caractères dangereux » |
| Recherche de secrets | cherche les identifiants oubliés | « clé d'API en dur dans config.py » |
Quatre outils parce que quatre angles morts différents — aucun ne couvre les autres.
Un pipeline à portes de sécurité
À l'aéroport, vous passez par des contrôles successifs : identité, bagages, détecteur de métaux. Si un contrôle échoue, vous ne passez pas. Le pipeline fonctionne de la même façon, avec des security gates.
Des contrôles successifs, et une décision différente selon la criticité de ce qui est trouvé.
| Règle | Pourquoi | Exemple |
|---|---|---|
| Bloquer le critique | un secret exposé, c'est une compromission immédiate | secret détecté, la construction échoue |
| Alerter sur le reste | tout bloquer, c'est se faire contourner | vulnérabilité moyenne : un ticket est créé, la construction passe |
| Aucun secret en dur | le code est versionné, donc visible | passer par un coffre-fort dédié |
Le chapitre montre ce qui arrive quand la première règle avale les deux autres.
Sécurité de la chaîne d'approvisionnement
Quand vous achetez de la viande, l'étiquette indique l'origine, la date, le numéro de lot : en cas de problème sanitaire, on remonte la chaîne. 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 qu'il apporte |
|---|---|
| SBOM | l'inventaire complet des composants logiciels |
| Signature | la preuve cryptographique que l'artefact vient bien de vous |
| Provenance | qui a construit quoi, quand et comment |
Trois réponses détaillées au chapitre .
L'attaque SolarWinds (2020) a montré qu'un attaquant peut compromettre la chaîne de construction et injecter du code malveillant dans un logiciel légitime. Le sujet a pris une telle ampleur que l'OWASP Top 10:2025 lui consacre désormais une catégorie entière — Software Supply Chain Failures — qui remplace et élargit l'ancienne catégorie des composants vulnérables et obsolètes : elle couvre aussi la compromission des dépôts, des chaînes de construction et des mécanismes de distribution.
Les principes sous-jacents
Les outils changent, ces principes non. Ce sont eux qui déterminent si une chaîne outillée protège réellement quelque chose, ou si elle empile des scanners.
| Principe | Ce que cela signifie | Exemple |
|---|---|---|
| Moindre privilège | ne donner que les droits strictement nécessaires | un service qui lit une base n'a pas besoin d'y écrire |
| Défense en profondeur | plusieurs couches de protection | pare-feu, authentification, chiffrement, supervision |
| Sécurisé par défaut | la configuration de base est déjà sûre | ports fermés par défaut, HTTPS obligatoire |
Trois principes antérieurs au DevSecOps, et qui lui survivront.
La sécurité dès la conception consiste à porter les décisions de sécurité au moment où elles sont encore réversibles. Traiter la sécurité après coup coûte plus cher parce qu'il faut revenir sur des choix structurants : un modèle de données qui n'isole pas les clients, une authentification greffée sur une interface qui n'en prévoyait pas.
Par où commencer
Premier palier — les gains rapides
- Crochets de pré-commit pour les secrets — un secret bloqué avant le commit coûte cinq minutes le même secret en production peut coûter des millions.
- Analyse des dépendances dans la chaîne — vous utilisez probablement des bibliothèques portant des vulnérabilités connues sachez lesquelles.
- Formation de base — deux heures de sensibilisation à l'OWASP Top 10 changent les réflexes.
Deuxième palier — l'automatisation
- analyse statique sur chaque demande de fusion : les problèmes sont vus avant la fusion
- scan des images de conteneur, qui héritent souvent de vulnérabilités de l'image de base
- séparation des environnements, avec des secrets distincts.
Troisième palier — la maturité, puis l'excellence
- signature des artefacts : prouver que vos constructions sont authentiques
- génération de SBOM : répondre en minutes à « sommes-nous affectés ? »
- supervision de sécurité en production
- puis, au-delà : provenance vérifiable (SLSA niveau 3), réponse automatisée aux vulnérabilités critiques, partage des pratiques.
Le meilleur rapport effort/bénéfice
Commencez par les crochets de pré-commit pour les secrets : trente minutes d'installation pour éviter les incidents les plus coûteux. Ajoutez ensuite l'analyse des dépendances — c'est là que se trouve la majorité des vulnérabilités.
Mesurer la progression
| Métrique | Ce qu'elle mesure | Enjeu | Cible |
|---|---|---|---|
| Délai de détection | temps pour détecter une vulnérabilité | moins de temps pour l'attaquant | moins de 24 h pour le critique |
| Délai de correction | temps pour la corriger | une faille connue non corrigée est une cible facile | moins de 7 jours pour le critique |
| Détection par phase | où les failles sont trouvées | maximum en intégration, minimum en production | plus de 80 % en intégration |
| Taux de faux positifs | alertes non pertinentes | trop de bruit, et tout est ignoré | moins de 10 % |
| Couverture de scan | part du code analysée | ce qui n'est pas scanné n'est pas protégé | plus de 90 % |
Cinq métriques — et des cibles à ajuster selon le contexte.
| Si vous observez… | Cela signifie | Action |
|---|---|---|
| un délai de détection élevé | les vulnérabilités passent inaperçues | ajouter des scans automatiques |
| un délai de correction élevé | les correctifs traînent | prioriser le critique, automatiser les tickets |
| beaucoup de failles en production | les contrôles d'intégration sont insuffisants | renforcer les portes de sécurité |
| un fort taux de faux positifs | les développeurs ignorent les alertes | affiner les règles, réduire le bruit |
Une bonne posture de sécurité accélère la livraison au lieu de la freiner.
À retenir de cette séance
Le DevSecOps, c'est la sécurité intégrée, pas ajoutée à la fin. Le shift-left détecte les problèmes au plus tôt, évitant un facteur cent sur le coût. La responsabilité est partagée : tout le monde contribue. L'automatisation est intelligente : bloquer le critique, alerter sur le reste. Quatre tests complémentaires — SCA, SAST, DAST, recherche de secrets — couvrent des angles différents. La chaîne d'approvisionnement est une catégorie à part entière depuis l'OWASP Top 10:2025. Et la progressivité l'emporte : commencer par les crochets de pré-commit.
Réponse unique
Que désigne le shift-left en DevSecOps ?
Indice · La gauche, c'est le début du cycle de vie.
[ METTRE EN PRATIQUE ]
Planifier trois paliers d'adoption
3 étapes · 30 min · 120 XP
[ CETTE LEÇON DANS LES PARCOURS ]