Le CI/CD est une surface de risque de chaîne d’approvisionnement logicielle parce que le pipeline peut récupérer des dépendances, compiler du code, créer des artefacts, les publier et les remettre à la production avec très peu d’inspection humaine. OpenSSF continue de traiter la sécurité de la chaîne d’approvisionnement comme un thème central, et son ensemble de projets actuel continue d’inclure à la fois Sigstore et SLSA comme blocs de construction fondamentaux pour sécuriser la façon dont le logiciel est construit et distribué.

Sigstore, SLSA et les SBOMs résolvent différentes parties du problème. Sigstore vous donne la signature, la vérification, la transparence et des workflows sans clé basés sur l’identité ; SLSA vous donne un framework pour l’intégrité du build plus une provenance qui décrit où, quand et comment un artefact a été produit ; et les standards SBOM comme SPDX et CycloneDX vous donnent un inventaire lisible par machine des composants à l’intérieur du logiciel que vous expédiez. Aucun de ceux-ci ne remplace les autres. Ils fonctionnent mieux comme une stack.

Ce tutoriel utilise GitHub Actions pour les exemples concrets parce que le flux GitHub actuel se mappe proprement à la signature basée sur OIDC, les attestations de provenance de build et les attestations SBOM signées. La même base s’applique quand même sur d’autres systèmes CI : signez ce que vous expédiez, générez la provenance depuis le builder, générez un SBOM au moment du build et vérifiez les trois avant le déploiement. Pour un contexte plus large sur comment le développement piloté par l’IA change le tableau du risque de chaîne d’approvisionnement, consultez Software Supply Chain Security in the AI Era.

Étape 1 : Mapper votre pipeline actuel

Avant d’ajouter des contrôles, mappez le chemin logiciel réel de la source à la production. Le modèle de provenance de SLSA existe parce que les artefacts ne sont pas fiables simplement parce qu’ils viennent “du pipeline” ; vous avez besoin d’informations vérifiables sur le builder, les entrées, l’invocation et le sujet produit. Si vous ne pouvez pas décrire ces parties mobiles, vous ne pouvez pas les défendre.

Inventorier les étapes du pipeline

Pour chaque application ou image que vous publiez, capturez :

le dépôt source et les branches protégées
le workflow de build ou le runner
l’étape de résolution des dépendances
l’étape de packaging
le registre d’artefacts ou magasin de release
le chemin de déploiement
les actions tierces, plugins et images de base

Un fichier d’inventaire léger suffit pour commencer.

Fichier : pipeline-inventory.yaml

application: payments-api
source:
  repo: github.com/acme/payments-api
  protected_branches:
    - main
build:
  ci_platform: github-actions
  workflow: .github/workflows/release.yml
  runner_type: github-hosted
dependencies:
  lockfiles:
    - package-lock.json
    - Dockerfile
  third_party_actions:
    - actions/checkout
    - docker/build-push-action
artifact:
  type: container-image
  registry: ghcr.io/acme/payments-api
deploy:
  environments:
    - staging
    - production
  gate: deploy-verify.sh

Identifier ce qui est réellement déployable

Signez et vérifiez la chose que votre runtime consomme, pas seulement un fichier intermédiaire. La documentation d’attestation d’artefacts de GitHub fait le même point en pratique : signez le logiciel que les gens exécutent réellement, comme les binaires, les packages et les images de conteneur, plutôt que chaque fichier accessoire du dépôt.

Pour la plupart des équipes, cela signifie un ou plusieurs de :

les digests d’image de conteneur
les binaires de release
les artefacts de package
les bundles de déploiement ou manifestes qui épinglent les digests

Identifier vos points de confiance tiers

Le modèle de menace de SLSA se concentre fortement sur la falsification dans le chemin de build. Dans les vrais pipelines, les points de confiance les plus courants ne sont pas seulement le dépôt source. Ce sont aussi :

les actions ou plugins réutilisables
les images de base de conteneur
les registres de packages
les runners auto-hébergés
les credentials de registre
les credentials de déploiement

Créez une courte checklist et forcez-vous à les nommer.

Fichier : third-party-trust-points.md

# Third-Party Trust Points

- Docker base images
- npm registry packages
- GitHub Actions used by the release workflow
- Container registry credentials
- Cloud deploy role assumed by the workflow

Astuce

Le premier gain est la visibilité. La plupart des équipes découvrent qu’elles font confiance à plus de composants de pipeline qu’elles ne le pensaient.

Vous devriez maintenant avoir une carte du pipeline qui vous dit où les artefacts sont construits, où ils sont publiés et quels systèmes externes influencent le résultat.

Étape 2 : Ajouter la signature d’artefacts

La signature est le premier contrôle applicable parce qu’elle répond à une question simple : l’artefact vient-il d’une identité attendue ? Le flux sans clé de Sigstore est particulièrement utile en CI parce qu’il utilise un token d’identité OIDC et des certificats de courte durée au lieu de vous forcer à garder une clé privée de signature de longue durée dans le pipeline. Dans GitHub Actions, l’intégration Fulcio de Sigstore peut lier l’identité du certificat au workflow et au dépôt qui ont effectué la signature.

Décider quoi signer

Pour les charges de travail OCI, signez le digest d’image immuable, pas un tag flottant. Pour les binaires de release, signez l’artefact final que les utilisateurs téléchargent. Si vous expédiez à la fois un conteneur et un tarball de release, signez les deux séparément et vérifiez-les là où chacun est consommé.

Ajouter la signature sans clé au build

L’exemple ci-dessous construit une image de conteneur, la pousse et signe le digest d’image avec Cosign en utilisant le token OIDC de GitHub.

Fichier : .github/workflows/release.yml

name: release

on:
  push:
    branches:
      - main

permissions:
  contents: read
  packages: write
  id-token: write

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ghcr.io/acme/payments-api

jobs:
  build-sign:
    runs-on: ubuntu-latest

    steps:
      - name: Check out source
        uses: actions/checkout@v4

      - name: Log in to GHCR
        run: echo "${{ github.token }}" | docker login ghcr.io -u "${{ github.actor }}" --password-stdin

      - name: Build and push image
        id: build
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ${{ env.IMAGE_NAME }}:${{ github.sha }}

      # Check https://github.com/sigstore/cosign/releases for latest version
      - name: Install Cosign
        run: |
          COSIGN_VERSION="v3.0.5"
          curl -fsSL -o /tmp/cosign.deb \
            "https://github.com/sigstore/cosign/releases/download/${COSIGN_VERSION}/cosign_${COSIGN_VERSION#v}_amd64.deb"
          sudo dpkg -i /tmp/cosign.deb

      - name: Sign image digest with Sigstore keyless
        env:
          IMAGE_URI: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}
        run: |
          cosign sign --yes "${IMAGE_URI}"

Vérifier les signatures là où ça compte

Ne vous arrêtez pas à cosign sign. La vérification appartient là où les décisions de confiance se produisent :

avant le déploiement
au moment de l’admission dans Kubernetes
pendant la promotion de release
côté consommateur si d’autres équipes tirent vos artefacts

Le policy-controller de Sigstore existe spécifiquement pour appliquer la politique de signature d’image et d’attestation dans l’admission Kubernetes, et il peut valider les signatures et attestations avec une application périmètrée par namespace.

Un simple script de vérification pré-déploiement ressemble à ceci :

Fichier : deploy-verify-signature.sh

#!/usr/bin/env bash
set -euo pipefail

IMAGE_URI="$1"

cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "https://github.com/acme/payments-api/.github/workflows/release.yml@refs/heads/main" \
  "${IMAGE_URI}"

Attention

Signer sans vérifier est de la tenue de registres, pas de la protection.

Vous devriez maintenant avoir la signature d’artefacts dans le pipeline et un point de vérification avant le déploiement ou l’admission.

Étape 3 : Générer la provenance

La provenance est une attestation qui décrit comment un artefact a été produit. En termes SLSA, la provenance devrait permettre à un vérificateur de vérifier l’identité du builder, le sujet et digest de l’artefact, et les détails de build qui connectent la sortie au code source et aux instructions de build. La provenance ne devient utile qu’une fois que vous la vérifiez contre une racine de confiance attendue et une identité de build attendue.

Quelles métadonnées de build comptent

Au minimum, la provenance est précieuse quand elle vous permet de répondre :

quel builder a produit l’artefact
quel dépôt source et quelle révision ont été utilisés
quelles instructions de build ont été exécutées
quel digest d’artefact a été produit

Le modèle actuel d’attestation d’artefacts de GitHub inclut le dépôt, le workflow, l’environnement, le SHA du commit, l’événement et d’autres informations de build dérivées de l’OIDC. GitHub note aussi explicitement que les attestations d’artefacts seules correspondent au SLSA v1.0 Build Level 2, tandis que les workflows réutilisables peuvent aider à atteindre le Build Level 3 en isolant les instructions de build.

Base : ajouter la provenance de build dans GitHub Actions

Pour une première base pratique, ajoutez une attestation de provenance de build juste après la construction de l’image. L’action officielle attest-build-provenance de GitHub supporte les binaires et les images de conteneur et peut pousser l’attestation vers le registre.

Ajoutez cette étape au job build-sign après la construction de l’image. Le bloc permissions au niveau du job du workflow ci-dessus inclut déjà le scope requis attestations: write ; ajoutez-le si votre workflow ne l’a pas encore.

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

Chemin plus fort : aller vers des workflows de build réutilisables et isolés

Si vous avez besoin d’une histoire SLSA plus forte sur GitHub Actions, utilisez des workflows réutilisables ou le SLSA GitHub Generator au lieu de laisser toute la logique de build inline dans un seul workflow de release mutable. Le projet SLSA GitHub Generator est l’outillage officiel du framework SLSA pour les projets natifs GitHub et est conçu pour générer une provenance SLSA Build Level 3 pour les workflows supportés.

Un job de provenance réutilisable simplifié pour les artefacts de fichiers ressemble à ceci :

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      hashes: ${{ steps.hashes.outputs.subjects }}
    steps:
      - uses: actions/checkout@v4

      - name: Build artifact
        run: |
          mkdir -p dist
          tar -czf dist/payments-api.tar.gz src package.json package-lock.json

      - name: Compute artifact digest file
        run: sha256sum dist/payments-api.tar.gz > subject-digests.txt

      - name: Encode subjects for SLSA generator
        id: hashes
        uses: slsa-framework/slsa-github-generator/actions/generator/generic/create-base64-subjects-from-file@v2.1.0
        with:
          path: subject-digests.txt

  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.hashes }}
      upload-assets: true

Vérifier la provenance avant la promotion

gh attestation verify de GitHub vérifie les attestations de provenance de build, et les recommandations de vérification propres à SLSA disent que le vérificateur devrait vérifier la signature, s’assurer que le sujet correspond au digest de l’artefact, confirmer le type de prédicat et comparer l’identité du builder à une racine de confiance préconfigurée.

Une simple étape de vérification pour une image de conteneur ressemble à ceci :

gh attestation verify \
  "oci://ghcr.io/acme/payments-api:${GITHUB_SHA}" \
  -R acme/payments-api

Info

La provenance n’est pas juste des métadonnées pour les auditeurs. C’est le lien lisible par machine entre un artefact et l’identité du builder qui l’a produit.

Vous devriez maintenant avoir la provenance de build générée et un endroit concret pour la vérifier avant la promotion ou le déploiement.

Étape 4 : Produire un SBOM

Un SBOM répond à une question différente de la provenance. La provenance vous dit comment l’artefact a été construit. Un SBOM vous dit ce qu’il y a dedans. Le flux d’attestation SBOM de GitHub supporte les attestations SBOM signées, et Sigstore/Cosign supportent les workflows liés aux SBOMs SPDX et CycloneDX. SPDX et CycloneDX sont tous deux des standards actifs et officiels, donc le choix opérationnel important n’est pas “lequel est vrai”, mais lequel vous utiliserez comme format canonique interne.

Choisir un format canonique unique

Une bonne règle par défaut est :

choisissez SPDX JSON si votre organisation penche déjà fortement vers l’outillage de licence/conformité ou veut l’écosystème SPDX adossé à l’ISO
choisissez CycloneDX JSON si votre outillage de sécurité est plus orienté sécurité applicative et analyse de dépendances

Les deux sont valides. La plus grande erreur est de générer plusieurs formats de manière ad hoc sans source de vérité claire.

Générer le SBOM au moment du build

Pour GitHub Actions, la documentation d’attestation SBOM de GitHub pointe explicitement vers la création du SBOM d’abord puis son attestation. L’exemple ci-dessous utilise Syft pour générer un fichier SPDX JSON pour l’image construite. Syft est un générateur de SBOM largement utilisé pour les images et systèmes de fichiers.

Ajoutez ces étapes au job build-sign après la construction de l’image :

      # Check https://github.com/anchore/syft/releases for latest version
      - name: Install Syft
        run: |
          SYFT_VERSION="v1.42.1"
          curl -fsSL -o /tmp/syft.tar.gz \
            "https://github.com/anchore/syft/releases/download/${SYFT_VERSION}/syft_${SYFT_VERSION#v}_linux_amd64.tar.gz"
          tar -xzf /tmp/syft.tar.gz -C /tmp
          sudo mv /tmp/syft /usr/local/bin/syft

      - name: Generate SPDX SBOM for image
        env:
          IMAGE_URI: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}
        run: |
          syft "${IMAGE_URI}" -o spdx-json=sbom.spdx.json

Stocker le SBOM avec l’artefact

Le flux actuel d’attestation SBOM de GitHub signe le SBOM comme une attestation associée à l’artefact. Cosign de Sigstore supporte aussi l’attachement ou l’attestation de SBOMs pour les artefacts OCI. Pour une base CI pratique sur GitHub, utiliser l’action officielle attest-sbom garde le lien artefact-SBOM explicite et vérifiable.

Ajoutez cette étape après la génération du SBOM. Le bloc permissions au niveau du job doit inclure attestations: write :

      - name: Generate signed SBOM attestation
        uses: actions/attest-sbom@v4
        with:
          subject-name: ${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.build.outputs.digest }}
          sbom-path: sbom.spdx.json
          push-to-registry: true

Vérifier l’attestation SBOM

Le flux de vérification de GitHub supporte les attestations SBOM et vous permet de vérifier un type de prédicat spécifique. Pour SPDX, le type de prédicat documenté est https://spdx.dev/Document/v2.3.

gh attestation verify \
  "oci://ghcr.io/acme/payments-api:${GITHUB_SHA}" \
  -R acme/payments-api \
  --predicate-type https://spdx.dev/Document/v2.3

Astuce

Traitez le SBOM comme faisant partie du dossier de release, pas comme un fichier secondaire optionnel que quelqu’un pourrait ou non uploader plus tard.

Vous devriez maintenant avoir un SBOM au moment du build, une attestation signée qui le lie à l’artefact, et un chemin de vérification avant le déploiement.

Étape 5 : Ajouter des portes de vérification

C’est ici que la base devient réelle. Les recommandations de vérification de SLSA sont directes à ce sujet : la provenance ne fait rien à moins que quelqu’un ne l’inspecte. La même logique s’applique aux signatures et aux SBOMs. La génération sans portes est une fonctionnalité de tableau de bord, pas un contrôle.

Bloquer les artefacts non signés

Un job de déploiement ou de promotion devrait échouer si la signature de l’artefact est manquante ou si l’identité de signature n’est pas celle que vous attendez. En termes GitHub/Sigstore, cela signifie généralement vérifier l’émetteur OIDC et faire correspondre l’identité du certificat au workflow de release ou au pattern regex de confiance.

Bloquer la provenance non fiable

Au minimum, exigez que l’artefact ait une attestation de provenance valide de votre dépôt et builder attendus. Si vous utilisez les attestations d’artefacts GitHub, vérifiez-les avec gh attestation verify. Si vous utilisez des builders natifs SLSA, validez aussi l’identité du builder et la source ou ref attendue.

Signaler les dépendances inconnues avant le déploiement

Un SBOM est le plus utile quand vous le comparez réellement à une politique. Les premières bonnes vérifications sont :

pas de packages de registres non approuvés
pas de SBOM vide ou évidemment incomplet
pas de licences inconnues critiques si votre organisation suit cela
pas de composants nouvellement introduits en dehors de la politique de dépendances autorisées

Un simple script de porte peut appliquer la base minimale :

Fichier : deploy-verify.sh

#!/usr/bin/env bash
set -euo pipefail

IMAGE_URI="$1"
REPO="acme/payments-api"

echo "1) Verify Sigstore signature"
cosign verify \
  --certificate-oidc-issuer "https://token.actions.githubusercontent.com" \
  --certificate-identity-regexp "https://github.com/acme/payments-api/.github/workflows/release.yml@refs/heads/main" \
  "${IMAGE_URI}" >/dev/null

echo "2) Verify build provenance"
gh attestation verify \
  "oci://${IMAGE_URI}" \
  -R "${REPO}" >/dev/null

echo "3) Verify SBOM attestation"
gh attestation verify \
  "oci://${IMAGE_URI}" \
  -R "${REPO}" \
  --predicate-type "https://spdx.dev/Document/v2.3" >/dev/null

echo "4) Pull SBOM payload for policy checks"
gh attestation verify \
  "oci://${IMAGE_URI}" \
  -R "${REPO}" \
  --predicate-type "https://spdx.dev/Document/v2.3" \
  --format json \
  --jq '.[].verificationResult.statement.predicate' > verified-sbom.json

# Check that the SBOM contains package data (SPDX uses .packages, CycloneDX uses .components)
jq -e '.packages // .components | length > 0' verified-sbom.json >/dev/null

echo "All supply-chain checks passed"

Appliquer au moment du déploiement ou de l’admission

Si votre cible de déploiement est Kubernetes, l’admission est l’endroit le plus propre pour appliquer “pas d’image non signée” ou “pas d’image sans attestation requise.” Le policy-controller de Sigstore est construit pour exactement ce cas d’utilisation et peut évaluer les politiques de signatures et d’attestations à l’admission.

Attention

L’erreur de pipeline la plus courante est de mettre tout l’effort dans la génération et rien dans le rejet au moment du déploiement.

Vous devriez maintenant avoir une porte qui bloque les artefacts manquant une signature valide, une provenance valide ou une attestation SBOM valide.

Étape 6 : Sécuriser les identités du pipeline

Un pipeline de chaîne d’approvisionnement durci échoue quand même si le runner peut usurper trop d’identités ou si les secrets vivent trop longtemps. Le modèle OIDC de GitHub existe précisément pour que les workflows puissent s’authentifier auprès des fournisseurs cloud et autres services sans stocker des credentials statiques de longue durée dans les secrets. GitHub documente aussi le resserrement explicite des permissions GITHUB_TOKEN plutôt que de laisser des défauts larges en place.

Préférer OIDC aux secrets de longue durée

Pour les déploiements cloud et l’accès au registre, préférez des credentials fédérés de courte durée là où votre plateforme les supporte. Cela réduit le rayon d’impact des tokens fuités et lie la décision de confiance à l’identité du workflow. Le modèle sans clé de Sigstore suit le même principe pour la signature.

Réduire les permissions de workflow par défaut

N’exécutez pas les workflows de release avec des permissions de dépôt larges à moins que le job n’en ait vraiment besoin. Un workflow de release qui ne lit que la source, écrit des packages, signe des artefacts et écrit des attestations peut généralement le dire directement.

permissions:
  contents: read
  packages: write
  id-token: write
  attestations: write

Protéger les branches et environnements

Les recommandations de niveau supérieur de SLSA mettent l’accent sur les builders dignes de confiance et les plans de contrôle protégés, pas seulement sur les sorties signées. En termes CI pratiques, cela signifie :

protéger les branches de release
protéger les tags
utiliser les approbations d’environnement pour les déploiements en production
restreindre qui peut modifier les workflows de release
isoler soigneusement les runners auto-hébergés si vous les utilisez

Ces contrôles ne sont pas séparés de la sécurité de la chaîne d’approvisionnement. C’est comme ça que vous empêchez un humain ou un workflow de contourner la confiance du builder que vous essayez d’établir.

Garder la durée de vie des tokens courte et les secrets périmètrés

Les bons défauts incluent :

pas de mots de passe de registre de longue durée en CI si OIDC ou tokens de courte durée sont disponibles
secrets périmètrés par environnement
credentials de déploiement séparés des credentials de build
pas de réutilisation de tokens personnels larges pour l’automatisation

Astuce

Le durcissement de l’identité du pipeline fait partie de la qualité de la provenance. Un artefact bien signé depuis un runner surprivilégié est quand même une faible histoire de chaîne d’approvisionnement.

Vous devriez maintenant avoir un modèle d’identité plus serré pour les runners, tokens et workflows protégés.

Étape 7 : Construire une base de politique minimale

Une base est ce qui empêche le durcissement de la chaîne d’approvisionnement de devenir aspirationnel. La documentation d’attestation d’artefacts de GitHub est claire que les attestations ne sont pas une garantie qu’un artefact est sécurisé ; elles vous permettent de définir et appliquer une politique en utilisant les informations de build et d’origine qu’elles exposent. Le modèle de vérification de SLSA dit la même chose en d’autres mots : la confiance vient de la vérification de l’attestation contre vos attentes.

Commencer avec une politique petite et appliquée

Une base pratique pour une petite ou moyenne équipe est :

chaque artefact déployable doit être signé
chaque artefact déployable doit avoir une provenance de build
chaque artefact déployable doit avoir un SBOM
les déploiements échouent fermé si la vérification échoue
les exceptions nécessitent une approbation manuelle et une expiration

Fichier : supply-chain-policy.yaml

required:
  signature: true
  provenance: true
  sbom: true

trusted_signers:
  - issuer: https://token.actions.githubusercontent.com
    identity_regex: https://github.com/acme/payments-api/.github/workflows/release.yml@refs/heads/main

provenance:
  trusted_repo: acme/payments-api
  trusted_branch: refs/heads/main

sbom:
  predicate_type: https://spdx.dev/Document/v2.3
  must_include_dependencies: true

exceptions:
  max_duration_hours: 24
  approvers:
    - platform-team
    - security-team

Ajouter un workflow d’exception simple

Les exceptions ne sont pas un échec. Les exceptions permanentes le sont. Gardez-les explicites :

Fichier : exception-request.md

# Supply-Chain Policy Exception

- Artifact:
- Reason:
- Missing control: signature / provenance / SBOM
- Requested by:
- Approved by:
- Expiration time:
- Remediation issue:

À quoi ressemble une bonne maturité au fil du temps

Un chemin de maturité sensé est :

générer les signatures, la provenance et les SBOMs
les vérifier avant le déploiement
rétrécir les identités des builders et les permissions des workflows
appliquer au moment de l’admission ou de la promotion
standardiser les workflows de build réutilisables et une confiance de provenance plus stricte

Cette progression s’aligne avec la direction de l’écosystème OpenSSF autour de la sécurité de la chaîne d’approvisionnement et avec l’accent propre de SLSA sur le passage de “les métadonnées existent” à “les métadonnées sont dignes de confiance et vérifiées.”

Problèmes courants de configuration

Générer des SBOMs mais ne pas les utiliser

Les équipes produisent souvent des SBOMs parce que l’outillage est facile, puis ne vérifient jamais l’attestation, n’attachent jamais le SBOM à l’artefact et ne comparent jamais son contenu à une politique. Le workflow d’attestation SBOM et les commandes de vérification de GitHub existent spécifiquement pour que le SBOM puisse devenir partie d’un dossier de release vérifiable plutôt qu’un fichier en vrac dans les artefacts de build.

Signer les artefacts sans vérification

C’est le mode d’échec le plus courant. Sigstore, les attestations d’artefacts GitHub et les recommandations de vérification SLSA supposent tous que quelqu’un vérifie le résultat contre une identité de confiance ou une racine de confiance. Si votre étape de déploiement ne vérifie jamais, le contrôle n’a pas de dents.

Traiter SLSA comme uniquement de la conformité

SLSA n’est pas juste un label de rapport. Son modèle de provenance et de vérification porte sur le fait qu’un vérificateur puisse faire confiance à quel builder a produit l’artefact et de quelle source il provient. Si vous vous arrêtez à “nous avons un fichier de provenance”, vous manquez tout le point.

Ignorer l’accès humain au pipeline

Une forte histoire de signature n’aide pas beaucoup si trop de personnes peuvent modifier le workflow de release, contourner la protection de branche ou exécuter des déploiements depuis des branches non revues. Le modèle de confiance du builder de SLSA et les recommandations de GitHub autour des workflows réutilisables et des identités protégées pointent tous vers la même conclusion : l’accès humain au plan de contrôle compte.

Conclusion

Une base pratique de chaîne d’approvisionnement CI/CD n’est pas énorme. Commencez par mapper le pipeline, signez l’artefact déployable avec Sigstore, émettez une provenance que votre système de déploiement peut vérifier, générez un SBOM dans un format canonique unique, puis bloquez le déploiement quand ces vérifications échouent. Cela vous amène déjà beaucoup plus loin que “nous avons généré quelques métadonnées en CI.”

Pour les petites équipes, les gains rapides sont simples : signature sans clé, attestation de provenance de build, un seul format SBOM, permissions de workflow minimales et un seul script de vérification pré-déploiement. Au fil du temps, la maturité ressemble à des workflows de build durcis réutilisables, une confiance de provenance plus stricte, une application au moment de l’admission et moins de credentials de longue durée n’importe où dans le chemin de la source à la production.

Si votre pipeline CI/CD traite aussi du code généré par l’IA depuis des agents de codage, complétez ce durcissement de chaîne d’approvisionnement avec Verrouiller les pipelines d’agents de codage IA, qui couvre la détection, l’application de politique, le scanning de sécurité et les portes de revue basées sur le risque pour les PRs générées par l’IA.

Avant de commencer

Ce que vous apprendrez

Étape 1 : Mapper votre pipeline actuel

Inventorier les étapes du pipeline

Identifier ce qui est réellement déployable

Identifier vos points de confiance tiers

Étape 2 : Ajouter la signature d’artefacts

Décider quoi signer

Ajouter la signature sans clé au build

Vérifier les signatures là où ça compte

Étape 3 : Générer la provenance

Quelles métadonnées de build comptent

Base : ajouter la provenance de build dans GitHub Actions

Chemin plus fort : aller vers des workflows de build réutilisables et isolés

Vérifier la provenance avant la promotion

Étape 4 : Produire un SBOM

Choisir un format canonique unique

Générer le SBOM au moment du build

Stocker le SBOM avec l’artefact

Vérifier l’attestation SBOM

Étape 5 : Ajouter des portes de vérification

Bloquer les artefacts non signés

Bloquer la provenance non fiable

Signaler les dépendances inconnues avant le déploiement

Appliquer au moment du déploiement ou de l’admission

Étape 6 : Sécuriser les identités du pipeline

Préférer OIDC aux secrets de longue durée

Réduire les permissions de workflow par défaut

Protéger les branches et environnements

Garder la durée de vie des tokens courte et les secrets périmètrés

Étape 7 : Construire une base de politique minimale

Commencer avec une politique petite et appliquée

Ajouter un workflow d’exception simple

À quoi ressemble une bonne maturité au fil du temps

Problèmes courants de configuration

Générer des SBOMs mais ne pas les utiliser

Signer les artefacts sans vérification

Traiter SLSA comme uniquement de la conformité

Ignorer l’accès humain au pipeline

Conclusion