Lab : pipeline GitHub sécurisé de bout en bout

10 min

Par Stéphane Robert mis à jour le 13 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Ce lab construit de zéro un projet Python dont les workflows passent à zéro finding les quatre scanners de workflow, actionlint, zizmor et poutine lancés en local, plumber en gate bloquant dans la CI, 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 ?

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.

Source · SVG

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.jsonl attaché à 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 ?

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.

git clone https://github.com/stephrobert/secure-python-pipeline

Vous 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 ?

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 ?

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, Dockerfile non-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, poutine et plumber, 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.

À retenir

Le lab ne vaut pas par son application FastAPI, mais par la chaîne qui la construit, l'atteste et la publie.
Les cinq guides se suivent dans l'ordre : chacun consomme ce que le précédent a produit.
Les workflows passent les quatre scanners, actionlint, zizmor, poutine et plumber, sans exception tolérée.
Chaque image publiée porte une provenance SLSA, un SBOM attesté et une signature Cosign vérifiables par un tiers.
Le dépôt de référence est public : tout extrait cité se compare au code réellement exécuté.