À qui s’adresse « SBOM et supply chain (SLSA) DevOps » ?

Aux praticiens DevOps / platform / SRE qui veulent un lab concret 2026 sur sbom supply chain. Prérequis et niveau sont indiqués en tête de page.

Faut-il un cluster ou un compte cloud pour sbom supply chain ?

Oui dans la plupart des labs WOW (kube local, Free Tier ou sandbox). Suivez la section Prérequis pour outils, droits et coûts.

Ce tuto remplace-t-il la doc officielle ?

Non : c’est un parcours hands-on orienté DevOps Elastic Hayway. Gardez la doc upstream pour les API et breaking changes.

SBOM et supply chain (SLSA) DevOps

À la fin de ce tutoriel, vous saurez expliquer pourquoi un SBOM est indispensable, choisir SPDX ou CycloneDX, générer un inventaire avec Syft (et Trivy), le versionner comme artefact CI, relier le tout aux niveaux SLSA, et poser un garde-fou « pas de SBOM = pas de release » — région lab ca-central-1.

Niveau : Intermédiaire · Temps estimé : 50–70 min · Versions testées : Syft, Trivy, Docker, GitHub Actions, GitLab CI, SLSA provenance (concepts 2024–2026) · Dernière vérification : 2026-09-11 · Region : ca-central-1

Slug : wow-sbom-supply-chain · Série : WOW (32/50) · Mot-clé SEO : sbom supply chain · Publish : READY (push centralisé Maître)

← Précédent : Trivy : scan images et IaC en CI · → Suivant : Cosign / Sigstore : signer ses images · Aussi : Pipeline DevSecOps · Conftest CI

Prérequis

Bases Docker + Git + CI (GitHub Actions ou GitLab CI)
Notions images/CVE — Trivy
Compte GitHub (ou GitLab) pour le lab pipeline
Optionnel : profil AWS lab en ca-central-1 si vous poussez un artefact SBOM vers S3
Aucun cluster Kubernetes requis pour le lab minimal

Coût estimé : 0 € en local / runners CI. Si vous utilisez S3 en lab, créez un bucket jetable puis détruisez-le (Free Tier).

export AWS_PROFILE=lab
export AWS_DEFAULT_REGION=ca-central-1

Ce que nous allons construire

Lab SBOM + SLSA (WOW 32/50) — ca-central-1
  ├── App minimal Docker (Go/Python) + Dockerfile
  ├── Syft → SBOM CycloneDX + SPDX
  ├── Trivy sbom / scan croisé CVE
  ├── Artefact CI versionné (release + retention)
  ├── Garde-fou : job fail si SBOM absent
  ├── Concepts SLSA L1→L3 + lien Cosign
  └── Troubleshooting + FAQ + quiz

(Schéma — alt : « Build → SBOM Syft → artefact CI → scan Trivy → attestation SLSA / Cosign → deploy seulement si inventaire OK ».)

Étape 1 — Pourquoi un SBOM en 2026 ?

Un Software Bill of Materials liste les composants d’un artefact (OS packages, libs, versions, licences, hashes). Sans SBOM, vous ne savez pas quoi patcher quand une CVE sort (Log4Shell, xz, etc.).

Besoin	Sans SBOM	Avec SBOM
Réponse CVE	Grep manuel, espoir	Requête sur inventaire
Audit / client	« On croit que… »	Fichier machine-readable
Conformité	Excel fantôme	SPDX / CycloneDX
Supply chain	Boîte noire	Preuve + attestation

Chez DevOps Elastic Hayway : SBOM à chaque build (shift-left) + scan Trivy + signature Cosign. Le SBOM ne remplace pas le scan : il nomme ce que le scan doit couvrir.

Étape 2 — SPDX vs CycloneDX (et SLSA en une phrase)

SPDX (Linux Foundation) : standard mature, fort sur licences et conformité.
CycloneDX (OWASP) : orienté sécurité / DevSecOps, enrichi vulnérabilités, services, VEX.

Pour un pipeline CI moderne, CycloneDX JSON est souvent le plus pratique ; gardez SPDX si un client/auditeur l’exige. Beaucoup d’outils (Syft, Trivy) exportent les deux.

SLSA (Supply-chain Levels for Software Artifacts) : cadre de niveaux (L1 → L3+ selon l’évolution du modèle) qui exigent build reproductible, provenance, isolation des builders. Le SBOM documente le contenu ; la provenance SLSA atteste comment / où / par qui l’artefact a été produit. Les deux se complètent.

Étape 3 — Lab local : image + Syft

mkdir -p ~/lab-sbom-slsa && cd ~/lab-sbom-slsa

cat > Dockerfile << 'EOF'
FROM python:3.12-slim
WORKDIR /app
RUN pip install --no-cache-dir requests==2.32.3
COPY app.py .
CMD ["python", "app.py"]
EOF

cat > app.py << 'EOF'
import requests
print("lab-sbom ok", requests.__version__)
EOF

docker build -t lab-sbom:local .

Installer Syft :

curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
syft version

Générer CycloneDX et SPDX :

syft lab-sbom:local -o cyclonedx-json > sbom.cdx.json
syft lab-sbom:local -o spdx-json > sbom.spdx.json
wc -c sbom.cdx.json sbom.spdx.json
jq '.metadata.component.name, (.components|length)' sbom.cdx.json

Vous devez voir requests (et la couche Debian/slim) dans les composants. C’est votre inventaire machine-readable.

Étape 4 — Croiser avec Trivy

# Scan image classique
trivy image --severity HIGH,CRITICAL lab-sbom:local

# Scanner à partir du SBOM (si votre version Trivy le supporte)
trivy sbom sbom.cdx.json

Workflow DEH recommandé :

Build image
Syft → SBOM attaché à la release / registry
Trivy sur l’image (et/ou le SBOM)
Cosign signe image + attestation (tuto suivant)
Deploy seulement si seuils CVE + présence SBOM OK

Ne stockez pas le SBOM « dans un ticket Slack » : c’est un artefact de release, même cycle de vie que l’image.

Étape 5 — GitHub Actions (fail-closed)

# .github/workflows/sbom.yml
name: sbom-supply-chain
on:
  push:
    branches: [main]
  pull_request:

jobs:
  build-sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
      id-token: write   # utile plus tard pour OIDC / Fulcio
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t ghcr.io/${{ github.repository }}/lab-sbom:${{ github.sha }} .

      - name: Install Syft
        run: curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

      - name: Generate SBOM (CycloneDX)
        run: |
          syft "ghcr.io/${{ github.repository }}/lab-sbom:${{ github.sha }}" 
            -o cyclonedx-json > sbom.cdx.json
          test -s sbom.cdx.json || (echo "SBOM vide" && exit 1)

      - name: Upload SBOM artifact
        uses: actions/upload-artifact@v4
        with:
          name: sbom-${{ github.sha }}
          path: sbom.cdx.json
          retention-days: 90

      - name: Trivy (HIGH/CRITICAL)
        uses: aquasecurity/trivy-action@0.28.0
        with:
          image-ref: ghcr.io/${{ github.repository }}/lab-sbom:${{ github.sha }}
          severity: HIGH,CRITICAL
          exit-code: "1"

Fail-closed : test -s sbom.cdx.json + Trivy exit-code: 1. Jamais continue-on-error: true « pour voir » en main.

Variante lab AWS : après génération, aws s3 cp sbom.cdx.json s3://deh-lab-sbom-${ACCOUNT}/ca-central-1/${SHA}.cdx.json avec OIDC (voir GitHub Actions OIDC AWS), puis destruction du bucket.

Étape 6 — Variante GitLab CI

# .gitlab-ci.yml (extrait)
stages: [build, sbom, scan]

build:
  stage: build
  image: docker:27
  services: [docker:27-dind]
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

sbom:
  stage: sbom
  image: anchore/syft:latest
  script:
    - syft $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA -o cyclonedx-json > sbom.cdx.json
    - test -s sbom.cdx.json
  artifacts:
    paths: [sbom.cdx.json]
    expire_in: 90 days

scan:
  stage: scan
  image: aquasec/trivy:latest
  script:
    - trivy image --exit-code 1 --severity HIGH,CRITICAL $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Étape 7 — Niveaux SLSA (pratique DevOps)

Niveau (esprit)	Intention	Ce que vous faites concrètement
L1	Processus documenté	Build scripté + SBOM produit à chaque build
L2	Build service + provenance	CI hébergée, logs, attestation de provenance
L3	Isolation forte	Builders éphémères, secrets séparés, attestations vérifiables (Sigstore)

Checklist minimale DEH pour viser « L2-friendly » :

Source versionnée (Git) ; tags immuables sur releases
Build uniquement via CI (pas de laptop « golden »)
SBOM + digest image publiés ensemble
Provenance / attestation (Cosign attest) — détail dans Cosign / Sigstore
Policies admission (Kyverno/Gatekeeper) qui exigent signature + SBOM en prod

Le SBOM seul ne fait pas SLSA L3. Il est le contenu ; SLSA + Sigstore sont la preuve de production.

Étape 8 — Bonnes pratiques et pièges

Un digest, un SBOM : attachez le SBOM au digest d’image (sha256:…), pas seulement au tag latest (mutable).
Licences : le SBOM SPDX aide à détecter des licences copyleft surprises avant la prod.
VEX / exploitability : quand une CVE apparaît dans une dep transitive non atteignable, documentez l’analyse (VEX) plutôt que d’ignorer silencieusement Trivy.
Secrets : un SBOM ne doit jamais contenir de credentials ; auditez vos générateurs.
Multi-arch : générez un SBOM (ou un set) par architecture (amd64 / arm64) si vous publiez des manifests multi-plateformes.
Rétention : alignez la durée de conservation SBOM sur celle des releases (90 jours mini en CI, plus long en S3 versionné ca-central-1 pour les releases clients).
Revue PR : exigez le job sbom vert comme check obligatoire sur main — même discipline que les tests.

Exemple de vérification rapide après download d’artefact :

test -s sbom.cdx.json
jq -e '.bomFormat == "CycloneDX"' sbom.cdx.json
jq -r '.components[]?.name' sbom.cdx.json | sort -u | head

Troubleshooting

Symptôme	Cause / correction
SBOM « vide » / trop petit	Mauvaise ref image ; rebuild avant Syft
`requests` absent	Layer pip non scannée : vérifiez l’image taguée
Trivy OK, audit KO	Format attendu SPDX vs CycloneDX — exportez les deux
Artefact CI disparu	`retention-days` trop bas ; archivez sur S3 `ca-central-1`
Syft version diverge local/CI	Pinez la version Syft (tag image ou install script pin)
Confusion SBOM vs attestation	SBOM = inventaire ; attestation SLSA = métadonnées de build

FAQ

SBOM remplace-t-il Trivy ?
Non. SBOM liste ; Trivy (ou équivalent) évalue les CVE / misconfigs. Les deux sont obligatoires en DevSecOps.

CycloneDX ou SPDX ?
CycloneDX pour le flux sécu CI ; SPDX si conformité licences / client. Syft peut produire les deux.

Faut-il un SBOM par commit ?
Oui pour les images poussées. Au minimum chaque release + chaque tag déployable.

Où stocker le SBOM ?
Artefact CI + registry (OCI referrers / attestation) + éventuellement S3 versionné en ca-central-1.

SLSA est-il une certification officielle ?
C’est un cadre de bonnes pratiques / niveaux. Vous « visez » un niveau via contrôles techniques, pas un badge magique.

Quiz (5 questions)

1. Un SBOM sert surtout à :
– A. Remplacer les tests unitaires
– B. Inventorier composants/versions/licences d’un artefact
– C. Autoscaler Kubernetes

2. Format souvent préféré en pipeline DevSecOps :
– A. PDF scanné
– B. CycloneDX JSON (et SPDX si besoin audit)
– C. Uniquement un README

3. Outil DEH pour générer le SBOM dans ce tuto :
– A. kubectl only
– B. Syft (+ croisement Trivy)
– C. Terraform plan

4. SLSA et SBOM :
– A. Identiques
– B. Complémentaires : contenu (SBOM) + provenance/build (SLSA)
– C. Incompatibles

5. Région lab DevOps Elastic Hayway ici :
– A. us-east-1 obligatoire
– B. ca-central-1
– C. ap-south-1

Réponses : 1‑B · 2‑B · 3‑B · 4‑B · 5‑B

Pour aller plus loin

Syft (Anchore)
CycloneDX · SPDX
SLSA
Trivy : scan images et IaC en CI (WOW 31)
Cosign / Sigstore (WOW 33)
Pipeline DevSecOps de A à Z
GitHub Actions OIDC AWS · Conftest CI

Maillage série WOW


← Précédent	Trivy : scan images et IaC en CI
→ Suivant	Cosign / Sigstore : signer ses images
Aussi	DevSecOps · Conftest · Falco

Meta publication (SEO)

Title SEO : SBOM et supply chain (SLSA) DevOps (guide FR)
Meta description : SBOM SPDX/CycloneDX + SLSA : Syft/Trivy, artefacts CI, provenance, lab GitHub Actions, région ca-central-1 — DevOps Elastic Hayway.
Focus keyword : sbom supply chain
Secondary : sbom cyclonedx, sbom spdx, slsa devops, syft sbom, supply chain security
Image : assets/web/devopelastichayway/cover-wow-sbom-supply-chain-1200x630.webp (à générer)
Catégorie : WOW / Supply chain · Niveau : Intermédiaire
URL cible : https://devopelastichayway.com/tutoriels/wow-sbom-supply-chain/
Post live : N/A (nouveau) · slug wow-sbom-supply-chain · Publish : READY (Maître centralise le push WP-CLI)

← Catalogue Tutoriels

Pour aller plus loin — hubs live

Hub DevOps

Retour parcours Catalogue Tutoriels — hub de la série et leçons sœurs.