Ce lab construit, de zéro, un projet Python dont le pipeline GitHub Actions vise l'excellence de sécurité : une image durcie et signée, une provenance SLSA et un SBOM vérifiables par un tiers, et un pipeline qui passe tous les scanners de workflow (actionlint, zizmor, poutine, plumber) à zéro finding, scanne les vulnérabilités avec Trivy et maximise OpenSSF Scorecard. Il s'adresse à un lecteur avancé qui veut une référence reproductible, pas une recette magique. Chaque décision est expliquée : pourquoi ce réglage, quel contrôle il satisfait, quel piège il évite.
Aller droit au but
Section intitulée « Aller droit au but »Ce que le lab construit
Section intitulée « Ce que le lab construit »Le schéma ci-dessous résume la chaîne que vous allez bâtir : 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.
Le dépôt de référence, public et reproductible
Section intitulée « Le dépôt de référence, public et reproductible »Tout le lab s'appuie sur un dépôt public, que vous pouvez consulter, cloner et forker pour reproduire chaque étape à l'identique : 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 »Aux personnes qui écrivent déjà des workflows GitHub Actions et veulent les porter au niveau d'une référence de sécurité. La connaissance des concepts de supply chain (SLSA, SBOM, Sigstore) aide, mais chaque notion est rappelée au fil des étapes.
Le parcours en 5 guides
Section intitulée « Le parcours en 5 guides »Le lab se suit dans l'ordre : chaque guide s'appuie sur le précédent.
-
Bootstrap pose le socle : dépôt, gouvernance, application, dépendances par hash, image durcie. On valide tout 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, poutine, plumber).
-
Build vérifiable ajoute la provenance SLSA, le SBOM attesté et la signature Cosign, toutes vérifiables.
-
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.