En 2020, des attaquants ont compromis le système de build de SolarWinds Orion et glissé la porte dérobée SUNBURST dans une mise à jour signée, légitime, distribuée à 18 000 clients. Le binaire était correctement signé. Le SBOM, s'il avait existé, aurait listé des composants parfaitement sains. Le problème n'était ni dans le code source ni dans la liste des dépendances : il était dans la chaîne de build elle-même. Personne ne pouvait prouver que le binaire livré sortait bien du commit annoncé. C'est précisément cette preuve que SLSA apporte.
SBOM et provenance ne répondent pas à la même question
Le SBOM répond à « quoi » : quels composants, quelles bibliothèques, quelles versions, quelles dépendances transitives composent un livrable. Indispensable, mais insuffisant. Un SBOM ne dit rien de la façon dont l'artefact a été produit. Il ne prouve pas que le binaire que vous déployez sort bien du commit que vous croyez, buildé par le pipeline que vous croyez, sans étape malveillante insérée entre les deux.
La provenance répond à « comment ». C'est un enregistrement vérifiable qui décrit l'origine d'un artefact : quelle source (quel dépôt, quel commit), quel builder l'a produit, avec quels paramètres, à quel moment. SBOM et provenance se complètent. L'un inventorie le contenu, l'autre certifie la fabrication. SolarWinds est précisément un cas où le contenu était propre et la fabrication compromise.
SLSA (Supply-chain Levels for Software Artifacts, prononcé « salsa ») est le cadre qui formalise tout ça. Né chez Google, maintenu par l'OpenSSF depuis. La version 1.0 de la spécification est sortie en avril 2023. Elle découpe les exigences en pistes (tracks), dont la principale, la piste Build, structure la confiance qu'on peut accorder à la fabrication d'un artefact.
Les niveaux de build, du déclaratif au prouvé
La piste Build de SLSA v1.0 définit des niveaux croissants. Chacun ajoute une garantie contre une classe de menace précise.
Le niveau 1 exige une provenance générée automatiquement par le build, qui décrit comment l'artefact a été produit. Mais cette provenance n'est pas signée. Elle est juste des métadonnées : n'importe qui ayant accès à l'artefact peut la forger. L1 donne de la visibilité, sans rien empêcher. C'est un premier pas honnête, rien de plus. Sans gate de vérification au déploiement, un attaquant qui vole les credentials de publication peut remplacer un artefact L3 signé par un artefact L1 à la provenance bidon, et personne ne le voit.
Le niveau 2 ajoute deux choses : la provenance est générée par un service de build hébergé (GitHub Actions, Google Cloud Build, et non plus le poste d'un développeur), et elle est signée numériquement. Le consommateur peut vérifier l'authenticité et l'intégrité. On passe de « on vous dit comment c'est buildé » à « on vous le prouve, et la preuve résiste à la falsification simple ».
Le niveau 3 durcit la plateforme de build elle-même. Environnement de build isolé et éphémère, recréé pour chaque build, pour empêcher qu'un build en contamine un autre. Plateforme durcie qui isole les exécutions même au sein du même projet. Matériel de signature inaccessible aux étapes de build définies par l'utilisateur : un build compromis ne peut pas voler la clé qui signe la provenance. À L3, la plateforme résiste à la plupart des attaques connues sur la chaîne d'approvisionnement, y compris l'injection de code d'un build vers un autre projet.
La progression est claire : provenance existante, puis signée, puis émise par un builder isolé et durci. Chaque niveau ferme une porte que le précédent laissait entrouverte.
La provenance, concrètement : une attestation in-toto signée
Sous le capot, la provenance SLSA prend la forme d'une attestation in-toto. Quand une plateforme conforme génère la provenance, elle produit une attestation in-toto avec le predicateType https://slsa.dev/provenance/v1, la signe via DSSE (Dead Simple Signing Envelope) et la rattache à l'artefact via le champ subject. SLSA définit les exigences et le modèle de menace, in-toto fournit le format de données et le cadre de vérification.
Le contenu de l'attestation est ce qui compte : le digest de l'artefact (son empreinte), l'identité du builder, le point d'entrée du build, les paramètres invoqués, les matériaux d'entrée. De quoi rejouer mentalement la fabrication et détecter toute divergence : un commit source précis, un builder identifié, des paramètres figés. Si quelqu'un altère l'attestation, la signature DSSE saute.
Signer et vérifier avec Sigstore et cosign
C'est là que Sigstore et cosign entrent en jeu. Le modèle de signature sans clé (keyless) règle le problème historique de la gestion des clés privées : il n'y en a pas à stocker.
Le mécanisme tient en trois pièces. Le workflow GitHub Actions s'authentifie via son identité OIDC. Fulcio, l'autorité de certification de Sigstore, émet un certificat à durée de vie courte lié à cette identité OIDC. Rekor, le journal de transparence en append-only, enregistre l'événement de signature de façon immuable et publiquement vérifiable. L'identité du workflow de build devient le credential de signature, et la preuve atterrit dans un log public.
Côté vérification, cosign verify-attestation fait le travail. Il valide la signature, contrôle la chaîne de certificats contre des racines de confiance, vérifie que le certificat était valide au moment de la signature. Au-delà de la signature, cosign sait appliquer une politique de vérification écrite en CUE ou en Rego : on n'accepte pas seulement « c'est signé », on impose « c'est signé par tel workflow, depuis tel dépôt, sur telle branche ». La gate devient une assertion sur l'origine du build, pas un simple contrôle de présence.
En pratique, atteindre le L3 sans tout réécrire passe souvent par le slsa-github-generator. Ce workflow réutilisable produit des provenances conformes SLSA niveau 3 pour n'importe quel projet GitHub. Il signe la provenance avec cosign et s'exécute dans un environnement isolé contrôlé par les mainteneurs du framework, ce qui satisfait l'exigence L3 de plateforme de build durcie et non falsifiable. Pour un projet déjà outillé en scan d'images comme Trivy, c'est l'étape logique au-dessus : on ne se contente plus de chercher des vulnérabilités dans l'artefact, on certifie sa fabrication.
Pourquoi maintenant : SolarWinds, puis xz
SLSA a été créé en réponse directe à SolarWinds. Le cadre formalise ce qui aurait permis de détecter SUNBURST : une provenance vérifiable aurait révélé que le binaire livré ne correspondait pas à une fabrication propre depuis la source légitime.
L'affaire xz-utils, en mars 2024, a confirmé l'angle a posteriori. Un mainteneur infiltré sur la durée, une backdoor glissée dans les artefacts de release sans correspondance propre avec l'arbre source public. Là encore, une chaîne de fabrication vérifiable de bout en bout aurait donné un point de contrôle. Ces deux affaires ont la même morale : la signature de l'artefact final ne suffit pas si on ne peut pas prouver comment il a été fabriqué. SLSA déplace la confiance du « qui a signé » vers le « comment ça a été produit, et est-ce vérifiable ».
Provenance signée ou décoration
Le SBOM seul ne protège pas contre une compromission du build. Si votre chaîne livre des artefacts critiques, la provenance n'est pas optionnelle. La bonne nouvelle : la marche L1 ne coûte rien, juste activer la génération de provenance. La marche qui compte vraiment, c'est L2 vers L3, et le slsa-github-generator l'offre sans réarchitecturer le pipeline pour qui est déjà sur GitHub Actions.
La règle qu'on applique : provenance signée systématique sur tout artefact destiné à la production, et une politique de vérification cosign au déploiement qui contrôle l'identité du builder, pas seulement la présence d'une signature. Une signature qu'on ne vérifie pas avec une politique stricte ne sert à rien : elle prouve juste que quelque chose a signé quelque chose. La valeur est dans l'assertion sur l'origine. Sans cette gate au déploiement, la provenance est de la décoration. Cette logique prolonge une démarche DevSecOps où chaque étape du cycle ajoute une preuve vérifiable, pas une case cochée.
Sources
- SLSA Security levels, spécification v1.0 : la définition officielle des niveaux de build L0 à L3 et des menaces couvertes.
- SLSA Provenance, spécification v1.0 : le format de l'attestation de provenance et le predicateType in-toto.
- OpenSSF Announces SLSA Version 1.0 Release : l'annonce de la v1.0 et le découpage en pistes.
- General availability of SLSA 3 Container Generator for GitHub Actions : le slsa-github-generator et la signature via OIDC GitHub.
- cosign verify-attestation, documentation Sigstore : la commande de vérification et les politiques CUE/Rego.
