Lab : Génération et Vérification de la Provenance SLSA pour les Images Container

par

Présentation

La provenance SLSA (Supply-chain Levels for Software Artifacts) est un enregistrement vérifiable qui décrit comment un artefact a été construit : le dépôt source, la plateforme de build, le point d’entrée et les matériaux d’entrée. Lorsqu’elle est associée à une image container, la provenance permet aux consommateurs de répondre à une question critique avant le déploiement : « Cette image a-t-elle réellement été construite à partir du source que j’attends, sur une plateforme en laquelle j’ai confiance ? »

Dans ce lab pratique, vous allez :

  • Construire et pousser une image container vers GitHub Container Registry (GHCR).
  • Générer une provenance SLSA Level 3 en utilisant le workflow réutilisable officiel slsa-github-generator.
  • Générer une provenance en utilisant les artifact attestations natifs de GitHub (actions/attest-build-provenance).
  • Vérifier la provenance avec slsa-verifier, cosign et gh attestation verify.
  • Appliquer la provenance au moment du déploiement avec une politique d’admission Kubernetes.

À la fin de ce lab, vous disposerez d’un pipeline complet et reproductible qui prouve l’intégrité de chaque image container que vous livrez.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

  • Compte GitHub avec un dépôt de test (public ou privé avec GitHub Pro/Team/Enterprise).
  • Accès GHCR — votre compte GitHub peut pousser vers ghcr.io par défaut ; confirmez en naviguant vers Settings → Packages.
  • Cosign CLI installé localement : 
    # macOS
brew install cosign

# Linux / other
go install github.com/sigstore/cosign/v2/cmd/cosign@latest
  • slsa-verifier CLI installé : 
    go install github.com/slsa-framework/slsa-verifier/v2/cli/slsa-verifier@latest
  • GitHub CLI (gh) version 2.49 ou ultérieure (pour les commandes gh attestation).
  • Docker installé et en cours d’exécution.
  • kubectl avec accès à un cluster Kubernetes de test (pour l’exercice d’application des politiques).

Mise en Place de l’Environnement

Étape 1 — Créer le Dépôt de Test

Créez un nouveau dépôt GitHub appelé slsa-provenance-lab. Clonez-le localement et ajoutez les fichiers suivants.

main.go

package main

import (
	"fmt"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		fmt.Fprintf(w, "Hello from SLSA provenance lab!")
	})
	fmt.Println("Server starting on :8080")
	http.ListenAndServe(":8080", nil)
}

go.mod

module github.com/YOUR_USER/slsa-provenance-lab

go 1.22

Dockerfile

FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY go.mod ./
COPY main.go ./
RUN go build -o server .

FROM alpine:3.19
RUN apk --no-cache add ca-certificates
COPY --from=builder /app/server /server
ENTRYPOINT ["/server"]

Étape 2 — Confirmer l’Accès GHCR

Authentifiez Docker auprès de GHCR afin de pouvoir pousser des images :

echo $GITHUB_TOKEN | docker login ghcr.io -u YOUR_USER --password-stdin

Remplacez YOUR_USER par votre nom d’utilisateur GitHub et GITHUB_TOKEN par un jeton d’accès personnel disposant du scope write:packages.

Étape 3 — Workflow de Base Build-and-Push (Sans Provenance)

Créez .github/workflows/build.yml pour vérifier que l’image se construit et se pousse correctement avant d’ajouter la provenance :

name: Build and Push (baseline)

on:
  push:
    tags:
      - "v*"

env:
  IMAGE: ghcr.io/${{ github.repository_owner }}/slsa-provenance-lab

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ${{ env.IMAGE }}:${{ github.ref_name }}
            ${{ env.IMAGE }}:latest

Poussez un tag de test pour vérifier :

git add -A
git commit -m "baseline build workflow"
git tag v0.1.0
git push origin main --tags

Confirmez que l’image apparaît à ghcr.io/YOUR_USER/slsa-provenance-lab:v0.1.0 avant de continuer.

Exercice 1 : Générer la Provenance SLSA avec slsa-github-generator

Pourquoi slsa-github-generator Atteint le SLSA Level 3

La propriété clé du SLSA Build Level 3 est que la provenance est générée par une plateforme de build que le développeur ne peut pas influencer. Le slsa-github-generator y parvient en s’exécutant comme un workflow réutilisable hébergé dans un dépôt séparé. Comme GitHub Actions isole les exécutions de workflows réutilisables du workflow appelant, l’étape de génération de provenance est protégée contre la falsification — même un job de build compromis ne peut pas altérer la sortie de provenance.

Le Workflow

Créez .github/workflows/slsa-provenance.yml :

name: Build + SLSA Provenance (slsa-github-generator)

on:
  push:
    tags:
      - "v*"

env:
  IMAGE: ghcr.io/${{ github.repository_owner }}/slsa-provenance-lab

jobs:
  # --- Job 1: Build and push the container image ---
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    outputs:
      image: ${{ env.IMAGE }}
      digest: ${{ steps.push.outputs.digest }}
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - id: push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ${{ env.IMAGE }}:${{ github.ref_name }}
            ${{ env.IMAGE }}:latest

  # --- Job 2: Generate SLSA Level 3 provenance ---
  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 }}
    secrets:
      registry-username: ${{ github.actor }}
      registry-password: ${{ secrets.GITHUB_TOKEN }}

Comprendre le Workflow

  • Le job build construit l’image, la pousse vers GHCR et produit en sortie la référence de l’image et le digest.
  • Le job provenance appelle le workflow réutilisable depuis le dépôt slsa-framework/slsa-github-generator à un tag épinglé (@v2.1.0). Comme ce workflow s’exécute dans un environnement isolé contrôlé par les mainteneurs du framework SLSA, il satisfait l’exigence SLSA Level 3 d’une plateforme de build renforcée et non falsifiable.
  • La provenance est signée en utilisant la signature sans clé de Sigstore (certificat Fulcio + journal de transparence Rekor) et attachée à l’image dans GHCR sous forme d’attestation cosign.

Déclencher le Workflow

git add .github/workflows/slsa-provenance.yml
git commit -m "add SLSA provenance workflow"
git tag v1.0.0
git push origin main --tags

Dans l’onglet Actions, vous verrez deux jobs : build et provenance. Le job provenance génère une attestation in-toto, la signe via Sigstore et pousse l’attestation vers GHCR aux côtés de l’image. Lorsque les deux jobs réussissent, votre image à ghcr.io/YOUR_USER/slsa-provenance-lab@sha256:<digest> porte désormais une attestation de provenance SLSA Level 3 signée.

Exercice 2 : Générer la Provenance avec les GitHub Artifact Attestations

L’Approche Native de GitHub

GitHub fournit un mécanisme intégré pour générer la provenance de build via l’action actions/attest-build-provenance. Cette approche est plus simple à configurer et stocke les attestations dans le stockage d’attestations propre à GitHub, les rendant vérifiables avec le CLI gh. Le compromis est que ces attestations suivent le chemin de vérification propre à GitHub plutôt que l’outillage du framework SLSA.

Le Workflow

Créez .github/workflows/github-attestation.yml :

name: Build + GitHub Artifact Attestation

on:
  push:
    tags:
      - "v*"

env:
  IMAGE: ghcr.io/${{ github.repository_owner }}/slsa-provenance-lab

jobs:
  build-and-attest:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      attestations: write
      id-token: write
    steps:
      - uses: actions/checkout@v4

      - uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - id: push
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: |
            ${{ env.IMAGE }}:${{ github.ref_name }}
            ${{ env.IMAGE }}:latest

      - name: Generate artifact attestation
        uses: actions/attest-build-provenance@v2
        with:
          subject-name: ${{ env.IMAGE }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

Comparaison des Deux Approches

Aspect slsa-github-generator GitHub Artifact Attestations
Niveau SLSA Level 3 (workflow réutilisable isolé) Level 2–3 (géré par GitHub, workflow unique)
Outil de vérification slsa-verifier, cosign gh attestation verify, cosign
Stockage des attestations Registre OCI (aux côtés de l’image) API d’attestation GitHub + push OCI optionnel
Complexité de mise en place Workflow à deux jobs avec appel de workflow réutilisable Workflow à un seul job avec une étape supplémentaire
Signature Sigstore (Fulcio + Rekor) Sigstore (Fulcio + Rekor via GitHub)

Les deux approches sont valides. Utilisez slsa-github-generator lorsque vous avez besoin d’une conformité stricte au SLSA Level 3 avec une vérification multiplateforme. Utilisez les GitHub artifact attestations lorsque vous souhaitez une mise en place plus simple et que vos consommateurs utilisent déjà l’écosystème GitHub.

Exercice 3 : Vérifier la Provenance avec slsa-verifier

Le CLI slsa-verifier est l’outil officiel pour vérifier la provenance SLSA générée par slsa-github-generator. Il vérifie la signature cryptographique, l’identité du builder, le dépôt source et le digest de l’artefact en une seule commande.

Étape 1 — Obtenir le Digest de l’Image

Récupérez le digest de l’image que vous avez poussée :

IMAGE=ghcr.io/YOUR_USER/slsa-provenance-lab
DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' "$IMAGE:v1.0.0" | cut -d@ -f2)
echo "$DIGEST"

Vous pouvez également trouver le digest dans la sortie du workflow Actions ou sur la page du package GHCR.

Étape 2 — Vérification Réussie

slsa-verifier verify-image "ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST" \
  --source-uri github.com/YOUR_USER/slsa-provenance-lab \
  --source-tag v1.0.0

Sortie attendue :

Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v2.1.0" at commit abc123def456
VERIFIED: SLSA verification passed

Étape 3 — Échec de Vérification : URI Source Incorrect

Essayez de vérifier contre un dépôt source incorrect :

slsa-verifier verify-image "ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST" \
  --source-uri github.com/YOUR_USER/wrong-repo \
  --source-tag v1.0.0

Sortie attendue :

FAILED: SLSA verification failed: source used to generate the binary does not match provenance

Étape 4 — Échec de Vérification : Tag Incorrect

slsa-verifier verify-image "ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST" \
  --source-uri github.com/YOUR_USER/slsa-provenance-lab \
  --source-tag v9.9.9

Sortie attendue :

FAILED: SLSA verification failed: tag "v9.9.9" does not match provenance

Ce que slsa-verifier Vérifie

  • Identité du builder — confirme que la provenance a été créée par le workflow réutilisable officiel slsa-github-generator à la référence attendue.
  • Dépôt source — la provenance doit référencer l’URI source que vous spécifiez.
  • Tag/branche source — vérifie optionnellement la référence Git qui a déclenché le build.
  • Digest de l’artefact — le digest SHA-256 enregistré dans la provenance doit correspondre à l’image que vous vérifiez.
  • Signature et journal de transparence — la signature Sigstore est vérifiée contre le journal de transparence Rekor.

Exercice 4 : Vérifier avec cosign verify-attestation

Cosign fournit un moyen de plus bas niveau mais plus flexible pour vérifier les attestations attachées aux images container. C’est utile lorsque vous devez inspecter le payload de provenance brut ou lors de l’intégration dans des pipelines de vérification personnalisés.

Vérifier l’Attestation

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/slsa-framework/slsa-github-generator/" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST

En cas de succès, cosign affiche le payload de l’attestation au format JSON. Un exemple tronqué :

Verification for ghcr.io/YOUR_USER/slsa-provenance-lab@sha256:abc123... --
The following checks were performed on each of these signatures:
  - The cosign claims were validated
  - Existence of the claims in the transparency log was verified offline
  - The code-signing certificate was verified using trusted certificate authority

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

Inspecter le Payload de Provenance

Décodez le payload en base64 pour inspecter les champs de provenance :

cosign verify-attestation \
  --type slsaprovenance \
  --certificate-identity-regexp "https://github.com/slsa-framework/slsa-github-generator/" \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST \
  | jq -r '.payload' | base64 -d | jq .

Champs clés dans la sortie :

  • buildDefinition.buildType — identifie le système de build (par exemple, https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1).
  • buildDefinition.externalParameters.workflow — le fichier de workflow et la référence qui ont exécuté le build.
  • buildDefinition.resolvedDependencies — le commit Git, le dépôt et les autres entrées.
  • runDetails.builder.id — l’URI du builder de confiance qui a généré la provenance.

Exercice 5 : Vérifier avec gh attestation verify

Pour les images attestées en utilisant les artifact attestations natifs de GitHub (Exercice 2), le CLI gh fournit le chemin de vérification le plus simple.

Vérifier l’Attestation

gh attestation verify oci://ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST \
  --owner YOUR_USER

Sortie attendue :

Loaded digest sha256:abc123def456... for oci://ghcr.io/YOUR_USER/slsa-provenance-lab@sha256:abc123...
Loaded 1 attestation from GitHub API

✓ Verification succeeded!

PredicateType: https://slsa.dev/provenance/v1
SubjectName:   ghcr.io/YOUR_USER/slsa-provenance-lab
SubjectDigest: sha256:abc123def456...
SignerRepo:    YOUR_USER/slsa-provenance-lab
SignerWorkflow: .github/workflows/github-attestation.yml
RunnerEnv:     github-hosted

Télécharger et Inspecter l’Attestation

Pour télécharger le bundle d’attestation brut pour une inspection hors ligne :

gh attestation download oci://ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST \
  --owner YOUR_USER \
  --output attestation-bundle.json

# Inspecter le prédicat de provenance
cat attestation-bundle.json | jq '.dsseEnvelope.payload' -r | base64 -d | jq .

Cela vous donne le prédicat de provenance SLSA complet, que vous pouvez stocker aux côtés de vos enregistrements de déploiement à des fins d’audit.

Exercice 6 : Appliquer la Provenance au Moment du Déploiement

Générer et vérifier la provenance manuellement est précieux, mais le véritable bénéfice en termes de sécurité provient de l’application automatisée au moment du déploiement. Dans cet exercice, vous allez configurer une politique d’admission Kubernetes qui rejette toute image container dépourvue de provenance SLSA valide.

Option A : Sigstore Policy Controller

Le Sigstore policy-controller est un webhook d’admission Kubernetes qui vérifie les signatures d’images et les attestations avant que les pods ne soient admis.

Installer le Policy Controller

helm repo add sigstore https://sigstore.github.io/helm-charts
helm repo update
helm install policy-controller sigstore/policy-controller \
  --namespace cosign-system \
  --create-namespace

Créer une ClusterImagePolicy

Créez slsa-policy.yml :

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-slsa-provenance
spec:
  images:
    - glob: "ghcr.io/YOUR_USER/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: "https://github.com/slsa-framework/slsa-github-generator/.*"
      attestations:
        - name: must-have-slsa-provenance
          predicateType: https://slsa.dev/provenance/v1
          policy:
            type: cue
            data: |
              predicateType: "https://slsa.dev/provenance/v1"

Appliquez-la :

kubectl apply -f slsa-policy.yml

Labelliser le Namespace pour l’Application

kubectl label namespace default policy.sigstore.dev/include=true

Option B : Politique Kyverno

Si vous utilisez Kyverno comme moteur de politique, créez kyverno-slsa-policy.yml :

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-slsa-provenance
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: check-slsa-provenance
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/YOUR_USER/*"
          attestations:
            - type: https://slsa.dev/provenance/v1
              attestors:
                - entries:
                    - keyless:
                        issuer: https://token.actions.githubusercontent.com
                        subjectRegExp: "https://github.com/slsa-framework/slsa-github-generator/.*"
                        rekor:
                          url: https://rekor.sigstore.dev

Appliquez-la :

kubectl apply -f kyverno-slsa-policy.yml

Test : Image Avec Provenance (Admise)

kubectl run test-allowed \
  --image=ghcr.io/YOUR_USER/slsa-provenance-lab@$DIGEST \
  --restart=Never

Résultat attendu : le pod est créé avec succès.

Test : Image Sans Provenance (Rejetée)

Poussez une image rapide sans provenance :

docker build -t ghcr.io/YOUR_USER/slsa-provenance-lab:no-provenance .
docker push ghcr.io/YOUR_USER/slsa-provenance-lab:no-provenance

NO_PROV_DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' \
  ghcr.io/YOUR_USER/slsa-provenance-lab:no-provenance | cut -d@ -f2)

kubectl run test-rejected \
  --image=ghcr.io/YOUR_USER/slsa-provenance-lab@$NO_PROV_DIGEST \
  --restart=Never

Résultat attendu :

Error from server: admission webhook denied the request:
image ghcr.io/YOUR_USER/slsa-provenance-lab@sha256:... 
failed to verify: no matching attestations found

Cela confirme que la politique d’admission bloque correctement les images dépourvues de provenance SLSA.

Inspection du Document de Provenance

Comprendre le document de provenance est essentiel pour l’audit et la construction d’automatisations par-dessus. Ci-dessous se trouve un document de provenance représentatif généré par slsa-github-generator, suivi d’une explication champ par champ.

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "ghcr.io/YOUR_USER/slsa-provenance-lab",
      "digest": {
        "sha256": "abc123def456789..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://slsa-framework.github.io/github-actions-buildtypes/workflow/v1",
      "externalParameters": {
        "workflow": {
          "ref": "refs/tags/v1.0.0",
          "repository": "https://github.com/YOUR_USER/slsa-provenance-lab",
          "path": ".github/workflows/slsa-provenance.yml"
        }
      },
      "resolvedDependencies": [
        {
          "uri": "git+https://github.com/YOUR_USER/slsa-provenance-lab@refs/tags/v1.0.0",
          "digest": {
            "gitCommit": "a1b2c3d4e5f6..."
          }
        }
      ]
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/tags/v2.1.0"
      },
      "metadata": {
        "invocationId": "https://github.com/YOUR_USER/slsa-provenance-lab/actions/runs/1234567890/attempts/1",
        "startedOn": "2026-03-23T10:15:30Z",
        "finishedOn": "2026-03-23T10:17:45Z"
      }
    }
  }
}

Analyse Champ par Champ

  • _type — identifie ceci comme une déclaration (Statement) in-toto v1, le format d’enveloppe utilisé par SLSA.
  • subject — l’artefact que cette provenance décrit. Contient le nom de l’image et son digest SHA-256. C’est ce que vous comparez avec l’image que vous vérifiez.
  • predicateType — déclare que cette attestation est une provenance SLSA v1. Les outils de vérification l’utilisent pour déterminer comment interpréter le prédicat.
  • buildDefinition.buildType — spécifie le système de build. Pour GitHub Actions, cela indique aux vérificateurs d’attendre des champs spécifiques à GitHub.
  • buildDefinition.externalParameters.workflow — le fichier de workflow, le dépôt et la référence Git qui ont déclenché le build. Vous devez vérifier que cela correspond à la source attendue.
  • buildDefinition.resolvedDependencies — liste les entrées résolues, y compris le commit Git exact. C’est la liste des « matériaux » — elle fournit un enregistrement complet de ce qui est entré dans le build.
  • runDetails.builder.id — l’URI du builder qui a généré la provenance. Pour le SLSA Level 3, il doit s’agir d’un builder de confiance et isolé comme le workflow réutilisable slsa-github-generator à un tag épinglé.
  • runDetails.metadata — horodatages et lien vers l’exécution spécifique de GitHub Actions, permettant une traçabilité complète de l’artefact jusqu’au build.

Lors de la construction d’une vérification automatisée, vérifiez toujours : (1) le digest du sujet correspond, (2) l’identifiant du builder est dans votre liste autorisée, (3) le dépôt source et la référence correspondent à vos attentes, et (4) la signature est valide.

Nettoyage

Supprimez les ressources créées pendant ce lab :

# Delete Kubernetes test pods
kubectl delete pod test-allowed test-rejected --ignore-not-found

# Remove the admission policy (Sigstore)
kubectl delete clusterimagepolicy require-slsa-provenance --ignore-not-found

# Or remove the Kyverno policy
kubectl delete clusterpolicy require-slsa-provenance --ignore-not-found

# Remove the namespace label
kubectl label namespace default policy.sigstore.dev/include-

# Delete GHCR images (via GitHub UI or CLI)
gh api -X DELETE /user/packages/container/slsa-provenance-lab/versions/PACKAGE_VERSION_ID

# Delete the test repository if desired
# gh repo delete YOUR_USER/slsa-provenance-lab --yes

Points Clés à Retenir

  • La provenance SLSA est un enregistrement signé et inviolable de la façon dont une image container a été construite. Elle capture la source, le builder et les paramètres de build.
  • Le SLSA Level 3 exige l’isolation du build — slsa-github-generator y parvient en exécutant la génération de provenance dans un workflow réutilisable séparé que le développeur ne peut pas modifier à l’exécution.
  • Les GitHub artifact attestations fournissent une alternative plus simple qui s’intègre étroitement à l’écosystème GitHub, avec des compromis en termes de portabilité multiplateforme.
  • La vérification doit être automatisée — utilisez slsa-verifier dans les portes CI, cosign verify-attestation dans les scripts, ou les contrôleurs d’admission Kubernetes pour appliquer la provenance avant le déploiement.
  • La vérification de provenance vérifie plusieurs affirmations : l’identité du builder, le dépôt source, la référence source, le digest de l’artefact et la validité de la signature cryptographique.
  • Inspectez les documents de provenance pour comprendre exactement ce qui a été construit, à partir de quel commit, par quel builder. C’est votre piste d’audit pour les incidents de chaîne d’approvisionnement.

Prochaines Étapes

Continuez à renforcer la sécurité de votre chaîne d’approvisionnement logicielle :