Ce niveau 2 du parcours DevSecOps transforme les bases du socle (Linux, Git, conteneurs) en pratiques opérationnelles concrètes. Il s'adresse aux ingénieurs qui savent déjà déployer une application et veulent désormais sécuriser le flux de livraison de bout en bout : shift-left sécurité, pipeline CI/CD avec security gates, gestion des secrets, SBOM et supply chain, déploiement GitOps, observabilité et gestion des incidents. Vous y apprendrez à raisonner en développeur et en défenseur, sans ralentir vos livraisons. Neuf blocs de compétences structurent ce niveau DevSecOps opérationnel, du threat modeling STRIDE jusqu'au postmortem sans blâme.
Durée estimée : 80 à 100 heures selon votre expérience CI/CD initiale.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Intégrer la sécurité dans tout le cycle de développement grâce au shift-left et au threat modeling STRIDE
- Construire un pipeline CI/CD avec SAST, DAST, SCA et détection de secrets
- Générer un SBOM et signer vos artefacts avec Sigstore/Cosign pour atteindre SLSA niveau 1 à 2
- Déployer en continu avec GitOps (ArgoCD ou Flux)
- Mesurer la fiabilité avec des SLO et des SLI plutôt qu'à l'instinct
- Gérer un incident de production et rédiger un postmortem sans blâme
Bloc 1, Fondamentaux DevSecOps
Section intitulée « Bloc 1, Fondamentaux DevSecOps »Avant d'intégrer des outils, il faut comprendre pourquoi la sécurité échoue dans les équipes qui travaillent vite, et comment y remédier structurellement. Ce premier bloc pose le vocabulaire commun (menace, risque, vulnérabilité) et le cadre de décision qui sert de fondation à tout le reste du niveau.
Bloc 2, Shift-Left et threat modeling
Section intitulée « Bloc 2, Shift-Left et threat modeling »Le shift-left (déplacer les contrôles de sécurité au plus tôt dans le cycle de développement, plutôt qu'en fin de pipeline) n'est pas une phrase creuse : c'est une décision d'organisation du travail. Savoir faire du threat modeling est la compétence clé qui rend le shift-left concret plutôt que déclaratif, en identifiant les scénarios d'attaque avant d'écrire le premier test.
L'OWASP Top 10, la référence historique des risques applicatifs, est passée en édition 2025 : deux catégories inédites font leur apparition, dont les défaillances de la supply chain logicielle, et Broken Access Control conserve la première place. C'est une bonne raison de la reparcourir même si vous la connaissez déjà par cœur.
Bloc 3, Tests de sécurité
Section intitulée « Bloc 3, Tests de sécurité »Les tests de sécurité automatisés sont le cœur du pipeline DevSecOps. SAST (analyse du code source sans l'exécuter), DAST (tests sur l'application en cours d'exécution), SCA (analyse des dépendances tierces) et fuzzing ont chacun une place précise selon le moment du cycle où l'on veut détecter un problème.
Outils de pipeline, choisissez la plateforme adaptée à votre contexte :
Bloc 4, Gestion des secrets
Section intitulée « Bloc 4, Gestion des secrets »Les secrets (mots de passe, clés API, tokens d'accès) exposés dans les logs, les dépôts Git ou les images Docker restent une des causes les plus fréquentes de fuites de données. La gestion des secrets est un sujet opérationnel, pas théorique : elle touche autant le développeur qui commit par erreur un fichier .env que l'administrateur qui doit faire tourner une clé compromise en urgence.
Bloc 5, Supply chain et SBOM
Section intitulée « Bloc 5, Supply chain et SBOM »La sécurité de la supply chain logicielle est devenue incontournable depuis les attaques SolarWinds et Log4Shell, et les incidents plus récents le confirment : le ver npm Shai-Hulud, apparu en 2025 et rejoué sous une forme aggravée début 2026, s'est propagé en compromettant simplement des comptes de mainteneurs par phishing, sans exploiter la moindre faille technique. Un seul package populaire piégé suffit à contaminer des dizaines de milliers de projets en aval.
Le SBOM (Software Bill of Materials, l'inventaire complet des composants d'un logiciel), le framework SLSA (aujourd'hui en version 1.2, avec un volet build et un volet source) et la signature Sigstore sont devenus les standards de facto pour tracer et vérifier l'origine d'un artefact. L'édition 2025 de l'OWASP Top 10 consacre d'ailleurs une catégorie entière aux défaillances de la supply chain logicielle : ce risque a définitivement dépassé le stade de la curiosité pour les équipes sécurité.
Bloc 6, GitOps
Section intitulée « Bloc 6, GitOps »GitOps structure le déploiement continu : Git devient la source de vérité unique, et un contrôleur (ArgoCD ou Flux) compare en permanence l'état réel du cluster à l'état déclaré dans le dépôt. Tout écart déclenche une réconciliation automatique, ce qui rend les déploiements déclaratifs, traçables et auditables : plus besoin de se demander qui a changé quoi en production, l'historique Git répond directement à la question.
Bloc 7, CI/CD : de l'idée à la production
Section intitulée « Bloc 7, CI/CD : de l'idée à la production »Au-delà des outils, comprendre la philosophie CI/CD évite de tomber dans les pièges classiques : pipelines qui prennent 40 minutes à s'exécuter, tests flaky (des tests qui échouent de façon aléatoire sans lien avec un changement de code) qui minent la confiance de l'équipe, ou déploiements manuels qui trahissent la promesse de la livraison continue.
Bloc 8, Observabilité minimale
Section intitulée « Bloc 8, Observabilité minimale »Sans observabilité (la capacité à comprendre l'état interne d'un système à partir de ses sorties : métriques, logs, traces), on déploie à l'aveugle et chaque incident se transforme en enquête à tâtons. L'objectif de ce bloc est d'apprendre à mesurer ce qui compte vraiment pour vos utilisateurs, pas simplement ce qui est facile à afficher sur un dashboard.
Bloc 9, Incidents et runbooks
Section intitulée « Bloc 9, Incidents et runbooks »La gestion des incidents est une compétence DevSecOps à part entière, pas un sujet réservé aux équipes d'astreinte. Les équipes matures traitent chaque incident comme une opportunité d'apprentissage grâce au postmortem sans blâme (une analyse qui cherche les causes systémiques d'une panne plutôt qu'un responsable à sanctionner), et non comme une faute à punir. Cette discipline est au cœur du SRE (Site Reliability Engineering), qui traite la fiabilité comme une fonctionnalité à part entière plutôt qu'un simple effet de bord de l'exploitation.
Livrable pratique, Projet opérationnel
Section intitulée « Livrable pratique, Projet opérationnel »À retenir
Section intitulée « À retenir »- La sécurité intégrée dans le pipeline ne ralentit pas les livraisons si les gates sont bien calibrées : bloquant sur les sévérités critiques, informatif sur le reste.
- Le shift-left n'est utile que combiné à du threat modeling : sans modélisation des menaces, on scanne au hasard sans prioriser.
- L'OWASP Top 10:2025 ajoute deux catégories inédites, dont les défaillances de la supply chain logicielle : un signal fort que ce risque est désormais central.
- Le SBOM et la signature via Sigstore/Cosign restent la base minimale pour viser le niveau SLSA 2, la référence de facto pour prouver l'intégrité d'un artefact.
- Des vers npm comme Shai-Hulud rappellent que la supply chain se compromet aussi par un simple mainteneur piégé, pas seulement par une faille technique.
- GitOps simplifie l'audit des déploiements : tout changement est tracé dans Git, avec réconciliation automatique en cas de dérive.
- L'observabilité sans SLO n'est que du bruit : définissez ce qui compte avant d'installer des dashboards.
- Un incident bien traité produit un postmortem sans blâme, pas un coupable : c'est ce qui distingue une équipe qui apprend d'une équipe qui se protège.