L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.
Le fil rouge DevSecOps applique toute la formation à un seul service,
notes-api, une petite API Flask qui range des notes. Vous le faites
évoluer en douze versions, de V0 à V11 : un premier pipeline, puis un
modèle de menace, des portes de sécurité, une identité sans secret, une image
signée qu'un cluster sait refuser, et enfin un SLO et des métriques
DORA, avec une version annexe, V9b, qui ajoute la détection à l'exécution
sur une vraie machine. Chaque version est un lab dsoxlab dont cinq
contrôles jugent le résultat, pas les commandes tapées. Il s'adresse à celui qui a suivi les
modules de la formation et veut le prouver sur un cas complet, pendant près
de onze heures.
Le fil rouge tient en un seul dépôt, qui se durcit d'une version à
l'autre. Le point de départ d'une version est la solution de la
précédente : ce que vous construisez en V3 sert en V4, et rien ne se
recommence. Le dépôt de labs
devsecops-dsoxlab-training
porte les douze versions, leurs scénarios en français et en anglais, et leurs
solutions chiffrées.
Le modèle de menace sert de colonne vertébrale. Posé en V1, il nomme
chaque faiblesse de notes-api, de l'injection SQL de la recherche au
security group ouvert au monde, et chaque version en fait passer une ou
deux de open à mitigated, avec le fichier qui le prouve. À la fin,
treize menaces sur dix-huit sont traitées et une est acceptée. Les quatre
dernières restent ouvertes, et nommées : l'authentification absente de
notes-api et le journal de ses écritures relèvent de l'application, pas de sa
chaîne de livraison.
Chaque version cite aussi la pratique du NIST SSDF qu'elle met en œuvre,
le référentiel de développement sécurisé du NIST (SP 800-218). Les
contrôles jouent votre pipeline avec act, qui exécute GitHub Actions
en local, puis le rejouent sur des copies piégées du projet : un jeton
collé dans le code, un verrou vulnérable, une pull request qui exécute son
propre code. Votre pipeline doit passer sur le projet, et casser sur la copie.
Le fil rouge tourne sur votre poste, sans compte cloud ni cluster à
louer. Il faut un Docker qui répond, la CLI dsoxlab et l'outil
mise, qui installe les versions épinglées par le catalogue : act 0.2.89,
uv, Python, et à partir de V8 kind, kubectl, helm et cosign. Seule V9b
demande une machine virtuelle, que dsoxlab crée sur votre poste avec
KVM ou Incus.
dsoxlab run prépare le répertoire de travail du lab, dsoxlab check
lance ses cinq contrôles, vingt points chacun. Les versions V8 et V9
montent un cluster kind à un nœud, jetable, le temps des contrôles :
comptez trois à quatre minutes, le premier passage téléchargeant les
images du cluster et de Kyverno.
Le tableau donne, pour chaque version, ce que notes-api gagne, la
pratique SSDF visée et la leçon de la formation qui enseigne le
concept. Suivez-le dans l'ordre : chaque ligne suppose les précédentes.
Version
Ce que notes-api gagne
SSDF
Leçon qui l'enseigne
V0
Un pipeline qui installe le verrou et teste chaque push
Les treize labs se regroupent en quatre étapes. Chaque bloc ci-dessous dit
ce que la version vous demande et sur quoi portent ses contrôles. Ils
lisent ce que votre pipeline produit, ce que votre image embarque ou
ce que votre cluster admet, jamais la forme de votre YAML seule.
Fondations : un pipeline, un modèle de menace, deux portes
Les trois premières versions posent le socle. V0 écrit le pipeline qui
installe les dépendances verrouillées et lance les tests : les contrôles
vérifient qu'un test cassé et un uv.lock désynchronisé le font échouer. V1
ajoute le modèle de menace, confronté aux routes réelles de l'application.
V2 branche gitleaks et Semgrep en portes bloquantes, et la copie
piégée ajoute une route qu'aucun test ne couvre : seule l'analyse statique
peut l'arrêter.
La chaîne d'approvisionnement, de la dépendance à la provenance
Les cinq versions suivantes sécurisent ce que notes-api consomme et ce
qu'elle livre. V3 fait bloquer osv-scanner et distingue ce qui se
corrige de ce qui se trie : une vulnérabilité sans correctif reçoit une
exception datée, et une copie dont l'échéance est passée redevient rouge.
V4 remplace la clé AWS stockée par un échange OIDC : les contrôles
évaluent votre politique de confiance contre cinq jetons, et seul celui d'un
push sur main, destiné à STS, doit passer.
V5 audite les workflows eux-mêmes avec actionlint et zizmor, et
réécrit un workflow d'accueil qui exécutait le code des pull requests avec un
jeton en écriture. V6 analyse le Dockerfile, le Terraform et l'image
construite avec Trivy : les contrôles construisent votre image et
vérifient l'utilisateur qui l'exécute. V7 produit le SBOM de l'image,
le confronte au verrou, et attend un script qui refuse une archive dont la
provenance ne vient pas du pipeline de main.
Déployer et exécuter : le cluster refuse, le Pod est cloisonné
Les versions V8 et V9 suivent notes-api dans Kubernetes. V8 écrit les
politiques d'admission Kyverno de l'espace de noms : les contrôles
montent un cluster kind, un registre interne et Kyverno, puis demandent
l'admission d'une image signée, d'une non signée, d'une signée par une autre
clé et d'une image de Docker Hub. V9 impose le standard restricted des
Pod Security Standards et des NetworkPolicies : les contrôles mesurent le
trafic réel, depuis le contrôleur d'entrée, depuis un autre espace de noms et
depuis notes-api elle-même, qui ne doit sortir que vers le DNS.
V9b, version annexe, voit ce que ces protections ne disent pas : quand
quelqu'un est entré. Sur une machine Ubuntu que dsoxlab provisionne,
notes-api tourne dans Docker sous Falco 0.45.0 et sa sonde eBPF
moderne. Vous écrivez les règles qui signalent un shell ouvert dans son
conteneur et une écriture dans son code ; les contrôles provoquent ces
actions eux-mêmes, puis l'activité normale, qui ne doit rien déclencher.
Gouverner et mesurer : décisions écrites, fiabilité mesurée
Les deux dernières versions traitent ce qui reste quand tout bloque. V10
relève le seuil à MEDIUM : ce qui se corrige est corrigé, ce qui s'accepte
devient une exception datée avec sa raison, et un document VEX dit
aux exploitants des versions précédentes que pip, présent dans l'image de
base, n'affecte pas notes-api. V11 écrit le SLO sous forme d'alerte
Prometheus, le runbook vers lequel elle renvoie, et le calcul des quatre
métriques DORA. Pour un SLO de 99,5 %, l'alerte réveille l'astreinte quand
le budget d'erreurs brûle 14,4 fois trop vite, soit plus de 7,2 %
d'erreurs : les contrôles vérifient avec promtool que 10 % la déclenchent et
que 1 % ne la déclenche pas.
Un contrôle vert ne vaut que pour ce qu'il mesure, et le fil rouge le dit.
act ne fournit pas de jeton OIDC : sous act, un job qui s'authentifie
auprès d'AWS échoue de la même façon avec un rôle et avec une clé statique,
mesuré avec configure-aws-credentials v6.3.0. V4 et V7 jugent donc la
configuration de la publication, et exécutent la politique de confiance
et le script de vérification, sans pouvoir rejouer la signature keyless
elle-même.
La détection à l'exécution avec Falco n'entre pas dans V9 : elle exige
une vraie machine, pas un cluster qui partage le noyau de l'hôte. C'est
pourquoi V9b se joue sur une VM. Enfin,
les bases de vulnérabilités évoluent : une dépendance saine aujourd'hui
peut porter une CVE demain et faire échouer une version déjà réussie. C'est
le comportement attendu d'une porte bloquante, et le catalogue rejoue ses
solutions pour le détecter.
Deux pièges mesurés en construisant le fil rouge valent d'être connus hors
du lab. cosign 3.1 signe par défaut au nouveau format de bundle, que
Kyverno 1.19.1 ne trouve pas (« no signatures found ») : la signature se
fait avec --new-bundle-format=false. Et l'image python:3.12-slim du
3 octobre 2026 portait déjà une CVE HIGH de libpcre2 corrigée dans
Debian, d'où l'apt-get upgrade à chaque construction en V6.
Vérifiez que l'essentiel de cette leçon est acquis. Les questions portent
uniquement sur ce qui vient d'être expliqué ici.
Contrôle de connaissances
Validez vos connaissances avec ce quiz interactif
6 questions
6 min.
70% requis
Informations
Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin
Lance le quiz et démarre le chronomètre
⏱️--:--
0 / 6
Vérification
(0/0)
--:--
0%
0Correctes
0À revoir
0:00Temps
-Niveau
Score par domaine
Un domaine regroupe plusieurs guides et reçoit plusieurs questions : son score est plus fiable qu'un score par thème, qui porte souvent sur une seule question.
Bilan
Points forts
Aucun sujet réussi à 80 % sur au moins deux questions pour l’instant.
Points faibles
Aucun sujet sous le seuil de réussite.
À faire ensuite
Des indices pour retenter votre chance ?
Nouveau quiz complet avec des questions aléatoires
Les questions ci-dessous reviennent le plus souvent avant de démarrer le
fil rouge : durée totale, prérequis Kubernetes, outils à installer,
ordre des versions et ce que valent les contrôles des labs.
Le fil rouge est le capstone de la formation : un seul service, notes-api, que vous durcissez en douze versions. Chaque version part de la solution de la précédente et constitue un lab dsoxlab vérifié par cinq contrôles, du premier pipeline au SLO et aux métriques DORA.
Les treize labs totalisent près de onze heures de pratique : 30 minutes pour V0, une heure pour V6 et V11, autour de 50 minutes pour les autres. La lecture des leçons qui enseignent chaque concept s'y ajoute, si vous ne les avez pas encore suivies.
Non. Tout tourne sur votre poste : act joue les workflows GitHub Actions en local, V8 et V9 montent un clusterkind jetable, et V9b une machine virtuelle que dsoxlab crée avec KVM ou Incus. Il faut un Docker qui répond, la CLI dsoxlab et mise.
Oui : dsoxlab run prépare chaque version à partir de la solution de la précédente, déjà fournie. Suivre l'ordre reste pourtant conseillé, parce que chaque version suppose les gestes appris avant : on ne durcit pas un pipeline (V5) qu'on n'a jamais écrit (V0).
Ils jugent ce que le pipeline produit, ce que l'image embarque ou ce que le clusteradmet, jamais la forme du YAML seule. Puis ils rejouent le pipeline sur des copies piégées du projet, un jeton collé dans le code ou un verrou vulnérable, qui doivent le faire échouer.
act ne fournit pas de jeton OIDC : l'échange OIDC de V4 et la signature keyless de V7 ne se rejouent pas en local, leur configuration est donc relue et évaluée. La détection à l'exécution avec Falco, qui exige une vraie machine, se joue à part, en V9b, sur une VM.