Formation DevSecOps : la sécurité dans toute la livraison

Cette formation apprend à intégrer la sécurité à chaque étape de la livraison logicielle, de la conception jusqu'au runtime (l'exécution en production), et à prouver que chaque contrôle fonctionne. DevSecOps consiste à placer ces contrôles dans la chaîne de livraison au lieu de les confier à un audit de fin de projet. La formation enseigne une méthode : quel risque on traite, quel contrôle le couvre, où le placer et comment démontrer qu'il bloque réellement. Elle compte 17 modules et 133 leçons, soit environ 86 heures en piste Complet. 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.

Que contient la formation DevSecOps et combien de temps demande-t-elle ?

Le programme réunit 133 leçons réparties en 17 modules, pour environ 86 heures de travail en piste Complet. Les modules suivent le cycle de livraison et se regroupent, hors la Présentation, en quatre niveaux, de d1 à d4, décrits dans la section sur l'organisation du programme.

Ce que vous suivez	Volume (piste Complet)
Modules	17
Leçons	133
Labs	30
Leçons avec un quiz de contrôle	130
Durée estimée	environ 86 heures
Pratique	des labs joués avec la CLI dsoxlab : ceux du fil rouge, dans le dépôt devsecops-dsoxlab-training, et douze repris des catalogues Python, Terraform, Docker et Kubernetes

Glissez pour voir

Ces volumes portent sur la piste Complet, qui contient toute la formation. La piste Essentiel en est un sous-ensemble plus court, décrite dans la section sur les deux pistes ; la page Mon parcours affiche les leçons de chacune. Les heures additionnent la lecture, les labs et les quiz : ce sont des ordres de grandeur, pas un temps de lecture.

À qui s'adresse cette formation ?

La formation 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 : les modules de DevSecOps y renvoient au lieu de la redire.

Prérequis	Pourquoi	Où l'apprendre
Linux	les conteneurs et les runners (les machines qui exécutent les pipelines) 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, pour le niveau d3 en piste Complet	les leçons de déploiement et de runtime et les labs Kubernetes supposent kubectl, un espace de noms et un Deployment	Formation Kubernetes

Glissez pour voir

Kubernetes n'est pas un prérequis pour commencer, et la piste Essentiel n'en demande pas les bases. Seul le niveau d3 en piste Complet en suppose les bases : le module « Déploiement contrôlé » n'a aucune leçon en Essentiel, les labs V8 et V9 montent un cluster kind local (un Kubernetes qui tourne dans des conteneurs Docker sur votre poste), et les labs repris de la formation Kubernetes tournent sur des machines virtuelles où un cluster, installé avec l'outil kubeadm, est déjà prêt. Suivez la formation Kubernetes avant le niveau d3 si vous visez le Complet.

L'Essentiel connaît une seule exception : l'épreuve V11 exige, dans un runbook (la procédure écrite à suivre en cas d'incident), la commande kubectl rollout undo, qu'une leçon d'Essentiel présente.

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 par le module « Culture et flux ». Un non : passez d'abord par la formation correspondante ; une lecture ciblée de ses modules suffit souvent.

Une méthode, pas un catalogue de scanners

Un parcours organisé outil par outil, avec un chapitre sur l'analyse statique du code (SAST), un sur le test de l'application en marche (DAST) et un sur le scan d'image, laisse au lecteur le travail de relier chaque scanner au risque qu'il couvre. Ici, chaque contrôle se présente dans le même ordre : le risque, la classe de contrôle (la famille d'outils qui y répond, comme l'analyse statique), l'endroit où la placer dans la chaîne, le résultat qu'elle produit et la façon de 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 (le projet libre de signature d'artefacts)
Secrets chiffrés dans Git	SOPS	fichiers relus en revue de code
Conformité	CINC Auditor	profils InSpec (des règles de conformité écrites en code), distribution libre
Détection runtime	Falco	projet gradué de la CNCF, la fondation qui héberge Kubernetes

Glissez pour voir

Tous ces outils sont open source et tournent en local, sans cloud payant. Les alternatives (detect-secrets, KICS, OpenSCAP, Tetragon) restent documentées sur le site, hors du parcours.

Un seul projet, notes-api, qui se durcit de version en version

Plutôt que des exercices isolés, la formation suit un produit unique, notes-api, une petite API Flask qui range des notes. Vous la faites évoluer en douze versions, de V0 à V11, avec une version annexe V9b : un premier pipeline, un modèle de menace, des portes de sécurité (des contrôles qui font échouer le pipeline), une identité sans secret, une image signée qu'un cluster sait refuser, enfin un objectif de fiabilité (SLO) et des métriques de performance de livraison (DORA). Chaque version est un lab dont cinq contrôles jugent le résultat produit, jamais la forme de votre YAML seule.

La page du fil rouge liste les treize labs et, pour chacun, la leçon qui enseigne le geste : vous le pratiquez juste après cette leçon.

Huit leçons, reprises des formations Python, Terraform, Docker et Kubernetes, portent des labs de ces catalogues, douze en tout :

• deux labs Python, portés par les leçons pipeline-ci et sbom du niveau d2, en pistes Essentiel et Complet ;
• deux labs Terraform, portés par deux leçons du module « Build, conteneurs et IaC », au niveau d2 : la première en pistes Essentiel et Complet, la seconde en piste Complet seulement ;
• un lab Docker, porté par la leçon sur l'utilisateur d'une image, au niveau d2, en pistes Essentiel et Complet, sur machine virtuelle ;
• sept labs Kubernetes, répartis sur trois leçons du niveau d3, en piste Complet.

Quelle piste choisir : Essentiel ou Complet ?

La piste Essentiel garde la colonne vertébrale : une leçon par geste indispensable, de la culture au runtime des conteneurs, sans le volet Kubernetes du déploiement. La piste Complet ajoute les approfondissements, le volet Kubernetes du déploiement et la gouvernance détaillée. Deux modules n'ont aucune leçon en Essentiel : « Déploiement contrôlé » et « Généraliser à l'échelle ».

Le choix de piste décide aussi des versions du fil rouge que vous pratiquez, et donc de ce que vous prouvez. Pour ces versions, les objectifs ne se répartissent pas de la même façon dans les deux pistes, comme le montre ce tableau.

Ce que vous pratiquez dans le fil rouge	Version	Piste
Analyser les risques d'une application	V1	Essentiel et Complet
Bloquer secrets, failles et dépendances vulnérables avant le merge	V2 et V3	Essentiel et Complet
Construire une image sans privilège	V6	Essentiel et Complet
Traiter une vulnérabilité jusqu'à sa clôture, avec des exceptions datées et un VEX	V10	Essentiel et Complet
Publier par identité courte, sans secret stocké (OIDC)	V4	Complet seulement
Auditer les workflows et contenir les pull requests	V5	Complet seulement
Produire un SBOM et prouver la provenance d'un artefact	V7	Complet seulement
Faire refuser une image non signée par un cluster	V8	Complet seulement

Glissez pour voir

Trois termes du tableau sont nouveaux pour qui débute en sécurité de la chaîne logicielle. L'OIDC (OpenID Connect) permet au pipeline de s'authentifier auprès d'un service avec un jeton de courte durée, au lieu d'une clé enregistrée dans le dépôt. Un SBOM est l'inventaire des composants d'un logiciel, et la provenance prouve où et comment il a été construit. Un VEX indique, pour une faille connue, si elle est exploitable dans votre produit.

La page du fil rouge dit, pour chaque version, la piste dont elle relève, y compris pour celles qui ne figurent pas dans ce tableau. Les douze labs repris des catalogues Python, Terraform, Docker et Kubernetes, présentés plus haut, s'ajoutent à ces versions avec la piste indiquée pour chacun.

Comment suivre sa progression dans le parcours DevSecOps ?

Chaque leçon porte une case à cocher, et votre progression est enregistrée dans votre navigateur, sans compte ni inscription obligatoires. La page Mon parcours affiche le programme complet, module par module, avec le pourcentage d'avancement, et un sélecteur filtre l'affichage selon la piste (Essentiel ou Complet).

Dans chaque leçon, le plan du cours en colonne de gauche rappelle où vous en êtes ; en bas, un bouton marque la leçon comme lue sans quitter la page ; un lien « Passer à la leçon suivante » apparaît alors à côté de la confirmation. Votre progression reste la même quelle que soit la piste affichée.

Comment le programme est-il organisé, niveau par niveau ?

Le programme avance en quatre niveaux, de d1 à d4, qui regroupent les modules dans l'ordre où un changement traverse la chaîne de livraison. Chaque niveau porte un résultat attendu et une épreuve, un lab noté sur l'état produit plutôt que sur les commandes tapées. Les niveaux ordonnent le programme et commandent l'affichage du parcours.

Niveau d1 : comprendre le flux et les risques

Vous lisez un système de livraison comme un flux, vous situez où la sécurité s'y insère et vous modélisez les menaces d'une application. Le niveau regroupe les modules « Culture et flux », « Le système de livraison », « Fondamentaux DevSecOps » et « Threat modeling ». L'épreuve est le lab V1, « un modèle de menace : STRIDE sur notes-api, vérifié par le pipeline », jouable en piste Essentiel. STRIDE est une grille qui classe les menaces en six familles, de l'usurpation d'identité au déni de service.

Niveau d2 : sécuriser la chaîne de livraison

Vous sécurisez le code, les dépendances, les secrets, la CI/CD, le build et la chaîne d'approvisionnement, jusqu'à la provenance des artefacts. Le niveau regroupe « Sécuriser le code et les dépendances », « Secrets et identités machine », « Sécuriser la CI/CD », « Build, conteneurs et IaC » et « Software supply chain ». Les secrets viennent volontairement avant la sécurité du pipeline. Le secret zéro est le premier secret qu'il faut bien confier au pipeline pour qu'il accède aux autres : l'OIDC le remplace par un jeton de courte durée, et on n'en voit l'intérêt qu'après avoir compris ce problème.

L'épreuve est le lab V7, « SBOM et provenance : savoir ce qu'on livre, prouver d'où ça vient ». Elle n'existe qu'en piste Complet : en Essentiel, ce niveau n'a pas d'épreuve jouable.

Niveau d3 : protéger la production

Vous contrôlez ce qui se déploie, vous protégez le runtime, vous gérez les vulnérabilités et les exceptions, puis vous observez et répondez aux incidents. Le niveau regroupe « Déploiement contrôlé », « Sécurité du runtime », « Vulnérabilités, exceptions et conformité » et « Observer et répondre ».

L'épreuve est le lab V9, « l'exécution cloisonnée : Pods restreints et réseau fermé ». Elle n'existe qu'en piste Complet et monte le cluster local kind. Elle ne mesure que le runtime : le déploiement contrôlé (V8), la détection à l'exécution (V9b) et les exceptions (V10) restent des pratiques du niveau, sans épreuve propre.

Niveau d4 : mesurer et généraliser

Vous mesurez la démarche, vous la pilotez et vous l'étendez à l'échelle de l'organisation, jusqu'au capstone, le projet de synthèse qui assemble tout le parcours. Le niveau regroupe « Mesurer et piloter », « Généraliser à l'échelle » et « Capstone ».

L'épreuve est le lab V11, « mesurer la fiabilité : un SLO qui réveille, un runbook, les métriques DORA », jouable en piste Essentiel. Un SLO est l'objectif de fiabilité que l'équipe se fixe, et les métriques DORA mesurent la performance de livraison, par exemple la fréquence de déploiement. L'épreuve ne mesure que cette part : aucun lab n'évalue le volet « généraliser » (les Security Champions, ces développeurs relais de la sécurité dans leur équipe, et la plateforme interne), qui s'apprend par les leçons et leurs quiz.

Où trouver les labs et sur quel environnement se jouent-ils ?

Les labs du fil rouge vivent dans le dépôt devsecops-dsoxlab-training et se jouent avec la CLI dsoxlab, sur votre poste. Les autres labs viennent des dépôts python-dsoxlab-training, terraform-dsoxlab-training, containers-dsoxlab-training et kubernetes-dsoxlab-training, et la leçon qui les porte les décrit. Pour les labs du fil rouge, il faut Docker installé et démarré, uv (un gestionnaire d'outils Python) pour installer dsoxlab, et l'outil mise, qui installe les versions épinglées par le catalogue, dont act, l'outil qui rejoue GitHub Actions en local. Aucun compte cloud n'est nécessaire pour le fil rouge.

uv tool install dsoxlab
git clone https://github.com/stephrobert/devsecops-dsoxlab-training.git
cd devsecops-dsoxlab-training
mise install
dsoxlab run   capstone-v00-pipeline-minimal
dsoxlab check capstone-v00-pipeline-minimal

dsoxlab run prépare le répertoire de travail du lab et dsoxlab check lance ses contrôles. Trois précisions sur l'environnement :

• à partir de V8, mise installe aussi kind, kubectl, helm et cosign, et les labs V8 et V9 montent un cluster kind jetable ;
• parmi les labs du fil rouge, seule V9b demande une machine virtuelle, que dsoxlab crée sur votre poste avec KVM ou Incus ; les labs repris du catalogue Kubernetes tournent aussi sur des machines virtuelles, avec un cluster kubeadm déjà installé, et le lab Docker repris au niveau d2 (leçon sur l'utilisateur d'une image) tourne lui aussi sur machine virtuelle, y compris pour un apprenant de l'Essentiel ;
• douze des treize labs du fil rouge jouent GitHub Actions avec act, V9b étant le seul à ne pas le faire : le prérequis accepte GitLab CI, mais aucun lab de cette formation ne joue un pipeline GitLab CI.

Act n'injecte pas dans les jobs les variables qui donnent accès à un jeton OIDC de GitHub. Une signature sans clé (keyless) qui s'appuie sur ce jeton ne se rejoue donc pas en local non plus : certaines preuves du fil rouge se lisent dans les contrôles plutôt qu'elles ne s'exécutent de bout en bout. Les commandes ci-dessus sont celles de la page du fil rouge, qui reste la référence si elles évoluent ; elle donne aussi les versions d'act et de cosign.

Comment se valident les acquis ?

Un quiz vérifie que vous avez compris pourquoi, un lab que vous savez faire, et l'épreuve de chaque niveau que vous le savez sur un cas complet. Les quiz couvrent la plupart des leçons, et le lab d'un niveau note l'état final de votre dépôt plutôt que les commandes tapées.

Le capstone assemble ces preuves sur un seul dépôt. Ses contrôles lisent ce que le pipeline produit, ce que l'image embarque ou ce que le cluster admet. Comme les épreuves de d2 et de d3 n'existent qu'en piste Complet, un apprenant de l'Essentiel franchit deux lignes d'arrivée, V1 et V11. Il pratique aussi V2, V3, V6 et V10 du fil rouge et des labs repris, mais sans épreuve de niveau pour d2 et d3 : il lit le reste par les leçons et leurs quiz.

Pour approfondir, hors du parcours

Ces pages ne font pas partie de la progression, pour qu'elle reste finissable. Elles prolongent un module quand un sujet vous concerne directement :

• Code : OSV-Scanner
• Pipeline : runners auto-hébergés, Jenkins
• Conteneurs et IaC : namespaces et cgroups, capabilities et seccomp, OPA et Conftest
• Supply chain : Syft
• Secrets : OpenBao, secrets Kubernetes
• Runtime : audit logs Kubernetes

Que faire après la formation ?

La formation donne le socle commun, pas un métier : le DevSecOps mène à des trajectoires distinctes selon qu'on privilégie la sécurité applicative, la fiabilité, la plateforme, le cloud ou les pipelines. Le catalogue des métiers décrit les responsabilités et le parcours de chacune, et le catalogue des certifications liste celles que le site prépare avec des labs et des examens blancs. Une certification valide un socle reconnu par les recruteurs, elle ne remplace pas la pratique sur des incidents réels : visez-la quand les bases qu'elle suppose sont acquises.

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. La formation recommande donc un contrôle unique qui casse réellement la livraison plutôt que cinq outils qui produisent des rapports que personne ne lit : un contrôle qui bloque se remarque et se corrige, un rapport ignoré ne change rien. Un contrôle bloquant demande en contrepartie d'être réglé avec soin, sinon les faux positifs arrêtent les livraisons pour rien.

La supply chain n'est pas un chapitre optionnel. Par supply chain, on entend tout ce qui entre dans votre logiciel : dépendances, outils de build et pipeline. Des incidents récents, comme celui de tj-actions ou les vers npm de la famille Shai-Hulud, décrits dans Attaques via les gestionnaires de paquets en CI/CD, passent par le pipeline et les dépendances plutôt que par une faille de l'application. C'est pourquoi SBOM, signature et provenance sont au cœur du parcours, au même rang que le scan de dépendances.

Une alerte mal traitée coûte cher, même fausse. Une équipe qui ignore cent alertes finit par ignorer la cent unième, la vraie. La formation déconseille de supprimer une alerte sans date d'expiration ni justification écrite : une alerte écartée sans trace devient une dette qui ne se voit plus, alors qu'une exception datée et justifiée revient en revue à l'échéance.

Lecture conseillée

Le vocabulaire du premier niveau vient en grande partie d'un roman d'entreprise : The Phoenix Project, Gene Kim raconte le redressement d'une DSI au bord de la rupture. C'est une porte d'entrée accessible aux Three Ways (les trois principes du DevOps : le flux, le retour d'information et l'apprentissage continu), à la notion de flux et à celle de goulot d'étranglement.

Lien affilié Amazon. Acheter via ce lien soutient le site sans surcoût pour vous.

À retenir

• DevSecOps intègre la sécurité à chaque étape de la livraison, pas à la fin, et 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 ; Kubernetes n'est requis que pour le niveau d3 en piste Complet.
• Les modules se regroupent en quatre niveaux, d1 à d4, chacun clos par un lab noté sur l'état produit ; d2 et d3 n'ont d'épreuve qu'en piste Complet.
• Deux pistes, Essentiel et Complet, partagent le même programme et la même progression ; V1 et V11 sont les seules épreuves jouables en Essentiel.
• Les secrets passent avant la sécurité du pipeline, parce qu'un pipeline sans secret statique s'appuie sur l'OIDC.
• Un projet unique, notes-api, se durcit de version en version : ses treize labs sont dans le dépôt devsecops-dsoxlab-training et se jouent sur votre poste, avec GitHub Actions rejoué par act ; douze labs d'autres catalogues s'y ajoutent, portés par huit leçons.
• Tous les outils de référence sont open source et tournent en local, sans cloud payant.

FAQ : questions fréquentes

Ces questions portent sur la formation elle-même : l'ordre à suivre, le choix de la piste, le besoin de Kubernetes, la plateforme de CI jouée par les labs et la façon dont les acquis se valident.

Par où commencer pour apprendre le DevSecOps ?

Quelle différence entre la piste Essentiel et la piste Complet ?

Faut-il apprendre Kubernetes avant la formation DevSecOps ?

Les labs se jouent-ils avec GitLab CI ou GitHub Actions ?

Quels outils faut-il connaître ?

Comment les acquis sont-ils validés ?

×

📖 Voir la documentation →