Les Niveaux SLSA Expliqués : Checklist Pratique de Conformité

Introduction : Qu’est-ce que SLSA et pourquoi devriez-vous vous en soucier ?

Supply-chain Levels for Software Artifacts — SLSA (prononcé « salsa ») — est un framework de sécurité créé par Google et désormais maintenu par l’Open Source Security Foundation (OpenSSF). Son objectif est d’une simplicité trompeuse : rendre plus difficile pour les attaquants de falsifier les logiciels que vous construisez et distribuez.

Si vous avez suivi les incidents majeurs tels que SolarWinds, Codecov ou le flot de paquets npm malveillants, vous savez déjà pourquoi la sécurité de la chaîne d’approvisionnement est importante. SLSA vous donne un framework concret et incrémental pour savoir comment y remédier.

La spécification SLSA v1.0 (publiée en avril 2023) a simplifié le modèle original en une piste claire — les Build Levels 0 à 3 — chacun ajoutant des garanties plus fortes sur l’intégrité de votre processus de build et les métadonnées de provenance qu’il produit.

Ce guide passe en revue chaque niveau en langage clair, vous fournit une checklist que vous pouvez remettre à votre équipe lundi matin, associe chaque exigence à des outils concrets, montre à quoi ressemble réellement la provenance, et propose une feuille de route d’adoption étape par étape. C’est parti.

Aperçu rapide : le Build Track SLSA en un coup d’œil

Avant de plonger dans chaque niveau, voici un tableau comparatif pour avoir une vue d’ensemble.

Aspect	Build L0	Build L1	Build L2	Build L3
Processus de build	Aucune exigence	Build scripté et cohérent	Service de build hébergé	Builders renforcés et isolés
Provenance	Non requise	Existe et disponible	Authentifiée et générée par le service	Infalsifiable, signature isolée
Signataire de la provenance	N/A	Développeur ou CI	Le service de build lui-même	Service de build renforcé
Protection contre la falsification	Aucune	Erreurs et documentation	Falsification après le build	Falsification pendant et après le build
Effort d’adoption	Zéro	Faible — heures à jours	Moyen — jours à semaines	Élevé — semaines à mois

Build Level 0 — Le point de départ (aucune garantie)

Le Build L0 n’est pas vraiment un niveau — c’est l’absence totale de conformité SLSA. Tout projet logiciel commence ici par défaut.

Ce que cela signifie en langage clair

Vous n’avez aucune exigence formelle. Les builds peuvent être réalisés sur le portable d’un développeur, sans aucun enregistrement du code source utilisé, des commandes exécutées ou du résultat produit. Il n’y a pas de document de provenance. Il n’y a rien à vérifier.

Checklist

☐ Rien de requis — c’est le point de départ à partir duquel vous progressez.

À quoi ressemble la provenance au L0

Elle n’existe pas. Il n’y a pas d’attestation, pas de métadonnées, pas de signature. Si quelqu’un demande « prouvez que ce binaire provient de ce commit », la réponse honnête est : vous ne pouvez pas.

En résumé : Le L0 est là où se trouvent la plupart des organisations aujourd’hui. La bonne nouvelle ? Passer au L1 est étonnamment facile.

Build Level 1 — La provenance existe

Le L1 est la première étape significative. Sa promesse centrale : la provenance existe et le processus de build est scripté.

Exigences en langage clair

Build scripté — Le build est défini dans du code (un Makefile, un Dockerfile, un fichier YAML de pipeline CI), et non une série de commandes shell manuelles qu’un développeur exécute de mémoire.
La provenance est générée — Le build produit un document qui enregistre, au minimum, qui l’a construit, quel code source a été utilisé et quel processus de build a été exécuté.
La provenance est disponible — Les consommateurs peuvent effectivement télécharger et inspecter la provenance.

Checklist

☐ Le build est entièrement défini dans un script de build ou un fichier de configuration CI (aucune étape manuelle).
☐ Chaque build produit des métadonnées de provenance (format in-toto / SLSA provenance recommandé).
☐ La provenance enregistre : la plateforme de build, le dépôt source, le point d’entrée et les empreintes (digests) de l’artefact produit.
☐ La provenance est publiée aux côtés de l’artefact (par ex. dans un registre, un artefact OCI ou une URL publique).
☐ Le format de provenance suit le schéma SLSA Provenance v1.

Outils qui satisfont le L1

GitHub Actions — Utilisez les workflows réutilisables slsa-github-generator. Ils génèrent automatiquement la provenance SLSA.
GitLab CI — GitLab 15.x+ prend en charge l’attestation d’artefacts nativement.
SLSA Verifier — Le CLI slsa-verifier pour valider la provenance côté consommateur.
Sigstore / Cosign — Signez et stockez la provenance dans le journal de transparence de Sigstore (Rekor).
in-toto — Le framework in-toto fournit une spécification et des bibliothèques pour générer des attestations.

À quoi ressemble la provenance au L1

Un document de provenance SLSA v1 minimal au L1 pourrait ressembler à ceci (JSON simplifié) :

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [{
    "name": "my-app",
    "digest": { "sha256": "a1b2c3d4..." }
  }],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://github.com/slsa-framework/slsa-github-generator/...",
      "externalParameters": {
        "source": {
          "uri": "git+https://github.com/acme/my-app@refs/heads/main",
          "digest": { "sha1": "abc123..." }
        }
      }
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0"
      }
    }
  }
}

Point clé : Au L1, la provenance peut être auto-attestée — c’est le développeur ou son propre job CI qui la signe. C’est acceptable à ce niveau ; l’objectif est l’existence.

Build Level 2 — Provenance hébergée et authentifiée

Le L2 relève la barre : le build doit s’exécuter sur un service de build hébergé, et la provenance doit être générée et signée par ce service — et non par le développeur.

Exigences en langage clair

Plateforme de build hébergée — Les builds s’exécutent sur un service géré (GitHub Actions, GitLab CI, Google Cloud Build, Jenkins sur infrastructure gérée, etc.), et non sur le portable d’un développeur.
Provenance authentifiée — Le service de build lui-même génère et signe la provenance. Un développeur ne peut pas la falsifier ou la modifier.
Générée par le service — La génération de la provenance est une fonctionnalité de la plateforme de build, et non un script que le développeur peut modifier dans son dépôt.

Checklist

☐ Tous les builds de release s’exécutent sur un service CI/CD hébergé (aucun build local pour les artefacts de production).
☐ Le service de build génère la provenance — pas un script contrôlé par l’utilisateur.
☐ La provenance est signée par l’identité du service de build (par ex. signature keyless basée sur OIDC via Sigstore).
☐ La provenance inclut l’identité authentifiée du builder (vous pouvez vérifier quel service l’a produite).
☐ Les consommateurs peuvent vérifier la signature de la provenance par rapport à l’identité connue du service de build.
☐ Le dépôt source et le point d’entrée dans la provenance sont renseignés par le service, et non par des valeurs fournies par l’utilisateur.

Outils qui satisfont le L2

GitHub Actions + slsa-github-generator — Lorsque vous utilisez le workflow réutilisable (et non une action composite), le jeton OIDC de GitHub signe la provenance. Cela satisfait le L2 nativement.
Google Cloud Build — Produit nativement une provenance authentifiée pour les images de conteneurs stockées dans Artifact Registry.
Sigstore Fulcio + Rekor — Signature keyless avec des certificats éphémères liés à l’identité OIDC du CI. Le journal de transparence (Rekor) fournit un enregistrement infalsifiable.
Tekton Chains — Pour le CI natif Kubernetes. Tekton Chains génère et signe automatiquement la provenance SLSA pour les exécutions de pipelines Tekton.
SLSA Verifier — Côté consommateur, slsa-verifier verify-artifact vérifie la signature et l’identité du builder.

À quoi ressemble la provenance au L2

La structure JSON est similaire au L1, mais la différence essentielle est l’enveloppe de signature. La provenance est encapsulée dans un DSSE (Dead Simple Signing Envelope) :

{
  "payloadType": "application/vnd.in-toto+json",
  "payload": "",
  "signatures": [{
    "keyid": "",
    "sig": "MEUCIQD...base64...signature"
  }]
}

La signature provient de l’identité du service de build — vérifiée via le journal de transparence des certificats de Sigstore — et non de la clé personnelle d’un développeur. C’est ce qui rend la provenance authentifiée.

Build Level 3 — Builds renforcés

Le L3 est le standard le plus élevé dans SLSA v1.0. Il ajoute des garanties d’isolation : l’environnement de build est renforcé de sorte que même un script de build compromis ou une dépendance malveillante ne puisse falsifier la provenance ou affecter d’autres locataires du système de build.

Exigences en langage clair

Plateforme de build renforcée — Le service de build fournit une isolation forte entre les jobs de build (par ex. des VMs éphémères, et non des conteneurs partagés). Un job ne peut pas influencer un autre.
Provenance infalsifiable — La provenance est générée de manière à ce que le job de build lui-même (le code défini par l’utilisateur) ne puisse pas la modifier ou la falsifier. La clé de signature ou l’identité OIDC n’est pas accessible au script de build.
Secrets isolés — Le matériel de signature (clés, jetons OIDC utilisés pour la signature) est hors du contrôle du locataire. Même si le script de build est entièrement compromis, il ne peut pas produire une attestation de provenance valide pour un artefact qu’il n’a pas construit.

Checklist

☐ Les jobs de build s’exécutent dans des environnements éphémères et isolés (VMs, et non des runners partagés de longue durée).
☐ Les environnements de build sont fraîchement provisionnés pour chaque build et détruits après.
☐ Les étapes de build définies par l’utilisateur ne peuvent pas accéder à la clé ou au jeton de signature de la provenance.
☐ La plateforme empêche le build d’un locataire d’influencer celui d’un autre.
☐ La provenance est générée par la plateforme après la fin du build — et non en ligne avec le code utilisateur.
☐ Des builds hermétiques ou sandboxés sont utilisés dans la mesure du possible (pas d’accès réseau arbitraire pendant le build).
☐ L’identité du builder dans la provenance est une valeur vérifiée et contrôlée par la plateforme.
☐ Vous avez vérifié que le modèle de menace de votre plateforme de build documente comment elle satisfait l’isolation L3 de SLSA.

Outils qui satisfont le L3

GitHub Actions (avec les workflows réutilisables slsa-github-generator) — Les runners hébergés par GitHub utilisent des VMs éphémères. Le workflow réutilisable s’exécute dans un job séparé que le workflow appelant ne peut pas altérer. Cette architecture satisfait le L3 lorsque vous utilisez le slsa-github-generator officiel.
Google Cloud Build — Les builds s’exécutent sur des VMs éphémères avec une signature isolée. La documentation de Google mappe explicitement Cloud Build au SLSA L3.
Tekton Chains sur Kubernetes renforcé — Lorsque Tekton s’exécute sur des nœuds avec une isolation au niveau VM (par ex. gVisor, Kata Containers) et que Chains gère la signature de manière externe.
Buildkite avec des agents isolés — Lorsque les agents s’exécutent sur une infrastructure éphémère (instances EC2 auto-scalées terminées après chaque job).

À quoi ressemble la provenance au L3

Le format du document de provenance est le même qu’au L2 — une déclaration in-toto encapsulée dans une enveloppe DSSE. La différence ne réside pas dans le format mais dans les propriétés de confiance derrière la signature. Au L3 :

L’identité de signature est vérifiablement liée à une plateforme de build renforcée.
Le champ builder.id référence un builder reconnu comme satisfaisant les exigences d’isolation L3.
Les outils de vérification comme slsa-verifier vérifient l’identité du builder par rapport à une liste d’autorisation de builders conformes au L3.

# Vérifier un artefact au SLSA Build L3
slsa-verifier verify-artifact my-app-linux-amd64 \
  --provenance-path my-app-linux-amd64.intoto.jsonl \
  --source-uri github.com/acme/my-app \
  --builder-id https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0

Feuille de route d’adoption étape par étape

N’essayez pas de sauter directement au L3. SLSA est conçu pour une adoption incrémentale. Voici une feuille de route pratique.

Phase 1 : Atteindre le Build L1 (Semaine 1-2)

Auditez vos builds. Listez chaque artefact que vous livrez. Comment chacun est-il construit ? Sur le portable de qui ? Quel job CI ?
Scriptez tout. Si une étape de build est manuelle, déplacez-la dans votre configuration CI. Chaque build doit être reproductible à partir d’une seule commande ou d’un seul déclencheur.
Ajoutez la génération de provenance. Pour GitHub Actions, ajoutez le workflow réutilisable slsa-github-generator. Pour d’autres plateformes, intégrez la génération d’attestations in-toto dans votre pipeline.
Publiez la provenance. Attachez la provenance à vos artefacts de release. Pour les images de conteneurs, poussez-la comme un artefact OCI aux côtés de l’image. Pour les binaires, publiez le fichier .intoto.jsonl.
Vérifiez que cela fonctionne. Utilisez slsa-verifier pour confirmer que la provenance est valide et que l’empreinte de l’artefact correspond.

Phase 2 : Atteindre le Build L2 (Semaine 3-6)

Éliminez les builds locaux. Imposez une politique : aucun artefact de production n’est construit en dehors du CI. Utilisez des règles de protection de branches et des vérifications de statut obligatoires.
Passez à la provenance générée par le service. Passez de la provenance auto-attestée à la provenance générée par la plateforme. Avec GitHub Actions, cela signifie utiliser le workflow réutilisable (et non une action composite). Avec GCB, activez l’attestation intégrée.
Activez la signature keyless. Utilisez Sigstore Fulcio pour des certificats éphémères basés sur OIDC. Cela lie la signature à l’identité du CI, et non à une clé longue durée que vous gérez.
Ajoutez la vérification à votre pipeline de déploiement. Avant de déployer, exécutez slsa-verifier ou un moteur de politiques (comme Kyverno ou OPA Gatekeeper) pour vérifier la provenance de chaque artefact entrant en production.

Phase 3 : Atteindre le Build L3 (Mois 2-4)

Vérifiez le modèle d’isolation de votre plateforme. Lisez la documentation de sécurité de votre fournisseur CI. Utilise-t-il des VMs éphémères ? Un job peut-il accéder à l’environnement d’un autre ? Pour les runners hébergés par GitHub, la réponse est oui (éphémères) — pour les runners auto-hébergés, vous devrez probablement reconfigurer.
Migrez hors des runners partagés ou auto-hébergés (ou renforcez-les). Si vous utilisez des runners GitHub Actions auto-hébergés, passez à des instances éphémères auto-scalées (par ex. Actions Runner Controller avec des pods éphémères ou des groupes d’auto-scaling AWS).
Verrouillez le chemin de signature. Assurez-vous que la clé de signature ou le jeton OIDC utilisé pour la provenance n’est pas accessible aux étapes de build utilisateur. Avec les workflows réutilisables slsa-github-generator, cela est garanti par conception.
Documentez votre modèle de menace. Décrivez ce contre quoi votre plateforme de build protège et ce qu’elle ne couvre pas. Partagez-le avec votre équipe de sécurité pour revue.

Pièges courants

Même les équipes bien intentionnées trébuchent sur ces problèmes. Évitez-les dès le départ.

Utiliser une action composite au lieu d’un workflow réutilisable sur GitHub. Une action composite s’exécute à l’intérieur du job de l’appelant, ce qui signifie que l’appelant peut altérer la génération de provenance. Seul un workflow réutilisable s’exécute dans un job séparé et isolé. C’est la différence entre le L1 et le L2+ sur GitHub Actions.
Traiter la provenance comme une case à cocher. Générer de la provenance ne sert à rien si personne ne la vérifie. Mettez en place une vérification automatisée dans votre pipeline de déploiement — pas seulement dans un rapport d’audit.
Stocker les clés de signature dans le dépôt ou les variables d’environnement CI. Cela annule l’objectif. Utilisez la signature keyless (Sigstore) ou un KMS externe. L’identité de signature ne doit pas être accessible au script de build.
Ignorer les runners auto-hébergés. Les runners auto-hébergés sont souvent des VMs de longue durée partagées entre les jobs. Cela brise l’isolation L3. Passez à des runners éphémères ou utilisez une isolation au niveau VM.
Négliger la vérification des sources. Le Build Track SLSA se concentre sur le build. Mais si un attaquant peut pousser du code malveillant dans votre dépôt, un build parfaitement conforme ne fait que produire un artefact altéré avec une provenance valide. Associez SLSA à des contrôles de source solides (protection de branches, revue de code, signature de commits).

Questions fréquemment posées

SLSA est-il réservé aux images de conteneurs ?

Non. SLSA s’applique à tout artefact logiciel — binaires, paquets npm, Python wheels, Helm charts, modules Terraform, et bien plus. Le format de provenance (in-toto) est agnostique vis-à-vis du type d’artefact.

SLSA remplace-t-il le SBOM ?

Non. Ils sont complémentaires. Un SBOM (Software Bill of Materials) vous dit ce que contient l’artefact. La provenance SLSA vous dit comment il a été construit et d’où il vient. Utilisez les deux ensemble pour une visibilité complète de la chaîne d’approvisionnement.

Dois-je atteindre le L3 pour être « conforme » ?

Pas nécessairement. SLSA est un framework de maturité, pas une réglementation pass/fail. Le L1 est déjà une amélioration significative par rapport au L0. De nombreuses organisations visent le L2 comme un point d’équilibre pratique. Le L3 est destiné aux environnements à haute sécurité ou aux projets avec des exigences strictes en matière de chaîne d’approvisionnement (par ex. gouvernement, infrastructures critiques).

Quel est le lien entre SLSA et le NIST SSDF ou l’EO 14028 ?

L’Executive Order 14028 et le Secure Software Development Framework (SSDF) du NIST appellent tous deux à des pratiques de sécurité de la chaîne d’approvisionnement que SLSA soutient directement. La provenance SLSA et l’intégrité du build sont des implémentations concrètes des pratiques SSDF comme PS.1 (protéger le logiciel) et PW.4 (archiver et protéger les processus de build). Adopter SLSA vous aide à cocher de nombreuses cases dans ces frameworks.

Que faire si ma plateforme CI ne supporte pas SLSA nativement ?

Vous pouvez toujours générer de la provenance en utilisant les bibliothèques in-toto et la signer avec Sigstore. Cela vous amène au L1. Pour le L2+, vous devrez probablement ajouter une étape de génération de provenance qui s’exécute dans un job ou service séparé et de confiance que le build principal ne peut pas altérer.

Lectures complémentaires et ressources

Spécification officielle SLSA : slsa.dev/spec/v1.0
Format de provenance SLSA : slsa.dev/provenance/v1
slsa-github-generator : Dépôt GitHub
slsa-verifier : Dépôt GitHub
Sigstore : sigstore.dev
in-toto : in-toto.io
Notre guide de provenance SLSA : Provenance SLSA en profondeur
Atelier pratique : Atelier Provenance SLSA — Générez et vérifiez votre première attestation

Conclusion : Commencez au L1, livrez lundi

SLSA n’est pas un framework tout-ou-rien. L’objectif même du système de niveaux est de pouvoir commencer petit et progresser de manière incrémentale.

Voici votre plan d’action pour lundi matin :

Choisissez un artefact — votre binaire ou image de conteneur la plus critique.
Ajoutez la génération de provenance à son pipeline CI en utilisant slsa-github-generator ou l’équivalent de votre plateforme.
Publiez la provenance aux côtés de l’artefact.
Vérifiez-la avec slsa-verifier.
Célébrez. Vous êtes maintenant au SLSA Build L1 — en avance sur la grande majorité des projets logiciels.

Puis itérez. Passez au L2 en vous assurant que le service de build signe la provenance. Renforcez vos runners pour le L3. Chaque étape réduit matériellement votre risque lié à la chaîne d’approvisionnement.

Les attaques sur la chaîne d’approvisionnement continueront. La question n’est pas s’il faut adopter SLSA — c’est à quelle vitesse vous pouvez y arriver. Commencez dès aujourd’hui.