DevSecOps consiste à intégrer la sécurité à chaque étape de la livraison logicielle, de la conception jusqu'à la production, au lieu de la confier à un audit de fin de projet. Cette formation enseigne une méthode : savoir quel risque on traite, quel contrôle le couvre, où le placer dans la chaîne et comment prouver qu'il fonctionne. C'est la formation centrale du site : les autres domaines lui fournissent son socle ou l'approfondissent. Elle s'adresse à un DevOps, un administrateur ou un développeur qui connaît déjà Linux, Git, les conteneurs, la CI/CD et les bases de Terraform, et qui veut une chaîne où la sécurité est automatisée et vérifiable.
Ce que vous allez apprendre
Section intitulée « Ce que vous allez apprendre »- Analyser les risques d'une application et de son pipeline avec un modèle de menace
- Bloquer failles, secrets et dépendances vulnérables avant qu'ils n'entrent dans le dépôt
- Durcir un pipeline CI/CD : permissions, épinglage, jetons courts, OIDC (une identité fédérée qui évite de stocker un secret)
- Produire une image propre, un SBOM (l'inventaire des composants livrés), une signature et une provenance (qui a construit l'artefact, et comment) vérifiables
- Remplacer les secrets statiques par des identités machine
- Traiter une vulnérabilité de la découverte à la clôture, et mesurer la posture
Quel problème cette formation résout-elle ?
Section intitulée « Quel problème cette formation résout-elle ? »Avant de choisir un outil, il faut nommer ce qui bloque. Le tableau met en regard les symptômes visibles, ceux qu'on remarque en réunion post-incident, et les causes profondes qu'ils cachent. Cette lecture évite de traiter un problème de culture ou de flux avec une solution purement technique, l'erreur la plus fréquente des équipes qui débutent.
| Symptôme fréquent | Ce qui manque réellement |
|---|---|
| Des outils modernes, mais des incidents qui se répètent | Une culture de l'amélioration continue et des postmortems sans blâme |
| Une CI/CD qui tourne, mais des mises en production encore stressantes | Des lots plus petits et un retour plus rapide |
| Des failles de sécurité découvertes en production | Une sécurité pensée comme contrainte de conception, pas comme contrôle final |
| Des scanners branchés, mais aucun build jamais bloqué | Un seuil de blocage décidé, et une preuve qu'il fonctionne |
| Chaque équipe réinvente la roue | Un socle commun et une plateforme partagée |
À qui s'adresse cette formation ?
Section intitulée « À qui s'adresse cette formation ? »Elle suppose les bases DevOps acquises et ne les réenseigne pas. Si l'un des prérequis ci-dessous vous manque, suivez d'abord la formation qui le couvre : chaque module de DevSecOps y renvoie au lieu de la redire. Kubernetes n'est pas exigé pour commencer, il ne sert qu'à la fin de la piste Complet.
| Prérequis | Pourquoi | Où l'apprendre |
|---|---|---|
| Linux | les conteneurs et les runners s'y exécutent | Formation Linux |
| Git | tous les contrôles commencent au dépôt | Formation Git |
| Conteneurs | image, registre, exécution | Formation Docker |
| CI/CD | le pipeline est un actif à sécuriser | GitHub Actions ou GitLab CI |
| IaC | on scanne du Terraform | Formation Terraform |
| Kubernetes, facultatif | le volet déploiement de la piste Complet | Formation Kubernetes |
Pour vous situer, posez-vous quatre questions : savez-vous écrire un
Dockerfile multi-stage, lire un fichier de workflow CI, annuler un commit
poussé, et dire ce que fait terraform plan ? Quatre oui : commencez au
module 1. Un non : passez d'abord par la formation correspondante, une
lecture ciblée suffit souvent.
Une méthode, pas un catalogue de scanners
Section intitulée « Une méthode, pas un catalogue de scanners »Un parcours organisé outil par outil, un chapitre SAST, un chapitre DAST, un chapitre scan d'image, laisse au lecteur le travail le plus difficile : relier chaque scanner au risque qu'il couvre. Ici, chaque contrôle se présente dans le même ordre : quel risque, quelle classe de contrôle, où la placer, quel résultat elle produit, et comment traiter ce résultat. L'outil vient en dernier, et un seul sert d'implémentation de référence par besoin.
| Besoin | Outil de référence | Pourquoi lui |
|---|---|---|
| Secrets dans le code | Gitleaks | libre, rapide, lit l'historique Git |
| Analyse statique | Semgrep | règles lisibles, sortie SARIF, le format standard de résultats |
| Dépendances, image, IaC | Trivy | un seul binaire pour trois scans |
| Mauvaise configuration IaC | Checkov | couverture Terraform large |
| Inventaire et signature | Syft, Cosign | standards ouverts, Sigstore |
| Secrets chiffrés dans Git | SOPS | fichiers relus en revue de code |
| Conformité | CINC Auditor | profils InSpec, distribution libre |
| Détection runtime | Falco | projet gradué de la CNCF, la fondation qui héberge Kubernetes |
Tous ces outils sont open source et tournent en local : aucun cloud payant n'est requis. Les alternatives (detect-secrets, KICS, OpenSCAP, Tetragon) restent documentées sur le site, hors du parcours.
Le programme en seize modules
Section intitulée « Le programme en seize modules »Le parcours suit le cycle de livraison, pas l'arborescence du site : ses leçons viennent des sections sécurité, DevOps, CI/CD, conteneurs et infrastructure as code. Les trois premiers modules posent le cadre (culture, livraison, raisons d'intégrer la sécurité), les dix suivants sécurisent la chaîne dans l'ordre où un changement la traverse, et les trois derniers apprennent à mesurer, à généraliser puis à tout démontrer. Chaque module répond à une question, et la colonne de droite donne sa première leçon de la piste Essentiel.
| Module | La question | Commencer par |
|---|---|---|
| Culture et flux | Pourquoi DevOps, et comment circule la valeur ? | Qu'est-ce que DevOps ? |
| Le système de livraison | Comment une modification arrive-t-elle en production ? | Qu'est-ce qu'une pipeline CI/CD ? |
| Fondamentaux DevSecOps | Où la sécurité doit-elle entrer dans le cycle ? | DevSecOps |
| Threat modeling | Que protège-t-on, contre qui ? | Menace, risque, vulnérabilité |
| Code et dépendances | Comment empêcher une faille ou un secret d'entrer ? | Tests de sécurité automatisés |
| Secrets et identités machine | Comment se passer des secrets statiques ? | Le problème des secrets statiques |
| Sécuriser la CI/CD | Peut-on faire confiance à ce qui exécute le build ? | La confiance implicite |
| Build, conteneurs et IaC | Comment livrer une image et une infra saines ? | Dockerfile : bonnes pratiques |
| Software supply chain | Que livre-t-on, et qui l'a construit ? | Sécurité de la supply chain |
| Déploiement contrôlé | Comment ne déployer que ce qu'on a vérifié ? | Chiffrer ses secrets avec SOPS (Complet) |
| Sécurité du runtime | Que se passe-t-il une fois en production ? | Sécurité des conteneurs |
| Vulnérabilités et conformité | Comment mener une CVE jusqu'à sa clôture ? | Gestion des vulnérabilités |
| Observer et répondre | Que faire quand le système se dégrade ? | Observabilité |
| Mesurer et piloter | La livraison et la sécurité progressent-elles ? | Les métriques DORA |
| Généraliser à l'échelle | Comment étendre la pratique à toutes les équipes ? | Security Champions (Complet) |
| Capstone | Toute la chaîne, sur un seul dépôt | Le fil rouge |
Les secrets et identités machine viennent volontairement avant la sécurité du pipeline : un pipeline sans secret statique s'appuie sur l'OIDC, et il faut avoir compris le problème du secret zéro pour en saisir l'intérêt. Le programme détaillé, leçon par leçon, avec votre progression, est sur la page Mon parcours.
Deux pistes : Essentiel ou Complet
Section intitulée « Deux pistes : Essentiel ou Complet »La piste Essentiel garde la colonne vertébrale : une leçon par geste indispensable, de la culture au runtime, sans Kubernetes. La piste Complet ajoute les approfondissements, le volet Kubernetes du déploiement et la gouvernance détaillée. Le sélecteur de la page Mon parcours filtre l'affichage, votre progression reste la même.
Un seul dépôt, qui se durcit de module en module
Section intitulée « Un seul dépôt, qui se durcit de module en module »Plutôt que des exercices isolés, la formation suit un produit unique : une petite application volontairement fautive, avec un secret dans l'historique, une dépendance vulnérable, un Dockerfile en root, un Terraform trop ouvert et un pipeline trop permissif. Chaque module corrige une couche, et la chaîne passe de v0, non sécurisée, à une version signée, attestée puis surveillée.
Les leçons sont suivies une à une dans Mon parcours, et des quiz couvrent la plupart d'entre elles. Deux labs guidés propres au parcours portent sur le pipeline durci et le build vérifiable ; les leçons reprises des formations Kubernetes et Terraform portent les labs de celles-ci.
Comment prouve-t-on ce qu'on sait ?
Section intitulée « Comment prouve-t-on ce qu'on sait ? »Un quiz vérifie qu'on a compris pourquoi, un lab guidé qu'on sait faire, un challenge qu'on sait faire sans la procédure. La preuve finale vient du capstone : il ne note pas les commandes tapées, il vérifie l'état final du dépôt. Secret absent de l'historique, scanners qui bloquent réellement, SBOM présent, signature valide, image non signée refusée.
Pour approfondir, hors du parcours
Section intitulée « Pour approfondir, hors du parcours »Ces pages ne sont pas dans la progression, pour qu'elle reste finissable. Elles prolongent un module quand un sujet vous concerne directement :
- Code : fuzzing, OSV-Scanner
- Pipeline : runners auto-hébergés, Jenkins
- Conteneurs et IaC : namespaces, capabilities, seccomp, OPA et Conftest
- Supply chain : Sigstore, in-toto, Syft
- Secrets : OpenBao, secrets Kubernetes
- Runtime : audit logs Kubernetes
Et après la formation : niveaux de carrière et spécialisations
Section intitulée « Et après la formation : niveaux de carrière et spécialisations »La formation donne le socle commun. La section DevOps propose en plus trois feuilles de route de carrière, qui débordent largement du parcours : elles couvrent aussi la fiabilité, le delivery et l'organisation des équipes. Elles servent à situer un poste, pas à remplacer le programme suivi.
- Niveau 1, Socle : culture DevOps, flux, sécurité fondamentale et SRE (Site Reliability Engineering, l'ingénierie de la fiabilité).
- Niveau 2, DevSecOps opérationnel : pipeline sécurisé, secrets, supply chain, GitOps, observabilité, gestion des incidents.
- Niveau 3, Expert et spécialisations : gouvernance, maturité, Platform Engineering, policy as code.
Le DevSecOps n'est pas un métier unique : c'est un socle qui mène à des trajectoires distinctes selon qu'on privilégie la sécurité applicative, la fiabilité, la plateforme, le cloud ou les pipelines. Les cinq premières spécialités du tableau ont leur page, avec leurs responsabilités et leur parcours, dans le catalogue des métiers ; l'architecte et le FinOps n'en ont pas, faute de formation qui les couvre.
| Spécialité | Mission | Certifications cibles |
|---|---|---|
| DevSecOps Engineer | Sécurité shift-left, SAST/DAST, supply chain | CKS, Certified AppSec |
| SRE | Fiabilité, SLO/SLI, on-call, réduction du toil | CKA, CKAD |
| Platform Engineer | IDP, Golden Paths, self-service infra | CKA, Terraform Associate |
| Ingénieur CI/CD | Pipelines, artefacts, déploiements continus | GitLab Certified, GitHub Actions |
| Cloud Engineer | Multi-cloud, IaC, migrations | AWS SAA, GCP ACE, AZ-104 |
| Architecte DevSecOps | Standards, gouvernance, design for failure | CKA + CKS + multi-cloud |
| FinOps Engineer | Coûts cloud, rightsizing, chargeback | FinOps Certified Practitioner |
Une certification valide un socle de connaissances reconnu par les recruteurs, elle ne remplace jamais la pratique sur des incidents réels. Visez-la quand le niveau qui y prépare est acquis : un examen avancé passé sans les fondations laisse des angles morts que le premier incident révèle.
Que contient la section DevOps ?
Section intitulée « Que contient la section DevOps ? »Cette page est aussi l'entrée de la section DevOps. Ses trois blocs se lisent indépendamment de la formation, selon le besoin : comprendre les concepts, les mettre en œuvre dans une organisation, ou suivre un écosystème qui évolue vite.
| Partie | Ce qu'elle apporte |
|---|---|
| Fondamentaux | Le cadre conceptuel : culture, flux, sécurité intégrée, fiabilité, sans outillage spécifique |
| Implémentation | La mise en pratique organisationnelle : maturité, équipes, métriques, delivery |
| Veille | Rester à jour sur l'écosystème DevSecOps |
D'autres sections prolongent la formation sur des sujets qui méritent leur propre parcours : sécuriser (durcissement, RBAC, PKI), observabilité, infrastructure as code, cloud et orchestrateurs, où vit Kubernetes.
Ce que cette formation défend
Section intitulée « Ce que cette formation défend »La sécurité se prouve, elle ne se déclare pas. Un scanner intégré au pipeline qui n'a jamais bloqué un build ne protège rien : je préfère un contrôle unique qui casse réellement la livraison à cinq outils qui produisent des rapports que personne ne lit.
La supply chain n'est pas un chapitre optionnel. Les incidents récents, tj-actions, les vers npm de la famille Shai-Hulud, passent par le pipeline et les dépendances, pas par une faille applicative. C'est pourquoi SBOM, signature et provenance sont au cœur du parcours, au même rang que le scan de dépendances.
Un faux positif mal traité coûte plus cher qu'un vrai. Une équipe qui ignore cent alertes finit par ignorer la cent unième, la vraie. Je vous déconseille de supprimer une alerte sans date d'expiration ni justification écrite : c'est une dette qui ne se voit plus.
À retenir
Section intitulée « À retenir »- DevSecOps intègre la sécurité à chaque étape de la livraison, pas à la fin.
- La formation enseigne une méthode : risque, contrôle, emplacement, résultat, traitement.
- Elle suppose Linux, Git, les conteneurs, la CI/CD et les bases de Terraform acquis, et renvoie vers leurs formations.
- Seize modules suivent le cycle de livraison, en deux pistes, Essentiel et Complet, et les secrets passent avant le pipeline.
- Un dépôt unique se durcit de module en module, jusqu'au capstone.
- Tous les outils de référence sont open source et tournent en local.
- Après la formation, trois niveaux de carrière et sept spécialisations prolongent le socle commun.