Ce niveau 2 des feuilles de route de carrière DevSecOps transforme les bases du socle (Linux, Git, conteneurs) en pratiques opérationnelles concrètes. La formation DevSecOps en est le programme guidé, leçon par leçon. 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.
L'introduction au DevSecOps montre ce qui change par rapport au DevOps classique, et le guide menaces, risques et vulnérabilités donne les mots pour raisonner sur une surface d'attaque. Viennent ensuite les causes structurelles de l'échec, dans pourquoi la sécurité échoue, et la façon de décider sous contrainte : accepter, réduire ou transférer un risque, comme l'explique le guide des compromis de sécurité.
Deux guides ferment le bloc. Les responsabilités partagées disent qui fait quoi entre développeurs, ops, sécurité et management, et le Security by Design montre comment intégrer la sécurité dès la conception, avant la première ligne de code.
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.
La leçon Shift-Left explique comment raccourcir la boucle de retour et réduire le coût de correction. Le threat modeling avec STRIDE l'outille, avec une méthode pensée pour le backlog et la planification de sprint, et l'OWASP Top 10 appliqué au DevSecOps montre comment s'en servir en sensibilisation, en revue de code et dans les quality gates.
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.
Le guide des tests de sécurité dit quand utiliser chaque type de test et comment l'intégrer en CI. Le pipeline CI/CD sécurisé assemble ces tests en security gates, avec des seuils, une gestion des faux positifs et la signature des artefacts.
Côté plateforme, choisissez celle de votre contexte : GitLab CI/CD et GitHub Actions ont chacune leur formation. Quelle que soit la plateforme, le guide sécuriser les pipelines CI/CD traite le pipeline lui-même comme une cible : durcissement des runners, injection de variables, OIDC et attaques de supply chain.
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 renouveler une clé compromise en urgence.
Le guide de gestion des secrets compare Vault, SOPS et External Secrets Operator, et aide à choisir selon votre infrastructure. Le principe à retenir avant tout outil : un secret ne vit jamais dans le dépôt, il s'injecte à l'exécution et se renouvelle sans redéployer l'application.
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, est revenu le 19 mai 2026 contre des dizaines de paquets de l'écosystème AntV. Il se propage en réutilisant les jetons de mainteneurs qu'il vole, 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é.
Le guide supply chain security explique comment produire SBOM, attestations de build et signatures. La gestion des vulnérabilités prend le relais une fois l'inventaire connu : triage, scores CVSS et EPSS, délais internes, exceptions et lien avec le VEX.
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.
Le guide GitOps : Git comme source de vérité pose les principes, la réconciliation et la différence entre modèle pull et modèle push, avant de comparer ArgoCD et Flux.
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.
La définition du pipeline CI/CD et la distinction CI ou CD posent le vocabulaire, puis les formes de pipelines montrent quand paralléliser ou passer en matrice. Les deux derniers guides parlent d'échec : pourquoi les pipelines échouent, entre flakiness et temps de cycle trop long, et les anti-patterns CI/CD qui transforment un pipeline en obstacle.
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.
Le guide d'observabilité explique ce qu'apportent métriques, logs et traces et comment les combiner. Les SLO, SLI et error budgets transforment ces mesures en objectifs de fiabilité qui pèsent sur les décisions. Pour la pratique, la section observabilité couvre Prometheus, Grafana, Loki, Tempo et OpenTelemetry.
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.
Le guide incidents et postmortems suit le cycle complet : détection, escalade, résolution et analyse. L'organisation des astreintes montre comment tenir une rotation soutenable, et éliminer le toil libère le temps que le travail répétitif confisque.
Livrable pratique : Projet opérationnel
Section intitulée « Livrable pratique : Projet opérationnel »Le projet fil rouge de ce niveau reprend le dépôt du socle et lui ajoute la chaîne de sécurité complète : scans, SBOM, signature, déploiement GitOps et supervision. S'il tourne de bout en bout sans intervention manuelle, vous êtes prêt pour le niveau 3.
À 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 des jetons de mainteneurs volés, 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.