Chaque livrable doit arriver vérifiable : sa composition, sa signature, sa provenance. Cette famille (S3, domaine Fournisseurs) exige un SBOM à chaque livraison (CycloneDX ou SPDX), des artefacts signés avec attestation de provenance (niveau SLSA déclaré), et une intégrité contrôlée à la réception (signature, checksum). C'est précisément le contrôle qui aurait détecté la mise à jour piégée de SolarWinds.
Un SBOM obtenu une seule fois vieillit à chaque version : la dépendance vulnérable apparaît entre deux livraisons, d'où l'exigence d'un SBOM à chaque livraison. Sans signature ni attestation de provenance, rien ne distingue le livrable authentique d'un artefact substitué en transit. Et télécharger sans vérifier l'intégrité à la réception, c'est faire confiance au canal de distribution, qui peut être compromis : le contrôle de signature ou de checksum est la dernière barrière côté consommateur quand l'amont a été piégé.
Concrètement, ces exigences parent : le livrable substitué en transit, l'artefact non signé indistinguable d'un faux, le SBOM périmé qui masque une dépendance vulnérable, et l'altération non détectée faute de vérification. Trois exigences, des fondamentales (R1) aux renforcées (R2).
Sans vérification à la réception, un livrable trojanisé entre dans votre chaîne.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Exigences
Section intitulée « Exigences »SBOM fourni à chaque livraison (CycloneDX ou SPDX).#
Un SBOM obtenu une seule fois vieillit à chaque nouvelle version : la dépendance vulnérable apparaît entre deux livraisons. Exiger un SBOM à chaque livraison (CycloneDX ou SPDX) maintient l'inventaire à jour, condition pour répondre en heures, pas en jours, à la prochaine Log4Shell.
- Preuve attendue
- SBOM reçu pour chaque livraison du fournisseur.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 5 standards · 2 menaces
La charge malveillante n'est pas dans la dépendance directe mais dans une dépendance de dépendance, invisible sans analyse du graphe complet. La profondeur de l'arbre de dépendances masque l'origine du risque SLSA (dépendances). Le canal par lequel le logiciel est distribué (site de téléchargement, CDN, miroir, mise à jour) est compromis pour livrer une version trojanisée aux utilisateurs finaux. La compromission frappe en aval de la production, au plus près des victimes SLSA (G).
artefacts signés et attestations de provenance (niveau SLSA déclaré et vérifiable).#
Sans signature ni attestation de provenance, rien ne distingue le livrable authentique d'un artefact substitué en route. Vérifier la signature et un niveau SLSA déclaré (in-toto, Sigstore) à la réception garantit que ce que vous déployez vient bien du fournisseur et n'a pas été altéré dans le transit.
- Preuve attendue
- Signatures et attestations de provenance vérifiées à la réception.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 4 standards · 2 menaces
L'attestation de provenance est forgée ou altérée pour faire croire qu'un artefact provient d'un build légitime. Sans provenance non falsifiable (build isolé, signature), la traçabilité est trompeuse SLSA (verification). Un installeur officiel et signé est modifié à la source ou au build pour embarquer une charge, distribué via le canal légitime (cas CCleaner, 3CX). La signature valide endort la méfiance CNCF Trust & Signing.
intégrité vérifiable à la réception (signature, checksum, registre de confiance).#
Télécharger un livrable sans vérifier son intégrité, c'est faire confiance au canal de distribution, qui peut être compromis. Contrôler signature, checksum ou registre de confiance à la réception détecte une altération avant le déploiement : dernière barrière côté consommateur quand l'amont a été piégé (CICD-SEC-9).
- Preuve attendue
- Procédure de vérification d'intégrité des livrables fournisseur.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 3 standards · 1 menace
Le canal par lequel le logiciel est distribué (site de téléchargement, CDN, miroir, mise à jour) est compromis pour livrer une version trojanisée aux utilisateurs finaux. La compromission frappe en aval de la production, au plus près des victimes SLSA (G).