Supply chain des images : SBOM, scan, signature et policies

Vous buildez des images, mais savez-vous vraiment ce qu’elles contiennent ? Une image peut embarquer des centaines de dépendances, dont certaines avec des vulnérabilités connues. Ce guide vous donne les bases DevSecOps pour sécuriser votre supply chain d’images : SBOM, scan de vulnérabilités, signatures et politiques. Une introduction pragmatique pour savoir par où commencer.

Ce que vous allez apprendre

• SBOM : la liste d’ingrédients de votre image (et pourquoi c’est obligatoire dans certains contextes)
• Scan de vulnérabilités : détecter les CVE dans vos images
• Signature d’images : prouver l’origine et l’intégrité
• Policies : appliquer des règles automatiques (pas d’image root, pas de CVE critique)
• Où placer ces contrôles dans la CI/CD

TL;DR — À mettre en place en priorité

1. Générer un SBOM à chaque build : syft <image> -o cyclonedx-json
2. Scanner avant push : trivy image --exit-code 1 --severity CRITICAL <image>
3. Signer l’image validée : cosign sign <image> (keyless ou avec clé)
4. Vérifier au déploiement : policy Kyverno/OPA pour bloquer les images non signées
5. Progressivité : alerter d’abord, bloquer ensuite

Carte mentale : qui fait quoi ?

Avant de plonger dans les détails, voici ce que chaque contrôle apporte :

Contrôle	Question à laquelle il répond	Exemple
SBOM	”Qu’y a-t-il dans mon image ?”	Liste des 234 packages avec versions
Scan	”Y a-t-il des vulnérabilités connues ?”	CVE critique dans OpenSSL
Signature	”Qui a produit cette image ? A-t-elle été modifiée ?”	Certificat lié à ci@monorg.com
Policy	”Cette image respecte-t-elle nos règles ?”	Bloque si non signé ou CVE critique

Glissez pour voir

Scan ≠ Signature : deux protections complémentaires

• Scan détecte les vulnérabilités connues (CVE publiées) — mais pas une backdoor injectée volontairement.
• Signature prouve l’origine et l’intégrité — mais ne dit rien sur les vulnérabilités.

Vous avez besoin des deux : le scan pour la qualité, la signature pour la confiance.

Vocabulaire minimal

Ces termes reviennent dans tout le guide :

Terme	Définition simple
Tag	Alias mutable (nginx:1.25). Peut pointer vers une image différente demain.
Digest	Hash immuable (sha256:abc123...). Garantit exactement la même image.
Attestation	Artefact OCI attaché à l’image (signature, SBOM, provenance).
Keyless	Signature sans clé privée à gérer : votre identité OIDC (GitHub, Google) + certificat éphémère.
VEX	Document indiquant si une CVE est réellement exploitable dans votre contexte.

Glissez pour voir

Le problème : la supply chain logicielle

Quand vous faites FROM python:3.11, vous héritez de :

• L’image de base Debian (ou Alpine)
• Des centaines de packages système
• Python et ses dépendances C
• Tout ce que les mainteneurs ont mis dedans

Puis votre pip install ajoute :

• Vos dépendances Python
• Les dépendances de vos dépendances (dépendances transitives)
• Potentiellement des packages compromis (typosquatting, mainteneur malveillant)

Résultat : votre image de 200 Mo contient peut-être des milliers de composants dont vous ignorez l’existence — et certains peuvent avoir des vulnérabilités connues (CVE).

Attaques supply chain documentées

Quelques incidents récents illustrent les risques :

• Lottie Player (oct. 2024) : compromission du package npm @lottiefiles/lottie-player via takeover de compte mainteneur — détails LottieFiles.
• PyPI : campagnes récurrentes de typosquatting et distribution de malwares — blog PyPI.
• Docker Hub : spam repos et images malveillantes détectés par Docker/JFrog — partenariat Docker/JFrog.
• XZ Utils backdoor : images Docker contenant la version compromise découvertes des mois après l’incident — The Hacker News.

Le registre peut supprimer le package, mais les builds déjà effectués restent compromis.

SBOM : la liste d’ingrédients

Un SBOM (Software Bill of Materials) est un inventaire exhaustif de tous les composants d’un logiciel : packages système, bibliothèques, versions, licences.

L’analogie de l’étiquette alimentaire

C’est comme la liste d’ingrédients sur un emballage alimentaire. Si vous êtes allergique aux arachides, vous vérifiez l’étiquette. Si une CVE touche log4j, vous vérifiez le SBOM.

Formats de SBOM

Format	Standard	Utilisateurs typiques
SPDX	Linux Foundation	Compliance, licences
CycloneDX	OWASP	Sécurité, vulnérabilités
Syft JSON	Anchore	Usage interne

Glissez pour voir

Générer un SBOM avec Syft

# SBOM au format SPDX (ISO standard)
syft nginx:1.25 -o spdx-json > sbom.json

# SBOM au format CycloneDX (orienté sécurité)
syft nginx:1.25 -o cyclonedx-json > sbom.json

# Voir le contenu
cat sbom.json | jq '.packages | length'
# 234 packages trouvés

SBOM : une exigence de marché croissante

Le SBOM devient un prérequis dans plusieurs cadres réglementaires :

• États-Unis : Executive Order 14028 (2021) — exigé pour les fournisseurs du gouvernement fédéral.
• Union Européenne : Cyber Resilience Act (CRA) — reporting obligatoire dès septembre 2026, exigences produit au 11 décembre 2027 (synthèse Taylor Wessing).

Même si vous n’êtes pas directement concerné, vos clients pourraient l’exiger.

Scan de vulnérabilités : détecter les CVE

Un scanner de vulnérabilités compare les composants de votre image à des bases de données de CVE (Common Vulnerabilities and Exposures).

Les outils principaux

Outil	Type	Quand l’utiliser
Trivy	CLI open source	Choix par défaut : rapide, gratuit, SBOM + VEX + IaC
Grype	CLI open source	Alternative légère, intégration native avec Syft
Docker Scout	Docker	Si vous utilisez Docker Desktop (intégré)

Glissez pour voir

Quel scanner choisir ?

Trivy est le choix par défaut pour la plupart des équipes (scan images, IaC, secrets, VEX). Grype est une alternative légère si vous utilisez déjà Syft. Les résultats peuvent varier légèrement entre scanners.

Scanner avec Trivy

# Scan basique
trivy image nginx:1.25

# Seulement les CVE critiques et hautes
trivy image --severity CRITICAL,HIGH nginx:1.25

# Échouer si CVE critique (utile en CI)
trivy image --exit-code 1 --severity CRITICAL nginx:1.25

# Ignorer certaines CVE (avec fichier .trivyignore)
echo "CVE-2023-12345" > .trivyignore
trivy image --ignorefile .trivyignore nginx:1.25

Exemple de sortie

nginx:1.25 (debian 12.1)
=========================
Total: 42 (UNKNOWN: 0, LOW: 20, MEDIUM: 18, HIGH: 3, CRITICAL: 1)

┌──────────────────┬────────────────┬──────────┬─────────────────────┐
│     Library      │ Vulnerability  │ Severity │   Fixed Version     │
├──────────────────┼────────────────┼──────────┼─────────────────────┤
│ openssl          │ CVE-XXXX-YYYY  │ CRITICAL │ 3.0.12-1            │
│ curl             │ CVE-XXXX-ZZZZ  │ HIGH     │ 7.88.1-10+deb12u1   │
└──────────────────┴────────────────┴──────────┴─────────────────────┘

VEX : réduire le bruit des faux positifs

VEX (Vulnerability Exploitability eXchange) indique si une CVE est réellement exploitable dans votre contexte. Exemple : une CVE dans OpenSSL peut ne pas vous concerner si vous n’utilisez pas la fonction vulnérable.

# Trivy supporte OpenVEX pour filtrer les faux positifs
trivy image --vex ./vex.json myimage:latest

Le format OpenVEX (OpenSSF) est le standard recommandé. Il peut être attaché comme attestation OCI à côté du SBOM. Pour la génération de fichiers VEX, consultez la documentation Trivy sur VEX.

Signature d’images : prouver l’origine

Scanner détecte les vulnérabilités connues, mais pas les images compromises (backdoor, modification malveillante). La signature résout ce problème.

Ce que la signature garantit

Sans signature	Avec signature
N’importe qui peut push myapp:1.0	Seul le détenteur de la clé peut signer
Pas de preuve d’origine	Vérification cryptographique de l’éditeur
Modification silencieuse possible	Toute modification invalide la signature

Glissez pour voir

Signer avec Cosign

Cosign (projet Sigstore) est l’outil standard pour signer des images OCI.

# Mode clé : générer une paire de clés
cosign generate-key-pair
cosign sign --key cosign.key ghcr.io/mon-org/mon-app:1.0.0
cosign verify --key cosign.pub ghcr.io/mon-org/mon-app:1.0.0

# Mode keyless (recommandé en CI/CD) : identité OIDC + certificat éphémère
cosign sign ghcr.io/mon-org/mon-app:1.0.0
cosign verify \
  --certificate-identity=ci@monorg.com \
  --certificate-oidc-issuer=https://token.actions.githubusercontent.com \
  ghcr.io/mon-org/mon-app:1.0.0

Keyless vs clé privée

• Keyless : pas de clé à gérer, signature liée à votre identité OIDC (GitHub Actions, Google…). Idéal pour la CI/CD.
• Clé privée : contrôle total, mais vous devez protéger la clé (HSM, Vault…).

L’écosystème Sigstore (Fulcio, Rekor) est détaillé dans la section “Pour aller plus loin”.

Policies : appliquer des règles automatiques

Les policies (ou admission policies) bloquent le déploiement d’images non conformes. Elles peuvent vérifier :

• L’image est signée
• Aucune CVE critique
• L’image vient d’un registry autorisé
• L’image n’utilise pas root
• Un SBOM est attaché

Outils de policy

Outil	Niveau	Cas d’usage
OPA/Gatekeeper	Kubernetes	Admission controller
Kyverno	Kubernetes	Policies déclaratives
Connaisseur	Registry/K8s	Vérification signatures
Conftest	CI	Validation locale

Glissez pour voir

Exemple : bloquer les images non signées

# Kyverno policy
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-signature
      match:
        resources:
          kinds:
            - Pod
      verifyImages:
        - imageReferences:
            - "ghcr.io/mon-org/*"
          attestors:
            - entries:
                - keys:
                    publicKeys: |-
                      -----BEGIN PUBLIC KEY-----
                      ...
                      -----END PUBLIC KEY-----

Kyverno sait vérifier les attestations

Kyverno peut vérifier non seulement les signatures Cosign, mais aussi les attestations (provenance SLSA, SBOM attaché). Voir la documentation Kyverno verifyImages.

Bonnes pratiques supply chain

Déployer par digest, pas par tag

Les tags sont mutables : nginx:1.25 peut pointer vers une image différente demain (mise à jour du mainteneur, compromission). Le digest est immuable : sha256:abc123... garantit exactement la même image.

# ❓ Risqué : le tag peut changer
image: nginx:1.25

# ✅ Sûr : le digest est immuable
image: nginx@sha256:6af79ae5de407283dcea8b00d5c37ace95441fd58a8b1d2aa1ed93f5511bb18c

Utiliser des images de base approuvées

• Docker Official Images : images maintenues par Docker, auditées régulièrement.
• Images durcies : Chainguard, Wolfi, distroless (moins de packages = moins de surface d’attaque).
• Registry interne : miroir des images approuvées, avec scan automatique.

Provenance et attestations (SLSA)

La signature prouve l’origine, mais pas comment l’image a été construite. Les attestations de provenance (SLSA) décrivent le pipeline de build : quel code source, quel Dockerfile, quel runner CI.

# Générer une attestation de provenance (build GitHub Actions)
cosign attest --predicate provenance.json ghcr.io/mon-org/mon-app:1.0.0

# Vérifier l'attestation
cosign verify-attestation --type slsaprovenance ghcr.io/mon-org/mon-app:1.0.0

Où placer ces contrôles dans la CI/CD

Étape	Outil	Action si échec
Build	Syft	Générer SBOM (jamais d’échec)
Scan	Trivy	Bloquer si CVE CRITICAL
Sign	Cosign	Signer l’image validée
Deploy	Kyverno	Bloquer si non signé

Glissez pour voir

Commencer simple

Ne bloquez pas tout dès le début. Commencez par scanner et alerter (sans bloquer), puis durcissez progressivement les règles quand l’équipe est prête.

Testez vos connaissances

Vérifions que vous avez compris les bases de la sécurisation supply chain : SBOM, scan, signature et policies.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

📝 7 questions

⏱️ 5 min.

🎯 80%

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

▶ Démarrer le quiz

Lance le quiz et démarre le chronomètre

À retenir

1. Générer un SBOM à chaque build — inventaire exhaustif, exigé par certaines réglementations.
2. Scanner avant de push — détecte les CVE connues (Trivy recommandé).
3. Filtrer avec VEX — réduit le bruit en indiquant l’exploitabilité réelle.
4. Signer l’image validée — prouve l’origine et l’intégrité (Cosign/Sigstore).
5. Vérifier au déploiement — policy Kyverno/OPA bloque les images non conformes.
6. Déployer par digest — le tag est mutable, le digest est immuable.
7. Utiliser des base images approuvées — Official Images ou images durcies.
8. Pipeline : Build → SBOM → Scan → Sign → Policy → Deploy.
9. Progressivité : alerter d’abord, bloquer ensuite.

Pour aller plus loin

Trivy Scanner de vulnérabilités pour images et IaC

Cosign et Sigstore Signer, vérifier, et comprendre Fulcio/Rekor

Syft Générer des SBOM pour vos images

Sécuriser Docker Capabilities, seccomp, rootless — sécurité au runtime

Prochaine étape

Vous avez maintenant une vue d’ensemble de la supply chain des images. Pour approfondir, explorez les outils individuels ou passez à l’orchestration avec Docker Compose ou Kubernetes.

Docker Compose Orchestrer des applications multi-conteneurs

Introduction à Kubernetes L'orchestrateur de conteneurs en production

×

📖 Voir la documentation →