Ce lab construit de zéro un projet Python dont le pipeline GitHub Actions passe les quatre scanners de workflow (actionlint, zizmor, poutine, plumber) à zéro finding, publie une image signée avec une provenance SLSA et un SBOM vérifiables, et maximise honnêtement OpenSSF Scorecard. Il se compose de 5 guides à suivre dans l'ordre, adossés à un dépôt public reproductible. Les vulnérabilités applicatives sont couvertes par Trivy. Il s'adresse à un lecteur avancé qui veut une référence exécutable, pas une recette magique : chaque décision est expliquée, pourquoi ce réglage, quel contrôle il satisfait, quel piège il évite.
Que construit exactement ce lab ?
Section intitulée « Que construit exactement ce lab ? »Le lab produit une chaîne complète : cinq jobs de CI, un build attesté, une publication sur GHCR et une double mesure de posture. Le schéma ci-dessous la résume : quatre analyses lancées en parallèle (lint, tests, SAST, audit) plus un build-check, soit les cinq jobs du CI, un build attesté (provenance SLSA, SBOM, signature Cosign), une publication sur GHCR, puis une double mesure, la posture avec OpenSSF Scorecard et l'exploitabilité réelle avec Plumber.
Le projet fil rouge est une API Python (FastAPI) volontairement minimale. Ce n'est pas l'application qui compte, mais la chaîne qui la construit, l'atteste et la publie. À la fin du lab, chaque image publiée porte :
- une attestation de provenance SLSA signée (Sigstore keyless, log Rekor) ;
- un SBOM (CycloneDX) attesté et lié au digest dans le registre ;
- une signature Cosign vérifiable, plus un
provenance.intoto.jsonlattaché à la release.
Et le dépôt lui-même est gouverné : protection de branche par ruleset, revue code-owner obligatoire, Dependabot avec quarantaine, et une posture mesurée par OpenSSF Scorecard.
Où trouver le dépôt de référence ?
Section intitulée « Où trouver le dépôt de référence ? »Tout le lab s'appuie sur le dépôt public stephrobert/secure-python-pipeline, que vous pouvez consulter, cloner et forker pour reproduire chaque étape à l'identique. Rien n'y est masqué : les workflows publiés sont ceux que les guides commentent, ligne par ligne.
Vous le trouvez à l'adresse github.com/stephrobert/secure-python-pipeline. github.com/stephrobert/secure-python-pipeline.
git clone https://github.com/stephrobert/secure-python-pipelineVous y trouverez les sept workflows (CI, release, CodeQL, Scorecard, fuzzing,
plumber, vérification SLSA), le Dockerfile durci, les dépendances
hash-lockées et les fichiers de gouvernance (SECURITY.md, CODEOWNERS,
dependabot.yml). Les guides qui suivent citent le code de ce dépôt tel quel :
aucun extrait n'est reconstruit de mémoire, chaque commande a été exécutée et
validée avant d'être documentée.
À qui s'adresse ce lab ?
Section intitulée « À qui s'adresse ce lab ? »Ce lab s'adresse aux personnes qui écrivent déjà des workflows GitHub Actions et veulent les porter au niveau d'une référence de sécurité. Si vous n'avez encore jamais écrit de workflow, commencez par les fondations GitHub Actions : le lab suppose acquis la syntaxe, les jobs et les secrets.
La connaissance des concepts de supply chain (SLSA, SBOM, Sigstore) aide, mais chaque notion est rappelée au fil des étapes.
Quels sont les 5 guides du lab, et dans quel ordre les suivre ?
Section intitulée « Quels sont les 5 guides du lab, et dans quel ordre les suivre ? »Le lab se suit dans l'ordre, du bootstrap au scoring : chaque guide consomme
ce que le précédent a produit. Commencer par le pipeline sans avoir posé le
socle mène au même endroit à chaque fois, un workflow qui échoue sur des
dépendances non verrouillées et un Dockerfile qui tourne en root.
-
Bootstrap sécurisé pose le socle : dépôt, gouvernance, application FastAPI, dépendances verrouillées par hash,
Dockerfilenon-root. Tout est validé en local avant le moindre workflow. -
Pipeline CI durci écrit le workflow d'intégration et le fait passer les quatre scanners de workflow,
actionlint,zizmor,poutineetplumber, sans exception tolérée. -
Build vérifiable ajoute la provenance SLSA native, le SBOM attesté et la signature Cosign keyless, toutes vérifiables par un tiers.
-
Protection et gouvernance protège la branche par un ruleset, impose la revue code-owner et outille les scanners avec un token GitHub App.
-
Scoring et durcissement maximise honnêtement OpenSSF Scorecard et vise le badge OpenSSF Best Practices sur
bestpractices.dev.
Pour aller plus loin
Section intitulée « Pour aller plus loin »- Lab 1 : bootstrap sécurisé : Le socle du projet, des dépendances verrouillées par hash au
Dockerfilenon-root, validé en local. - Lab 2 : pipeline CI durci : Le workflow d'intégration qui passe actionlint, zizmor, poutine et plumber sans exception tolérée.
- Lab 3 : build vérifiable : La provenance SLSA, le SBOM attesté et la signature Cosign, tous vérifiables par un tiers.
- Lab 4 : protection et gouvernance : Le ruleset, la revue code-owner et le token GitHub App qui alimente les scanners.
- Lab 5 : scoring et durcissement : La note OpenSSF Scorecard obtenue honnêtement, et le badge Best Practices en ligne de mire.