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.

Pourquoi la chaine logicielle est devenue la cible

Un attaquant a deux routes vers votre production: la porte d entree (attaquer vos services exposes) ou la porte derobee (compromettre quelque chose auquel vous faites deja confiance). La porte derobee passe mieux a l echelle. L incident SolarWinds a montre qu un processus de build altere frappe 18 000 organisations d un coup. XZ a montre qu un attaquant patient gagne la confiance sociale sur deux ans, obtient les droits de mainteneur, et plante une backdoor qui ne se declenche que sous des conditions tres precises.

Le denominateur commun: le maillon le plus faible n est jamais la cryptographie, c est la chaine humaine et procedurale autour du build. C est pourquoi la reponse n est pas une seule technologie mais une chaine de signature (qui l a construit), de provenance (comment et ou il a ete construit) et d inventaire (ce qu il y a dedans). Un maillon manquant et vous volez a l aveugle. L incident CodeCov de 2021, ou une credential fuitee a altere un script uploader bash, fut le reveil pour la couche de signature.

Cosign keyless: Fulcio et Rekor

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. Un workflow typique enchaine trois jobs: build reproductible, signature avec cosign sign --yes, attestation avec predicat SLSA Provenance v1.0.

L interet du log de transparence: meme si un attaquant obtient brievement une identite OIDC valide, toute signature est enregistree publiquement et de maniere immuable. Vous pouvez retroactivement demander quels artefacts ont ete signes avec quelle identite et a quel moment, et chasser les anomalies. 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.

SBOM avec Syft et CycloneDX

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. Un appel reel: syft packages dir:. -o cyclonedx-json=sbom.json. Le fichier voyage a cote de l image OCI comme artefact reference, lie a l image via cosign attest --predicate sbom.json --type cyclonedx, pas enseveli dans un bucket S3 que personne ne retrouvera dans six mois.

La valeur d un SBOM apparait le jour du prochain zero-day. Quand une CVE critique surgit dans une dependance transitive, la question n est pas abstraite mais operationnelle: lesquelles de nos 200 images en execution contiennent la version vulnerable? Sans SBOM c est de l archeologie sur plusieurs jours. Avec un inventaire SBOM interrogeable c est une requete de minutes. C est exactement pour cela qu on lie le SBOM a l artefact et non a une page wiki.

Scan avec Grype et Policy-as-Code

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. Une image propre hier peut porter une vulnerabilite critique aujourd hui sans qu une seule ligne de code ne change. 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 mecanisme d exception compte. Une policy dure sans chemin d exception documente est contournee des qu elle bloque un deploy urgent, et alors elle est morte. On utilise un fichier VEX (Vulnerability Exploitability eXchange) pour declarer qu une CVE donnee n est pas exploitable dans le contexte precis, avec justification et date d expiration. 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.

Comprendre les niveaux SLSA

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 ou le build n a pas d acces reseau non controle.

Le saut decisif est entre le Niveau 2 et le 3: une provenance que le builder lui-meme genere et signe ne peut pas etre falsifiee par un developpeur compromis, car il ne controle pas le processus du builder. Pour les equipes qui gerent aussi Dependency Confusion et Typosquatting: Defense Pratique pour Equipes Dev, SLSA boucle le cote publisher, tandis que la reservation de namespace et le pinning de registre couvrent le cote consommateur.

Provenance avec slsa-github-generator

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. Cette attestation documente de maniere cryptographiquement verifiable le commit source, les parametres de build et la version de la toolchain. 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.

Le point de rupture le plus frequent ici, ce sont les builds non reproductibles. Les timestamps embarques dans les binaires Go, les chemins absolus et les build IDs integres font que deux builds du meme commit produisent des hashes differents. Mettez -trimpath, fixez SOURCE_DATE_EPOCH et verrouillez la toolchain dans un lockfile, sinon votre provenance est signee mais pas reproductible de facon verifiable.

Verification cote consommateur

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. Le principe: signez a l origine, verifiez au point de consommation, et ne faites jamais confiance a un artefact simplement parce qu il est dans votre registre.

Limites: takeover social et Scorecard

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: un nouveau contributeur qui gagne la confiance de facon suspecte, une pression sur le mainteneur original, et des commits avec des donnees de test obfusquees.

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.

Pinning de registre et digests immuables

Signature et provenance servent a peu si vos deploiements referencent un tag mobile comme :latest. Un :latest verifie hier peut pointer sur une autre image aujourd hui. En production, pinnez toujours sur le digest immuable (image@sha256:...), pas sur un tag. Le digest est l empreinte cryptographique du contenu exact de l image; un digest pinne plus une signature verifiee donnent une chaine ininterrompue du commit source au conteneur en execution.

Completez avec un registre interne miroir (Harbor, Artifactory) executant un pull-through cache avec des regles d immutabilite, pour qu un tag upstream supprime ou ecrase ne casse pas vos builds et qu un attaquant ne puisse pas re-lier un tag deja verifie. Combine a une allowlist de registres autorises dans l admission controller, vous fermez la breche par laquelle passent les attaques de dependency confusion.

Rollout en 30 jours

Cette semaine: ajoutez cosign sign keyless sur un pipeline unique, generez un SBOM CycloneDX avec syft et publiez-le comme artefact OCI a cote de l image. Semaine prochaine: activez grype dans la PR avec une policy warn-only pour calibrer votre bruit de fond CVE. Semaine trois: activez cosign verify obligatoire sur un namespace staging en soft-fail. Semaine quatre: passez en hard-fail en prod pour un unique service bien compris et etendez a partir de la.

FAQ

Le keyless exige-t-il un acces internet au build? Oui, Fulcio et Rekor sont des services en ligne. Pour des environnements air-gap vous exploitez une instance privee Sigstore (Fulcio, Rekor, Trillian) en interne ou vous revenez a cosign base sur cle avec une cle detenue dans un KMS/HSM. Le keyless est la recommandation par defaut, pas un dogme.

Un SBOM remplace-t-il le scan de vulnerabilites? Non. Le SBOM est l inventaire, le scanner est l analyse contre lui. Un SBOM sans rescan continu contre des feeds CVE a jour vieillit en quelques jours. Ensemble ils donnent une image interrogeable et actuelle de votre surface d attaque; seuls ils sont des demi-mesures.

Comment vendre le cout au management? Pas avec des arguments de conformite mais avec le calcul du temps de reponse. Lors de la derniere grande CVE OpenSSL, les equipes sans inventaire SBOM ont mis des jours en moyenne juste pour identifier quels systemes etaient affectes. Les equipes avec SBOM lie ont repondu a la meme question en minutes et ont commence a patcher immediatement. Cette difference se traduit directement en risque de panne et en heures supplementaires, et c est exactement ce que comprend un responsable de budget.

Takeaway pratique: commence petit et mesurable. 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.