Provenance des Artefacts et Attestations : De SLSA à in-toto

Introduction

La signature de code est depuis longtemps un pilier de la sécurité logicielle. Lorsque vous vérifiez une signature, vous savez qui a signé un artefact. Mais savoir qui a signé quelque chose ne vous dit pas comment il a été construit, où il a été construit, ni quel code source a été utilisé. Un mainteneur pourrait signer un binaire compilé sur un ordinateur portable compromis avec des dépendances injectées — et la signature serait tout de même valide.

C’est la lacune que la provenance des artefacts comble. La provenance est un enregistrement vérifiable de la manière dont un artefact logiciel a été produit. Elle capture la plateforme de build, le dépôt source, le point d’entrée, les paramètres de build et les dépendances impliquées. Combinée aux signatures, la provenance offre aux consommateurs une image complète : non seulement « qui se porte garant de cet artefact », mais « quel processus l’a réellement créé ».

Dans ce guide, nous explorerons les deux frameworks les plus importants dans ce domaine — SLSA (Supply-chain Levels for Software Artifacts) et in-toto — et nous parcourrons leur mise en œuvre pratique dans les pipelines CI/CD modernes. Que vous soyez un ingénieur plateforme sécurisant votre infrastructure de build ou un développeur cherchant à comprendre ce que le niveau 3 de SLSA exige réellement, cet article vous fournira la profondeur technique nécessaire.

Qu’est-ce que la provenance des artefacts ?

La provenance des artefacts est une métadonnée qui décrit l’origine et le processus de build d’un artefact logiciel. Considérez-la comme un reçu de build : un document structuré et signé qui répond à trois questions fondamentales :

Où l’artefact a-t-il été construit ? (Quelle plateforme de build, quel runner, quel environnement ?)
Comment a-t-il été construit ? (Quelle commande de build, quelle configuration, quel point d’entrée ?)
À partir de quoi a-t-il été construit ? (Quel dépôt source, quel commit, quelles dépendances ?)

Provenance vs. Signatures

Les signatures et la provenance sont complémentaires mais servent des objectifs différents :

Une signature lie une identité à un artefact. Elle prouve qu’un détenteur de clé spécifique a approuvé ou produit l’artefact. Elle ne dit rien sur le processus de build.
La provenance lie un processus de build à un artefact. Elle prouve qu’une révision source spécifique a été transformée en artefact par une plateforme de build spécifique utilisant des paramètres spécifiques.

Vous avez besoin des deux. Une signature sans provenance est une déclaration de type « faites-moi confiance ». Une provenance sans signature est une affirmation non vérifiée. Ensemble, elles fournissent une preuve d’intégrité, une auditabilité et une base pour l’application automatisée de politiques.

Pourquoi la provenance est importante

La provenance répond à plusieurs risques critiques de la chaîne d’approvisionnement :

Preuve d’intégrité : Si un attaquant modifie un artefact après sa construction, la provenance ne correspondra pas. S’il modifie le processus de build, la provenance reflétera un builder ou une configuration différents de ceux attendus.
Auditabilité : Lorsqu’une vulnérabilité est découverte, la provenance vous permet de retracer exactement quel commit source et quelle configuration de build ont produit l’artefact affecté.
Conformité : Des frameworks comme le NIST SSDF et les décrets exécutifs sur la sécurité de la chaîne d’approvisionnement logicielle exigent de plus en plus la provenance comme contrôle de base.
Politique automatisée : Les contrôleurs d’admission et les portes de déploiement peuvent vérifier la provenance de manière programmatique, en imposant que seuls les artefacts construits par des plateformes de confiance à partir de dépôts approuvés soient déployés.

Le framework SLSA

SLSA (prononcé « salsa ») est un framework de sécurité développé à l’origine chez Google et maintenant maintenu par l’OpenSSF. Il définit un modèle de maturité pour la sécurité de la chaîne d’approvisionnement, avec la provenance en son cœur. SLSA ne prescrit pas d’outils spécifiques — il définit des exigences que les outils et les plateformes doivent satisfaire.

Le modèle de build SLSA

SLSA modélise la chaîne d’approvisionnement logicielle comme un pipeline simple :

Source → Plateforme de Build → Artefact

Chaque étape présente des menaces distinctes. La source peut être altérée (commits malveillants, VCS compromis). La plateforme de build peut être compromise (scripts de build modifiés, dépendances injectées). L’artefact peut être altéré après le build (empoisonnement du registre, attaque de l’homme du milieu). SLSA répond à chacune de ces menaces par des exigences de plus en plus strictes à chaque niveau.

Les niveaux SLSA (v1.0)

SLSA v1.0 définit quatre niveaux de build, chacun s’appuyant sur le précédent :

Niveau de Build 1 — La provenance existe

Le processus de build génère une provenance décrivant comment l’artefact a été produit.
Le format de provenance suit la spécification SLSA.
La provenance n’a pas besoin d’être signée ni générée par la plateforme de build elle-même.
Menace traitée : Fournit une base pour l’auditabilité. N’empêche pas la falsification.

Niveau de Build 2 — Build hébergé, provenance signée

Le build s’exécute sur une plateforme de build hébergée (pas un poste de travail de développeur).
La provenance est signée par la plateforme de build, pas par le mainteneur du projet.
La provenance est générée par le service de build lui-même et ne peut pas être modifiée par le locataire du build.
Menace traitée : Empêche le locataire du build de falsifier la provenance. Les consommateurs peuvent vérifier l’identité du service de build.

Niveau de Build 3 — Plateforme de build renforcée

La plateforme de build fournit une isolation forte entre les locataires de build (par exemple, environnements éphémères et sandboxés).
La provenance est infalsifiable : même un locataire de build compromis ne peut pas créer de fausse provenance pour un autre projet.
Les builds s’exécutent dans des environnements hermétiques avec des dépendances contrôlées et déclarées.
Menace traitée : Empêche un build compromis d’affecter d’autres projets. Empêche les builds d’utiliser des dépendances non déclarées.

Niveau de Build 4 — Revue à deux parties et builds hermétiques

Toutes les modifications de source nécessitent une revue à deux parties avant d’être acceptées dans le build.
Les builds sont entièrement hermétiques : toutes les dépendances sont déclarées et récupérées de manière reproductible.
La plateforme de build est entièrement isolée et auditable.
Menace traitée : Empêche un seul initié d’injecter du code malveillant qui est construit et distribué.

Spécification de la provenance SLSA

SLSA définit un format de provenance spécifique qui doit inclure :

Identité du builder : Quelle plateforme de build a produit l’artefact (par exemple, GitHub Actions, Google Cloud Build).
Configuration du build : Le point d’entrée et les paramètres du build (par exemple, le fichier de workflow, la commande de build).
Référence source : Le dépôt source et le digest du commit qui a été construit.
Matériaux : Une liste de toutes les entrées du build, y compris les dépendances et leurs digests.
Métadonnées : Horodatages, identifiants d’invocation et autres métadonnées de build.

Cette provenance est exprimée sous forme de document JSON structuré, plus précisément comme une attestation in-toto — ce qui nous amène à la section suivante.

Le framework d’attestation in-toto

in-toto est un framework pour sécuriser les chaînes d’approvisionnement logicielles par le biais de métadonnées signées cryptographiquement. Alors que SLSA définit ce que la provenance doit contenir et quel niveau de sécurité elle fournit, in-toto définit le format de données et le mécanisme de signature utilisés pour représenter et vérifier cette provenance.

Layout et métadonnées de lien in-toto

Dans le modèle original d’in-toto, une chaîne d’approvisionnement est décrite par deux types de métadonnées :

Layout : Un document signé par le propriétaire du projet qui définit les étapes attendues de la chaîne d’approvisionnement, qui est autorisé à effectuer chaque étape, et quelles règles d’inspection doivent être appliquées lors de la vérification.
Métadonnées de lien : Des preuves signées produites par chaque étape de la chaîne d’approvisionnement, enregistrant les matériaux (entrées) et les produits (sorties) de cette étape.

Ce modèle est puissant pour les chaînes d’approvisionnement multi-étapes où vous devez vérifier que l’étape A a produit la sortie X, qui a ensuite été consommée par l’étape B pour produire la sortie Y, chaque étape étant effectuée par un acteur autorisé.

Le format d’attestation in-toto

Le format moderne d’attestation in-toto (ITE-6) généralise le modèle original en un framework flexible et extensible. Une attestation comporte trois couches :

1. Statement : L’enveloppe extérieure qui lie un prédicat à un ou plusieurs sujets.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "my-artifact",
      "digest": {
        "sha256": "a1b2c3d4e5f6..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": { ... }
}

2. Predicate : Les métadonnées réelles concernant l’artefact. Différents types de prédicats servent différents objectifs :

https://slsa.dev/provenance/v1 — Provenance SLSA (informations de build)
https://spdx.dev/Document — SBOM au format SPDX
https://cyclonedx.org/bom — SBOM au format CycloneDX
https://in-toto.io/attestation/vulns — Résultats d’analyse de vulnérabilités

3. Subject : Une ou plusieurs références d’artefacts, chacune identifiée par un nom et un ensemble de digests cryptographiques. Cela lie le prédicat à des artefacts spécifiques.

DSSE (Dead Simple Signing Envelope)

Les attestations in-toto sont encapsulées dans un DSSE (Dead Simple Signing Envelope) pour la signature. DSSE résout plusieurs problèmes des approches de signature précédentes :

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

DSSE signe à la fois le type de payload et le payload ensemble (en utilisant un PAE — Pre-Authentication Encoding), empêchant les attaques de confusion où une signature pour un type de payload est réutilisée pour un autre. Il prend en charge les signatures multiples, permettant des scénarios de signature multi-parties.

Comment in-toto se rapporte à SLSA

La relation est simple : la provenance SLSA est un type de prédicat in-toto. Lorsqu’une plateforme de build conforme à SLSA génère une provenance, elle produit une attestation in-toto avec predicateType: https://slsa.dev/provenance/v1, la signe avec DSSE, et l’associe à l’artefact construit 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 framework de vérification.

Génération de la provenance en CI/CD

Parcourons les implémentations pratiques dans les plateformes CI/CD les plus courantes.

GitHub Actions : slsa-github-generator

Le projet slsa-framework/slsa-github-generator fournit des workflows réutilisables qui génèrent une provenance SLSA de niveau 3 sur GitHub Actions. La provenance est générée par un workflow hébergé et isolé que le locataire du build ne peut pas altérer.

Pour les artefacts génériques :

name: SLSA Provenance for Generic Artifacts
on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      digests: ${{ steps.hash.outputs.digests }}
    steps:
      - uses: actions/checkout@v4
      - name: Build artifact
        run: |
          go build -o my-binary ./cmd/app
      - name: Generate subject digest
        id: hash
        run: |
          DIGEST=$(sha256sum my-binary | base64 -w0)
          echo "digests=$DIGEST" >> "$GITHUB_OUTPUT"
      - uses: actions/upload-artifact@v4
        with:
          name: my-binary
          path: my-binary

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      contents: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@v2.1.0
    with:
      base64-subjects: ${{ needs.build.outputs.digests }}
      upload-assets: true

Pour les images de conteneurs :

name: SLSA Provenance for Container Images
on:
  push:
    tags:
      - "v*"

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      image: ${{ steps.build.outputs.image }}
      digest: ${{ steps.build.outputs.digest }}
    permissions:
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.ref_name }}

  provenance:
    needs: [build]
    permissions:
      actions: read
      id-token: write
      packages: write
    uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@v2.1.0
    with:
      image: ${{ needs.build.outputs.image }}
      digest: ${{ needs.build.outputs.digest }}
      registry-username: ${{ github.actor }}
    secrets:
      registry-password: ${{ secrets.GITHUB_TOKEN }}

Attestations d’artefacts GitHub

GitHub propose désormais des attestations d’artefacts natives via actions/attest-build-provenance. C’est plus simple que le générateur SLSA et produit des attestations signées par Sigstore stockées dans l’API d’attestation de GitHub.

name: Build and Attest
on:
  push:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/checkout@v4
      - name: Build binary
        run: go build -o my-binary ./cmd/app
      - name: Attest build provenance
        uses: actions/attest-build-provenance@v2
        with:
          subject-path: my-binary
      - name: Attest container image
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

GitLab CI : Génération de métadonnées de provenance

GitLab ne dispose pas encore d’un générateur de provenance SLSA natif au même niveau de maturité que celui de GitHub, mais vous pouvez générer et signer des métadonnées de provenance en utilisant directement les outils du framework SLSA.

stages:
  - build
  - provenance

build:
  stage: build
  image: golang:1.22
  script:
    - go build -o my-binary ./cmd/app
    - sha256sum my-binary > checksums.txt
  artifacts:
    paths:
      - my-binary
      - checksums.txt

generate-provenance:
  stage: provenance
  image: ghcr.io/slsa-framework/slsa-generator-generic:v2.1.0
  needs: [build]
  script:
    - |
      cat > provenance.json <<PROV
      {
        "_type": "https://in-toto.io/Statement/v1",
        "subject": [
          {
            "name": "my-binary",
            "digest": {
              "sha256": "$(sha256sum my-binary | awk '{print $1}')"
            }
          }
        ],
        "predicateType": "https://slsa.dev/provenance/v1",
        "predicate": {
          "buildDefinition": {
            "buildType": "https://gitlab.com/gitlab-ci",
            "externalParameters": {
              "repository": "${CI_PROJECT_URL}",
              "ref": "${CI_COMMIT_SHA}"
            }
          },
          "runDetails": {
            "builder": {
              "id": "https://gitlab.com/${CI_PROJECT_PATH}/-/runners/${CI_RUNNER_ID}"
            },
            "metadata": {
              "invocationId": "${CI_PIPELINE_URL}",
              "startedOn": "${CI_PIPELINE_CREATED_AT}"
            }
          }
        }
      }
      PROV
    - cosign attest-blob --predicate provenance.json --type slsaprovenance my-binary
  artifacts:
    paths:
      - provenance.json

Stockage de la provenance dans les registres OCI

Pour les images de conteneurs, les attestations de provenance sont généralement stockées aux côtés de l’image dans le registre OCI en utilisant le modèle d’attestation Cosign. L’attestation est stockée comme un artefact OCI séparé lié à l’image par son digest :

# Attacher la provenance à une image de conteneur dans le registre
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  --key cosign.key \
  ghcr.io/myorg/myimage@sha256:abc123...

# Pour la signature sans clé avec Sigstore
cosign attest --predicate provenance.json \
  --type slsaprovenance \
  --yes \
  ghcr.io/myorg/myimage@sha256:abc123...

Cette approche tire parti de l’API referrers de la spécification de distribution OCI, qui permet aux clients de découvrir les attestations associées à un manifeste d’image donné. Des outils comme cosign et crane peuvent alors récupérer et vérifier ces attestations lors du déploiement.

Vérification de la provenance

Générer la provenance n’est que la moitié de l’histoire. Les consommateurs — qu’il s’agisse d’opérateurs humains ou de systèmes automatisés — doivent vérifier la provenance avant de faire confiance à un artefact.

CLI slsa-verifier

L’outil slsa-verifier vérifie la provenance SLSA générée par des builders de confiance (actuellement les builders basés sur GitHub Actions).

# Vérifier un artefact générique
slsa-verifier verify-artifact my-binary \
  --provenance-path my-binary.intoto.jsonl \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

# Vérifier une image de conteneur
slsa-verifier verify-image ghcr.io/myorg/myimage@sha256:abc123... \
  --source-uri github.com/myorg/myrepo \
  --source-tag v1.2.3

Le vérificateur contrôle les éléments suivants :

La signature de la provenance est valide et remonte à une racine de confiance (Sigstore pour les builders GitHub Actions).
L’identité du builder correspond à un builder de confiance connu.
Le dépôt source correspond au dépôt attendu.
Le digest de l’artefact correspond au sujet dans la provenance.

cosign verify-attestation

Pour une vérification plus flexible, cosign verify-attestation vous permet de vérifier les attestations in-toto attachées aux images de conteneurs avec filtrage par type :

# Vérifier l'attestation de provenance SLSA
cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity "https://github.com/myorg/myrepo/.github/workflows/release.yml@refs/tags/v1.2.3" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/myorg/myimage@sha256:abc123...

# Vérifier avec une politique CUE
cosign verify-attestation \
  --type slsaprovenance \
  --policy policy.cue \
  ghcr.io/myorg/myimage@sha256:abc123...

# Vérifier avec une politique Rego
cosign verify-attestation \
  --type slsaprovenance \
  --policy policy.rego \
  ghcr.io/myorg/myimage@sha256:abc123...

gh attestation verify

Pour les artefacts attestés avec la fonctionnalité d’attestation native de GitHub, le CLI gh fournit une vérification intégrée :

# Vérifier un artefact local
gh attestation verify my-binary \
  --owner myorg

# Vérifier une image de conteneur
gh attestation verify oci://ghcr.io/myorg/myimage@sha256:abc123... \
  --owner myorg

# Télécharger et inspecter le bundle d'attestation
gh attestation download my-binary \
  --owner myorg \
  --output attestation.jsonl

Provenance dans les contrôleurs d’admission

Pour les portes de déploiement en production, les contrôleurs d’admission peuvent appliquer automatiquement des politiques de provenance. Voici un exemple utilisant le policy-controller de Sigstore dans un cluster Kubernetes :

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-slsa-provenance
spec:
  images:
    - glob: "ghcr.io/myorg/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subject: "https://github.com/myorg/*"
      attestations:
        - name: must-have-slsa-provenance
          predicateType: https://slsa.dev/provenance/v1
          policy:
            type: cue
            data: |
              predicateType: "https://slsa.dev/provenance/v1"
              predicate: buildDefinition: {
                buildType: =~"^https://github.com/slsa-framework/slsa-github-generator/"
              }

Que vérifier lors de la validation

Quel que soit l’outil utilisé, la vérification de la provenance doit confirmer :

Identité du builder : L’artefact a-t-il été construit par une plateforme de build de confiance ? Vérifiez l’identifiant du builder dans la provenance par rapport à une liste blanche connue.
Dépôt source : La provenance fait-elle référence au dépôt source et au commit attendus ? Cela empêche les artefacts provenant de forks ou de dépôts non autorisés d’être déployés.
Déclencheurs de build : Le build a-t-il été déclenché par un événement attendu (push vers un tag de release, merge vers main) ? Cela détecte les artefacts construits à partir de branches ou d’événements inattendus.
Digest de l’artefact : L’artefact que vous vérifiez correspond-il au digest du sujet dans la provenance ? C’est la vérification fondamentale d’intégrité.
Fraîcheur de la provenance : La provenance est-elle récente ? Une provenance obsolète pour d’anciens builds peut ne pas refléter la posture de sécurité actuelle.

Défis pratiques

La provenance et SLSA sont des concepts puissants, mais l’adoption dans le monde réel s’accompagne de défis significatifs. Une évaluation honnête aide les équipes à planifier des stratégies d’adoption réalistes.

Atteindre le niveau SLSA 3+ est difficile

Le niveau SLSA 3 exige des environnements de build renforcés et isolés — et c’est là que la plupart des organisations rencontrent des frictions. Les builds hermétiques signifient que chaque dépendance doit être explicitement déclarée et récupérée via des canaux contrôlés. Pas de téléchargement de packages aléatoires depuis Internet pendant le build. Pas d’accès réseau à des services non déclarés.

Pour de nombreux projets, cela nécessite des changements fondamentaux dans le fonctionnement des builds. Les langages avec des écosystèmes de packages riches (Node.js, Python, Go) ont souvent des processus de build qui téléchargent implicitement des dépendances. Passer à un modèle hermétique signifie vendoriser les dépendances, utiliser des fichiers de verrouillage avec des vérifications d’intégrité, ou exécuter les builds derrière un proxy de dépendances qui applique une liste blanche.

Les builders isolés ajoutent un coût opérationnel. Les environnements de build éphémères qui sont détruits après chaque build empêchent la contamination croisée mais augmentent les temps de build et les dépenses d’infrastructure. Les runners auto-hébergés sur GitHub Actions, par exemple, ne fournissent pas les mêmes garanties d’isolation que les runners hébergés par GitHub.

Maturité de l’outillage et lacunes de l’écosystème

L’écosystème SLSA mûrit rapidement mais présente encore des lacunes :

Les builders de confiance sont limités. À ce jour, les générateurs de provenance SLSA de niveau 3 existent principalement pour GitHub Actions. GitLab, Jenkins, CircleCI et d’autres plateformes disposent de solutions moins matures ou maintenues par la communauté.
L’outillage de vérification est fragmenté. Différents outils vérifient différents formats de provenance, et il n’existe pas de commande universelle « vérifier toute provenance ». Les équipes ont souvent besoin de plusieurs outils dans leur pipeline de vérification.
Les langages de politique varient. Certains outils utilisent CUE, d’autres utilisent Rego, et les contrôleurs d’admission Kubernetes ont chacun leur propre format de politique. La standardisation est encore en cours.

Provenance pour les artefacts non-conteneurs

Alors que la provenance des images de conteneurs dispose d’un modèle clair de stockage et de distribution (registres OCI et referrers), d’autres types d’artefacts font face à des défis :

Packages npm : npm prend en charge la provenance depuis mai 2023, générée automatiquement pour les packages publiés depuis GitHub Actions. Cependant, l’outillage de vérification côté consommateur est encore limité.
Packages Python (PyPI) : PyPI travaille sur le support des attestations avec les Trusted Publishers, mais l’écosystème en est encore au début de l’adoption.
Artefacts Maven : La provenance de l’écosystème Java est moins mature. Des projets comme Sigstore pour Java émergent, mais une adoption généralisée nécessite le support des registres.
Binaires génériques : Pour les binaires autonomes, la provenance est généralement livrée sous forme de fichier annexe (.intoto.jsonl) aux côtés du binaire dans les assets de release. Cela fonctionne mais nécessite que les consommateurs sachent où la trouver et comment la vérifier.

Équilibrer la rigueur et la vélocité des développeurs

Des exigences strictes de provenance peuvent ralentir les workflows de développement :

Développement local : Les développeurs ont besoin de tester les builds localement, mais les builds locaux ne peuvent pas produire une provenance SLSA de niveau 2+. Les équipes doivent distinguer les « builds de développement » des « builds de release » sans créer un processus si complexe que les développeurs le contournent.
Adoption incrémentale : Passer de zéro provenance au niveau SLSA 3 en une seule étape est rarement faisable. Les équipes qui essaient abandonnent souvent l’effort. Une approche progressive — niveau 1 d’abord, puis niveau 2, puis niveau 3 pour les chemins critiques — est plus durable.
Reproductibilité des builds : La provenance vous dit comment quelque chose a été construit, mais elle ne garantit pas que les mêmes entrées produisent toujours la même sortie. Les builds non reproductibles rendent plus difficile la vérification indépendante des affirmations de provenance.
Déploiements d’urgence : Dans les scénarios de réponse aux incidents, les équipes peuvent avoir besoin de déployer rapidement à partir de chemins de build non standards. Les politiques de provenance ont besoin de mécanismes d’échappement (avec une journalisation et des pistes d’audit appropriées) pour éviter de bloquer les correctifs critiques.

Conclusion

La provenance des artefacts comble une lacune fondamentale dans la sécurité de la chaîne d’approvisionnement logicielle. Alors que les signatures prouvent qui a approuvé un artefact, la provenance prouve comment il a réellement été construit. Combinée au modèle de maturité du framework SLSA et au format d’attestation d’in-toto, nous disposons désormais d’une approche pratique et standardisée pour l’intégrité des builds.

Les points clés pour les équipes qui débutent ce parcours :

Commencez au niveau SLSA 1. Générez des métadonnées de provenance pour vos builds, même si elles ne sont pas encore signées par la plateforme de build. Cela vous donne l’auditabilité et établit la pratique.
Passez au niveau 2 avec des builders hébergés. Utilisez GitHub Actions, Google Cloud Build ou une autre plateforme hébergée qui peut signer la provenance en votre nom. C’est à ce stade que la provenance devient significativement vérifiable.
Visez le niveau 3 pour les chemins critiques. Pour vos artefacts les plus sensibles — images de conteneurs de production, releases signées, bibliothèques critiques pour la sécurité — investissez dans les builds hermétiques et les environnements de build isolés.
Vérifiez la provenance dans votre pipeline de déploiement. Générer la provenance sans la vérifier est du théâtre de sécurité. Ajoutez la vérification à vos contrôleurs d’admission, scripts de déploiement ou workflows GitOps basés sur le pull.
Adoptez les attestations in-toto comme format de métadonnées. Le format d’attestation in-toto est en passe de devenir le standard pour les métadonnées de la chaîne d’approvisionnement, prenant en charge non seulement la provenance SLSA mais aussi les SBOM, les analyses de vulnérabilités et les prédicats personnalisés.

La sécurité de la chaîne d’approvisionnement n’est pas un outil unique ou un contrôle unique. C’est une approche en couches où chaque contrôle — intégrité de la source, intégrité du build, provenance, vérification — renforce les autres. La provenance est le tissu conjonctif qui rend l’ensemble du système auditable et vérifiable. Commencez à la générer dès aujourd’hui, et itérez vers le haut.