DevSecOps : intégrer la sécurité dans le cycle de développement
Longtemps, la sécurité intervenait à la fin d'un projet : l'application était terminée, on appelait un expert pour la tester, il trouvait des dizaines de problèmes, et l'on devait choisir entre retarder la mise en ligne ou la lancer avec les failles. C'est la méthode la plus chère qui existe. Le DevSecOps propose l'inverse : intégrer la sécurité à chaque étape du développement et du déploiement, pour trouver tôt ce qui coûte peu à corriger. Cette leçon conclut le chapitre en reliant tout ce que vous avez vu.
Cadre légal
Les outils d'analyse mentionnés ici s'utilisent sur votre code ou sur celui d'un client qui vous a autorisé par écrit. Utiliser un outil d'analyse dynamique contre une application ou un service tiers sans autorisation et sans périmètre défini peut tomber sous le coup des articles 323-1 à 323-3-1 du Code pénal. Pour vous entraîner, utilisez vos propres projets, OWASP Juice Shop, DVWA ou PortSwigger Web Security Academy.
De DevOps à DevSecOps
Le mouvement DevOps a rapproché les équipes qui développent (Dev) et celles qui exploitent (Ops) pour livrer plus vite et plus souvent, grâce à l'automatisation. Le DevSecOps ajoute la sécurité (Sec) à cette boucle : elle devient une responsabilité partagée, automatisée autant que possible, et présente à chaque étape. On parle souvent de « décaler vers la gauche » (shift left) : traiter la sécurité tôt dans la chronologie du projet, là où une erreur est la moins chère à corriger.
Imaginez la construction d'une maison : détecter qu'une cloison est mal placée sur le plan coûte une gomme. Le découvrir une fois la maison construite coûte une démolition.
La chaîne de livraison et ses contrôles
Une chaîne d'intégration et de déploiement continus (CI/CD) est une suite d'étapes automatiques qui transforment le code en application déployée. À chaque étape, on peut brancher un contrôle de sécurité :
| Étape | Contrôle de sécurité | Ce qu'il cherche |
|---|---|---|
| Conception | Modélisation des menaces | Les risques de l'architecture, avant même d'écrire du code |
| Écriture du code | Revue de code, détection de secrets | Mauvaises pratiques, mots de passe et clés oubliés |
| Construction | Analyse statique du code (SAST) | Motifs de code dangereux, sans exécuter le programme |
| Dépendances | Analyse de composition logicielle (SCA) | Bibliothèques tierces vulnérables ou à licence problématique |
| Infrastructure décrite comme du code | Analyse des configurations | Stockage public, ports ouverts, droits excessifs, avant le déploiement |
| Conteneurs | Analyse des images | Vulnérabilités connues, secrets embarqués |
| Test | Analyse dynamique (DAST), tests d'intrusion ciblés | Vulnérabilités visibles sur l'application en fonctionnement |
| Production | Supervision, journalisation, détection | Comportements anormaux, tentatives d'attaque |
Chaque contrôle apporte un angle de vue différent : l'analyse statique lit le code mais ne voit pas la configuration en production ; l'analyse dynamique voit le comportement mais pas le code. Ils se complètent, et aucun ne remplace l'esprit critique d'un humain.
La modélisation des menaces : penser avant de coder
La modélisation des menaces consiste à se poser, pendant la conception, quatre questions : Que construisons-nous ? Qu'est-ce qui peut mal tourner ? Que faisons-nous pour l'éviter ? Avons-nous bien travaillé ? On dessine l'application (utilisateurs, composants, flux de données, frontières de confiance) et on passe en revue les menaces possibles à chaque flux. Une grille de lecture courante, appelée STRIDE, classe les menaces en six familles : usurpation d'identité, falsification, répudiation, divulgation d'information, déni de service, élévation de privilèges. Vous reconnaissez là des notions vues dans les chapitres précédents.
Vous n'avez pas besoin d'un logiciel : un tableau blanc, une équipe de quatre personnes et une heure suffisent pour une première modélisation, et ce temps est largement rentabilisé.
La sécurité de la chaîne d'approvisionnement logicielle
Une application moderne contient souvent plus de code tiers que de code écrit par l'équipe : bibliothèques, composants, images de base. Chaque dépendance est une confiance accordée à un inconnu. Les attaques sur la chaîne d'approvisionnement visent précisément cela : compromettre un composant largement utilisé pour atteindre tous ses utilisateurs. Les défenses reposent sur :
- un inventaire des composants utilisés, parfois formalisé dans une « nomenclature logicielle » (SBOM) ;
- la mise à jour régulière des dépendances, avec une veille sur les vulnérabilités publiées (cve.org, nvd.nist.gov) ;
- la vérification de l'origine et de l'intégrité des composants ;
- la protection de la chaîne elle-même : les serveurs de construction et leurs secrets sont des cibles de choix, donc à protéger comme des systèmes critiques.
Des cadres de développement sécurisé existent : le NIST (nist.gov) publie un cadre de pratiques de développement logiciel sécurisé, et l'OWASP (owasp.org) propose des guides et des modèles de maturité pour organiser une démarche progressive.
Le facteur humain : culture et bon sens
L'outillage n'est que la moitié du DevSecOps. L'autre moitié est culturelle :
- Pas de « police de la sécurité » : si les développeurs voient la sécurité comme un frein, ils la contourneront. On leur donne des retours rapides, clairs, actionnables.
- Gérer le bruit : un outil qui produit 500 alertes dont 480 fausses sera ignoré. On règle, on priorise, on bloque seulement les problèmes graves au début.
- Former : des ateliers pratiques sur les vulnérabilités fréquentes (celles de l'OWASP) valent mieux qu'un long document.
- Désigner des relais : un « champion sécurité » dans chaque équipe fait le lien avec les spécialistes.
- Mesurer utilement : le délai de correction des vulnérabilités graves est plus parlant que le nombre d'alertes générées.
Où se situe le travail du testeur d'intrusion ?
Dans un monde DevSecOps, le test d'intrusion ne disparaît pas ; son rôle change. Il intervient pour ce que les outils automatiques ne savent pas trouver : les failles de logique métier (un enchaînement d'étapes qui contourne une règle de gestion), les scénarios d'attaque combinés, les erreurs de conception. Il aide aussi à calibrer les outils : si un test manuel trouve ce qu'aucun outil n'avait vu, c'est un signal pour améliorer la chaîne. Un apprenti white hat qui comprend le développement et l'automatisation est particulièrement apprécié.
À vous de jouer
Concevez la chaîne de livraison sécurisée d'une petite application d'Atelier Boréal (une API de devis en ligne, déployée dans le cloud, dans des conteneurs). Pour chacune des étapes suivantes, nommez un contrôle et dites s'il doit bloquer la livraison ou seulement alerter : (1) écriture du code, (2) dépendances, (3) construction de l'image, (4) déploiement de l'infrastructure, (5) application en test.
Voir une solution
- Écriture du code : détection de secrets avant l'enregistrement du code. Bloquer : un secret ne doit jamais entrer dans le dépôt.
- Dépendances : analyse de composition logicielle. Bloquer pour les vulnérabilités critiques connues avec correctif disponible ; alerter pour le reste, avec un délai de traitement.
- Image : analyse des vulnérabilités et vérification que le conteneur ne s'exécute pas en superutilisateur. Bloquer pour l'exécution en superutilisateur ; alerter pour les vulnérabilités moyennes.
- Infrastructure : analyse des configurations. Bloquer pour un stockage public ou des droits « tout pour tous » ; alerter pour les écarts mineurs.
- Application en test : analyse dynamique et tests d'autorisation de l'API sur l'environnement de test. Alerter au début, puis bloquer progressivement quand les réglages sont fiables.
Le principe : bloquer ce qui est grave, certain et facile à corriger ; alerter pour le reste afin de ne pas fâcher les équipes dès le premier jour.
Pour votre checklist
Terminez votre checklist de revue par une section « Cycle de développement » : y a-t-il une modélisation des menaces ? Des contrôles automatisés ? Un inventaire des dépendances ? Une gestion des secrets ? Avec les trois sections précédentes (cloud, API, conteneurs), vous avez une pièce solide de portfolio.
Le chapitre suivant tourne le regard vers votre avenir : comment participer à des programmes de bug bounty, rédiger un rapport qui est pris au sérieux et bâtir votre crédibilité.
À retenir
- DevSecOps = intégrer la sécurité tôt (« shift left ») et en continu, avec des contrôles automatisés dans la chaîne de livraison.
- Contrôles courants : détection de secrets, analyse statique, analyse des dépendances, analyse des configurations et des images, analyse dynamique.
- La modélisation des menaces permet de repérer les risques avant d'écrire du code.
- La chaîne d'approvisionnement logicielle est une surface d'attaque : inventaire, mises à jour, vérification des origines.
- La culture compte autant que les outils ; le testeur d'intrusion reste indispensable pour la logique métier et les scénarios combinés.