Lab : Construction d’un Pipeline SBOM — Générer, Attester et Vérifier avec Syft et Cosign

par

Présentation

Les Software Bills of Materials (SBOMs) deviennent rapidement un composant obligatoire de la transparence de la chaîne d’approvisionnement logicielle. Les décrets gouvernementaux, les cadres réglementaires comme le NIST SSDF et les normes industrielles exigent désormais des organisations qu’elles produisent, distribuent et vérifient des SBOMs pour chaque version logicielle. Un SBOM liste chaque composant, bibliothèque et dépendance à l’intérieur de votre logiciel — permettant aux consommateurs d’évaluer les risques, de suivre les vulnérabilités et de vérifier la provenance.

Dans ce lab pratique, vous allez construire un pipeline SBOM complet de zéro. À la fin, vous serez capable de :

  • Générer des SBOMs aux formats SPDX et CycloneDX avec Syft
  • Scanner les SBOMs pour détecter les vulnérabilités connues avec Grype
  • Attacher des SBOMs comme attestations signées aux images de conteneurs avec Cosign
  • Automatiser l’ensemble du flux de travail dans GitHub Actions et GitLab CI
  • Appliquer les exigences d’attestation SBOM au déploiement avec Kyverno
  • Comparer les SBOMs entre les versions pour détecter les changements de dépendances

Ce lab reflète les flux de travail de production réels utilisés par les équipes adoptant SLSA, in-toto et la sécurité de la chaîne d’approvisionnement basée sur Sigstore.

Prérequis

Avant de commencer, assurez-vous que les outils suivants sont installés et configurés :

Outil Fonction Installation
Syft Génération de SBOM curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
Grype Analyse de vulnérabilités curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
Cosign Signature et attestation go install github.com/sigstore/cosign/v2/cmd/cosign@latest
Docker Construction de conteneurs docs.docker.com
GitHub CLI (gh) Accès au dépôt et à GHCR brew install gh ou cli.github.com

Vous avez également besoin d’un compte GitHub avec accès au GitHub Container Registry (GHCR), et d’une application de base avec un Dockerfile.

Configuration de l’environnement

Nous allons créer une application Node.js minimale, la conteneuriser et la pousser vers GHCR. Cette image devient la cible de tous les exercices SBOM suivants.

Étape 1 : Créer le dépôt de test

mkdir sbom-pipeline-lab && cd sbom-pipeline-lab
git init

Étape 2 : Créer une application Node.js simple

cat > package.json <<'EOF'
{
  "name": "sbom-lab-app",
  "version": "1.0.0",
  "description": "SBOM pipeline lab application",
  "main": "server.js",
  "dependencies": {
    "express": "^4.18.2",
    "lodash": "^4.17.21",
    "axios": "^1.6.0"
  }
}
EOF

cat > server.js <<'EOF'
const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.json({ status: 'ok', message: 'SBOM Pipeline Lab' });
});

app.listen(3000, () => console.log('Listening on port 3000'));
EOF

Étape 3 : Créer le Dockerfile

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install --production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]

Étape 4 : Construire et pousser l’image de conteneur

# S'authentifier auprès de GHCR
echo $GITHUB_TOKEN | docker login ghcr.io -u YOUR_GITHUB_USERNAME --password-stdin

# Construire l'image
docker build -t ghcr.io/YOUR_GITHUB_USERNAME/sbom-lab-app:v1.0.0 .

# Pousser vers GHCR
docker push ghcr.io/YOUR_GITHUB_USERNAME/sbom-lab-app:v1.0.0

Remplacez YOUR_GITHUB_USERNAME par votre nom d’utilisateur GitHub réel tout au long de ce lab. Une fois le push terminé, notez le digest complet de l’image — vous en aurez besoin pour les opérations de signature.

# Capturer le digest de l'image
export IMAGE=$(docker inspect --format='{{index .RepoDigests 0}}' ghcr.io/YOUR_GITHUB_USERNAME/sbom-lab-app:v1.0.0)
echo $IMAGE
# Sortie : ghcr.io/YOUR_GITHUB_USERNAME/sbom-lab-app@sha256:abc123...

Exercice 1 : Générer un SBOM avec Syft

Syft est un outil open-source d’Anchore qui génère des SBOMs en analysant les images de conteneurs, les systèmes de fichiers et les archives. Il prend en charge plusieurs formats de sortie, notamment SPDX et CycloneDX — les deux standards SBOM dominants.

Générer un SBOM SPDX

syft $IMAGE -o spdx-json=sbom.spdx.json

Inspecter la sortie :

cat sbom.spdx.json | jq '.packages | length'
# Sortie : 287 (le nombre varie selon le contenu de l'image)

# Afficher les paquets détectés
cat sbom.spdx.json | jq '.packages[] | {name: .name, version: .versionInfo, license: .licenseDeclared}' | head -40

Générer un SBOM CycloneDX

syft $IMAGE -o cyclonedx-json=sbom.cyclonedx.json

Inspecter la sortie CycloneDX :

cat sbom.cyclonedx.json | jq '.components | length'

# Afficher les composants avec les licences
cat sbom.cyclonedx.json | jq '.components[] | {name: .name, version: .version, type: .type}' | head -40

SPDX vs. CycloneDX : Différences clés

Caractéristique SPDX CycloneDX
Origine Linux Foundation OWASP
Focus principal Conformité des licences et PI Sécurité et analyse des risques
Norme ISO ISO/IEC 5962:2021 ECMA-424
Données de vulnérabilité Support natif limité Champ vulnerabilities de premier ordre
Formats JSON, RDF, XML, YAML, tag-value JSON, XML, Protobuf
Idéal pour Conformité réglementaire, audits de licences DevSecOps, suivi des vulnérabilités

Pour ce lab, nous utilisons principalement SPDX JSON car c’est le format requis par de nombreuses normes d’approvisionnement gouvernementales et il s’associe bien avec les attestations Cosign. Cependant, les deux formats sont pris en charge par Grype et Cosign.

Générer un résumé lisible

syft $IMAGE -o syft-table

Cela affiche un tableau de tous les paquets avec le nom, la version et le type — utile pour une revue rapide pendant le développement.

Exercice 2 : Scanner le SBOM pour les vulnérabilités avec Grype

Grype est le scanner de vulnérabilités d’Anchore. Il peut scanner les images de conteneurs directement, mais il peut également scanner un fichier SBOM — ce qui est nettement plus rapide car il saute l’étape d’analyse de l’image.

Scanner le SBOM

grype sbom:./sbom.spdx.json

Exemple de sortie :

NAME          INSTALLED  FIXED-IN   TYPE  VULNERABILITY   SEVERITY
lodash        4.17.21               npm   CVE-2025-XXXXX  Medium
node          20.10.0    20.11.1    apk   CVE-2024-22019  High
libcrypto3    3.1.4-r1   3.1.4-r3   apk   CVE-2024-0727   Medium

Filtrer par sévérité

# Afficher uniquement les vulnérabilités Critiques et Hautes
grype sbom:./sbom.spdx.json --fail-on critical

# Sortie des résultats en JSON pour traitement CI
grype sbom:./sbom.spdx.json -o json > vulnerabilities.json

# Compter les vulnérabilités par sévérité
cat vulnerabilities.json | jq '[.matches[].vulnerability.severity] | group_by(.) | map({severity: .[0], count: length})'

Scan d’image vs. scan de SBOM

Il existe une distinction importante entre le scan direct de l’image et le scan du SBOM :

# Scan direct de l'image — Grype télécharge et analyse les couches de l'image
grype $IMAGE

# Scan du SBOM — Grype lit la liste de paquets pré-générée
grype sbom:./sbom.spdx.json
Approche Vitesse Précision Cas d’utilisation
Scan direct de l’image Plus lent (télécharge les couches) Découvre tous les paquets Première analyse, développement local
Scan du SBOM Rapide (lit le fichier JSON) Limité au contenu du SBOM Pipelines CI, scans répétés, audit

Le scan du SBOM est aussi complet que le SBOM lui-même. Si Syft a manqué un paquet (par exemple, un binaire compilé statiquement), Grype ne trouvera pas de vulnérabilités pour celui-ci. Pour une couverture maximale, générez le SBOM avec le flag --catalogers all de Syft.

Exercice 3 : Attacher le SBOM comme attestation Cosign

Une attestation est une déclaration signée concernant un artefact logiciel. En attachant le SBOM comme attestation, vous liez cryptographiquement le SBOM au digest spécifique de l’image — n’importe qui peut vérifier que le SBOM a été produit pour cette image exacte et qu’il n’a pas été falsifié.

Attacher l’attestation SBOM

En utilisant le flux keyless (Sigstore Fulcio) de Cosign :

cosign attest --predicate sbom.spdx.json \
  --type spdxjson \
  --yes \
  $IMAGE

Cette commande :

  1. Ouvre un navigateur pour l’authentification OIDC (signature keyless via Fulcio)
  2. Crée une attestation in-toto avec votre SBOM comme prédicat
  3. Signe l’attestation et l’enregistre dans le journal de transparence Rekor
  4. Pousse l’attestation vers le registre aux côtés de l’image

Vérifier l’attestation

cosign verify-attestation \
  --type spdxjson \
  --certificate-identity=YOUR_EMAIL@example.com \
  --certificate-oidc-issuer=https://accounts.google.com \
  $IMAGE | jq '.payload | @base64d | fromjson | .predicate'

Remplacez l’identité du certificat et l’émetteur OIDC par les valeurs correspondant à votre identité Sigstore. Dans les environnements CI (GitHub Actions), ceux-ci seraient :

--certificate-identity=https://github.com/YOUR_ORG/YOUR_REPO/.github/workflows/build.yml@refs/heads/main
--certificate-oidc-issuer=https://token.actions.githubusercontent.com

Inspecter l’attestation dans le registre

# Lister les référents (registres OCI 1.1)
cosign tree $IMAGE

Vous devriez voir l’attestation listée comme référent attaché au manifeste de l’image. L’attestation est stockée comme artefact OCI dans le même dépôt, tagué avec une convention sha256-<digest>.att.

Exercice 4 : Construire le pipeline complet dans GitHub Actions

Nous automatisons maintenant tout dans un seul flux de travail CI/CD. Ce pipeline construit l’image, génère le SBOM, scanne les vulnérabilités et attache le SBOM comme attestation signée.

Créez .github/workflows/sbom-pipeline.yml :

name: SBOM Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

permissions:
  contents: read
  packages: write
  id-token: write  # Required for Cosign keyless signing
  attestations: write

jobs:
  build-and-attest:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to GHCR
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

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

      - name: Get image digest
        id: digest
        run: |
          echo "image=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}" >> $GITHUB_OUTPUT

      - name: Install Syft
        uses: anchore/sbom-action/download-syft@v0

      - name: Generate SPDX SBOM
        run: |
          syft ${{ steps.digest.outputs.image }} -o spdx-json=sbom.spdx.json
          echo "### SBOM Summary" >> $GITHUB_STEP_SUMMARY
          echo "Package count: $(cat sbom.spdx.json | jq '.packages | length')" >> $GITHUB_STEP_SUMMARY

      - name: Install Grype
        uses: anchore/scan-action/download-grype@v4

      - name: Scan SBOM for vulnerabilities
        run: |
          grype sbom:./sbom.spdx.json -o json > vulnerabilities.json
          grype sbom:./sbom.spdx.json -o table >> $GITHUB_STEP_SUMMARY

          # Fail if critical vulnerabilities are found
          CRITICAL_COUNT=$(cat vulnerabilities.json | jq '[.matches[] | select(.vulnerability.severity=="Critical")] | length')
          echo "Critical vulnerabilities: $CRITICAL_COUNT"
          if [ "$CRITICAL_COUNT" -gt 0 ]; then
            echo "::error::Found $CRITICAL_COUNT critical vulnerabilities. Failing pipeline."
            exit 1
          fi

      - name: Install Cosign
        uses: sigstore/cosign-installer@v3

      - name: Attest SBOM
        run: |
          cosign attest --predicate sbom.spdx.json \
            --type spdxjson \
            --yes \
            ${{ steps.digest.outputs.image }}

      - name: Verify attestation
        run: |
          cosign verify-attestation \
            --type spdxjson \
            --certificate-identity-regexp="https://github.com/${{ github.repository }}/" \
            --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
            ${{ steps.digest.outputs.image }}

      - name: Upload SBOM as artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom-spdx
          path: sbom.spdx.json
          retention-days: 90

      - name: Upload vulnerability report
        uses: actions/upload-artifact@v4
        if: always()
        with:
          name: vulnerability-report
          path: vulnerabilities.json
          retention-days: 90

Ce flux de travail utilise la signature keyless via l’identité OIDC de GitHub Actions. Aucune clé privée n’est stockée dans les secrets — Cosign obtient un certificat éphémère auprès de l’autorité de certification Fulcio de Sigstore, et l’événement de signature est enregistré dans le journal de transparence Rekor.

Le pipeline échoue si des vulnérabilités critiques sont détectées. Ajustez le seuil en modifiant le filtre de sévérité dans l’étape de scan Grype.

Exercice 5 : Construire le pipeline dans GitLab CI

Le pipeline équivalent dans GitLab CI utilise les mêmes outils mais s’adapte au modèle basé sur les étapes de GitLab et à son registre de conteneurs intégré.

Créez .gitlab-ci.yml :

stages:
  - build
  - sbom
  - scan
  - attest

variables:
  IMAGE: $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
  IMAGE_DIGEST: ""

build:
  stage: build
  image: docker:24
  services:
    - docker:24-dind
  variables:
    DOCKER_TLS_CERTDIR: "/certs"
  script:
    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
    - docker build -t $IMAGE .
    - docker push $IMAGE
    - |
      DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' $IMAGE)
      echo "IMAGE_DIGEST=$DIGEST" >> build.env
  artifacts:
    reports:
      dotenv: build.env

generate-sbom:
  stage: sbom
  image: alpine:3.19
  needs: [build]
  before_script:
    - apk add --no-cache curl jq
    - curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
  script:
    - syft $IMAGE_DIGEST -o spdx-json=sbom.spdx.json
    - echo "Package count:" $(cat sbom.spdx.json | jq '.packages | length')
  artifacts:
    paths:
      - sbom.spdx.json
    expire_in: 90 days

scan-vulnerabilities:
  stage: scan
  image: alpine:3.19
  needs: [generate-sbom]
  before_script:
    - apk add --no-cache curl jq
    - curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin
  script:
    - grype sbom:./sbom.spdx.json -o json > vulnerabilities.json
    - grype sbom:./sbom.spdx.json -o table
    - |
      CRITICAL_COUNT=$(cat vulnerabilities.json | jq '[.matches[] | select(.vulnerability.severity=="Critical")] | length')
      echo "Critical vulnerabilities found: $CRITICAL_COUNT"
      if [ "$CRITICAL_COUNT" -gt 0 ]; then
        echo "ERROR: Critical vulnerabilities detected. Failing pipeline."
        exit 1
      fi
  artifacts:
    paths:
      - vulnerabilities.json
    expire_in: 90 days
    when: always

attest-sbom:
  stage: attest
  image: alpine:3.19
  needs: [build, generate-sbom, scan-vulnerabilities]
  id_tokens:
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  before_script:
    - apk add --no-cache curl
    - curl -sSfL https://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64 -o /usr/local/bin/cosign
    - chmod +x /usr/local/bin/cosign
  script:
    - cosign attest --predicate sbom.spdx.json
        --type spdxjson
        --yes
        $IMAGE_DIGEST
    - cosign verify-attestation
        --type spdxjson
        --certificate-identity-regexp="https://gitlab.com/$CI_PROJECT_PATH//"
        --certificate-oidc-issuer=https://gitlab.com
        $IMAGE_DIGEST

Différences clés par rapport à la version GitHub Actions :

  • GitLab utilise des stages au lieu d’un seul job avec des étapes
  • Le digest de l’image est transmis entre les stages via des artefacts dotenv
  • Le jeton OIDC de GitLab est exposé via id_tokens et la variable SIGSTORE_ID_TOKEN
  • L’émetteur OIDC pour la vérification est https://gitlab.com

Exercice 6 : Vérifier le SBOM au déploiement

Générer et attester des SBOMs n’est que la moitié du travail. Le véritable avantage en termes de sécurité vient de l’application de la vérification au moment du déploiement — en rejetant toute image dépourvue d’attestation SBOM valide.

Option A : Vérifier dans un script de déploiement

#!/bin/bash
# deploy.sh — Vérifier l'attestation SBOM avant le déploiement
set -euo pipefail

IMAGE="$1"

echo "Vérification de l'attestation SBOM pour : $IMAGE"

cosign verify-attestation \
  --type spdxjson \
  --certificate-identity-regexp="https://github.com/YOUR_ORG/YOUR_REPO/" \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  "$IMAGE" > /dev/null 2>&1

if [ $? -eq 0 ]; then
  echo "Attestation SBOM vérifiée avec succès."
  kubectl set image deployment/myapp myapp="$IMAGE"
else
  echo "ERREUR : La vérification de l'attestation SBOM a échoué. Déploiement bloqué."
  exit 1
fi

Option B : Appliquer avec Kyverno dans Kubernetes

Kyverno est un moteur de politiques natif Kubernetes qui peut vérifier les signatures et attestations d’images au moment de l’admission. La politique suivante rejette tout pod dont l’image ne dispose pas d’une attestation SBOM valide.

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-sbom-attestation
spec:
  validationFailureAction: Enforce
  webhookTimeoutSeconds: 30
  rules:
    - name: check-sbom-attestation
      match:
        any:
          - resources:
              kinds:
                - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/YOUR_ORG/*"
          attestations:
            - type: spdxjson
              attestors:
                - entries:
                    - keyless:
                        subject: "https://github.com/YOUR_ORG/YOUR_REPO/.github/workflows/sbom-pipeline.yml@refs/heads/main"
                        issuer: "https://token.actions.githubusercontent.com"
                        rekor:
                          url: https://rekor.sigstore.dev
              conditions:
                - all:
                    - key: "{{ len(spdxVersion) }}"
                      operator: GreaterThan
                      value: "0"

Appliquer la politique :

kubectl apply -f require-sbom-attestation.yaml

Test d’admission : image avec attestation

# Ceci devrait être ADMIS
kubectl run test-admitted \
  --image=ghcr.io/YOUR_ORG/sbom-lab-app@sha256:abc123... \
  --restart=Never

# Sortie attendue :
# pod/test-admitted created

Test d’admission : image sans attestation

# Ceci devrait être REJETÉ
kubectl run test-rejected \
  --image=ghcr.io/YOUR_ORG/sbom-lab-app:unattested \
  --restart=Never

# Sortie attendue :
# Error from server: admission webhook "mutate.kyverno.svc-fail" denied the request:
# resource Pod/default/test-rejected was blocked due to the following policies:
# require-sbom-attestation:
#   check-sbom-attestation: 'image verification failed for ghcr.io/YOUR_ORG/sbom-lab-app:unattested:
#     attestation spdxjson not found'

C’est la boucle d’application qui rend les SBOMs opérationnellement significatifs — sans vérification au déploiement, la génération de SBOM n’est que de la documentation.

Exercice 7 : Comparaison de SBOM entre versions

Lorsque vous publiez une nouvelle version, vous devez comprendre ce qui a changé dans votre arbre de dépendances. La comparaison des SBOMs entre versions révèle les paquets ajoutés, supprimés et mis à jour — essentiel pour évaluer les nouveaux risques.

Étape 1 : Générer les SBOMs pour deux versions

# Générer le SBOM pour v1.0.0
syft ghcr.io/YOUR_GITHUB_USERNAME/sbom-lab-app:v1.0.0 -o spdx-json=sbom-v1.spdx.json

# Générer le SBOM pour v1.1.0 (après mise à jour des dépendances)
syft ghcr.io/YOUR_GITHUB_USERNAME/sbom-lab-app:v1.1.0 -o spdx-json=sbom-v2.spdx.json

Étape 2 : Extraire les listes de paquets

# Extraire les listes de paquets triées
cat sbom-v1.spdx.json | jq -r '.packages[] | "\(.name)@\(.versionInfo)"' | sort > packages-v1.txt
cat sbom-v2.spdx.json | jq -r '.packages[] | "\(.name)@\(.versionInfo)"' | sort > packages-v2.txt

Étape 3 : Comparer les listes de paquets

diff --unified packages-v1.txt packages-v2.txt

Exemple de sortie :

--- packages-v1.txt
+++ packages-v2.txt
@@ -12,7 +12,8 @@
  express@4.18.2
  lodash@4.17.21
- axios@1.6.0
+ axios@1.7.2
+ helmet@7.1.0
  mime-types@2.1.35

Étape 4 : Identifier les vulnérabilités nouvellement introduites

# Scanner uniquement les paquets nouveaux/modifiés
grype sbom:./sbom-v2.spdx.json -o json > vulns-v2.json
grype sbom:./sbom-v1.spdx.json -o json > vulns-v1.json

# Comparer le nombre de vulnérabilités
echo "Vulnérabilités v1.0.0 : $(cat vulns-v1.json | jq '.matches | length')"
echo "Vulnérabilités v1.1.0 : $(cat vulns-v2.json | jq '.matches | length')"

# Trouver les NOUVELLES vulnérabilités dans v1.1.0
comm -13 \
  <(cat vulns-v1.json | jq -r '.matches[].vulnerability.id' | sort -u) \
  <(cat vulns-v2.json | jq -r '.matches[].vulnerability.id' | sort -u)

Ce processus de comparaison peut être automatisé dans la CI pour commenter les pull requests avec les changements de dépendances, offrant aux réviseurs une visibilité sur l’impact de la chaîne d’approvisionnement avant la fusion.

Nettoyage

Supprimez les ressources créées pendant ce lab :

# Supprimer les fichiers locaux
rm -f sbom.spdx.json sbom.cyclonedx.json vulnerabilities.json
rm -f sbom-v1.spdx.json sbom-v2.spdx.json packages-v1.txt packages-v2.txt
rm -f vulns-v1.json vulns-v2.json

# Supprimer l'image de test de GHCR (nécessite gh CLI)
gh api -X DELETE /user/packages/container/sbom-lab-app/versions/PACKAGE_VERSION_ID

# Supprimer la politique Kyverno
kubectl delete clusterpolicy require-sbom-attestation

# Supprimer les pods de test
kubectl delete pod test-admitted test-rejected --ignore-not-found

# Supprimer le dépôt local
cd .. && rm -rf sbom-pipeline-lab

Points clés à retenir

  • Les SBOMs sont un pilier de la sécurité de la chaîne d’approvisionnement — ils fournissent l’inventaire qui permet l’analyse des vulnérabilités, la conformité des licences et la vérification de la provenance.
  • Syft génère des SBOMs dans tous les formats majeurs — SPDX pour la conformité réglementaire, CycloneDX pour les flux de travail de sécurité, tous deux pris en charge dans l’écosystème.
  • Scanner le SBOM est plus rapide que scanner l’image — utilisez Grype avec le préfixe sbom: dans les pipelines CI pour des boucles de rétroaction rapides sans télécharger les couches de l’image.
  • Les attestations Cosign lient cryptographiquement les SBOMs aux images — les attestations signées prouvent qu’un SBOM spécifique a été produit pour un digest d’image spécifique, stocké dans le registre aux côtés de l’image.
  • La vérification au déploiement rend les SBOMs exécutoires — sans contrôle d’admission (Kyverno, OPA Gatekeeper ou scripts de déploiement), les SBOMs restent de la documentation sans force contraignante.
  • Les comparaisons de SBOM révèlent les changements de la chaîne d’approvisionnement entre versions — l’automatisation de la comparaison des dépendances dans la CI donne aux équipes une visibilité sur les nouveaux risques avant que le code n’atteigne la production.

Prochaines étapes

Continuez à construire votre pratique de sécurité de la chaîne d’approvisionnement avec ces guides connexes :