Supply Chain Security: Signature Sigstore et SBOM Reels en CI/CD

Quand la porte derobee de XZ Utils (CVE-2024-3094) a failli atteindre les distributions Linux stables en mars 2024, le constat est devenu brutal: signer un tag GitHub ne suffit plus. La chaine logicielle est devenue cible prioritaire parce qu un seul mainteneur compromis pousse du code malveillant vers des millions de hotes en quelques heures. Chez Basilisk OffSec on travaille des deux cotes: on simule des attaques contre les pipelines clients et on aide les equipes a fermer les portes que l on a ouvertes. Cet article consolide ce que l on deploie reellement en CI/CD production avec Sigstore cosign, SLSA niveau 3 et SBOMs CycloneDX, avec un biais pragmatique plutot que conformite theatrale.

Premiere etape: abandonner la cle privee longue duree stockee dans un secret manager. Cosign keyless utilise l OIDC de GitHub Actions, GitLab CI ou Buildkite pour emettre un certificat ephemere via Fulcio, valide 10 minutes, et enregistre la signature dans Rekor, un log de transparence append-only. Cela elimine toute une categorie de fuites de cle de signature, qui fut le pivot de l incident CodeCov en 2021. Un workflow typique enchaine trois jobs: build reproductible, signature avec cosign sign --yes, attestation avec predicat SLSA Provenance v1.0. Sur des projets clients on a mesure 90 pour cent de reduction sur le temps de rotation des credentials apres migration des cles PGP vers le keyless, ce qui rejoint directement AppSec Shift-Left: SAST, SCA et Secrets Scanning sans Bloquer l Equipe.

Un SBOM n est pas un XML que personne ne lit. On genere du CycloneDX 1.6 avec Syft au moment du build, incluant les hashes SHA-256 de chaque composant, la licence SPDX et le fournisseur. Le fichier voyage a cote de l image OCI comme artefact reference, pas enseveli dans un bucket S3. Pour valider on lance Grype sur la pull request et en arriere-plan contre le registre, parce que les CVE recentes arrivent apres le merge. On combine avec du policy-as-code via Kyverno ou Conftest, bloquant le deploiement si le SBOM contient une dependance au-dessus de CVSS 7.0 sans exception documentee. Le meme schema de policy revient quand on discute de Hardening de Serveur Linux: CIS Benchmark Applique Sans Casser la Prod sur les serveurs de production.

SLSA (Supply-chain Levels for Software Artifacts) est devenu le framework de reference apres que Google et OpenSSF ont standardise la v1.0 en 2023. Niveau 1: simplement un build script versionne. Niveau 2: builder heberge avec provenance signee. Niveau 3, ou on veut atterrir sur les projets sensibles, exige isolation du build, provenance non falsifiable et hermetic builds. En pratique on utilise GitHub Actions avec le reusable workflow slsa-framework/slsa-github-generator, qui produit une attestation in-toto signee par le runner via OIDC. Un attaquant qui compromet un mainteneur doit encore casser le builder GitHub, ce qui augmente le cout de l attaque de plusieurs ordres de grandeur. Pour les equipes qui gerent aussi Dependency Confusion et Typosquatting: Defense Pratique pour Equipes Dev, SLSA boucle le cote publisher.

La verification cote consommateur compte autant que la signature cote producteur. Sur les clusters Kubernetes on deploie l admission webhook policy-controller de Sigstore avec une ClusterImagePolicy exigeant que toute image en namespace production porte une signature cosign valide, une identite OIDC du domaine basilisk.example et une attestation SLSA du builder attendu. On configure du soft-fail en staging pour ne pas bloquer un deploy d urgence, et hard-fail en prod. On execute aussi cosign verify-blob sur les binaires CLI telecharges sur les postes analystes, integre au flow decrit dans OPSEC pour Chercheurs en Securite: Modele de Menace Personnel, parce qu une equipe offensive telecharge beaucoup d outils d origine douteuse et cela devient un vecteur evident.

Ou ca casse en pratique: builds non reproductibles, timestamps embarques dans les binaires Go, dependances transitives qui derivent entre git pull et CI, et mainteneurs qui refusent la 2FA. Le projet XZ pre-2.0 montrait deja des signaux de takeover social qu aucune signature ne capture. On recommande donc de combiner cosign+SLSA+SBOM avec une revue periodique des mainteneurs critiques, OpenSSF Scorecard tournant chaque semaine sur le top 50 des dependances, et des exercices red team simulant un compromis de mainteneur, similaires aux engagements decrits dans Adversary Emulation avec Caldera et MITRE ATT&CK en Lab d'Entreprise et Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue. La technologie sans processus de maintenance vire au theatre couteux.

Takeaway pratique: commence petit et mesurable. Cette semaine, ajoute cosign sign keyless sur un pipeline unique, genere un SBOM CycloneDX avec Syft et publie-le comme artefact OCI a cote de l image. Sprint suivant, active cosign verify obligatoire sur un namespace staging. En 30 jours tu as de quoi exiger SLSA L2 de tes fournisseurs et repondre avec preuve quand le prochain XZ tombera, parce qu il tombera. Le cout d implementation sur un pipeline existant tourne autour de 2 a 4 heures d ingenieur; le cout de ne pas le faire c est repondre dimanche soir au telephone si oui ou non tu as signe ce conteneur qui mine du Monero en production.