Un artefact publié est consommé par des centaines d'utilisateurs : s'il est une boîte noire, personne ne peut répondre à « suis-je affecté par cette CVE ? ». Le domaine Packaging & artefacts (PKG) garantit la transparence et l'intégrité de ce qu'on livre.
L'artefact est le produit livré. Sans SBOM, impossible de savoir quels composants il embarque le jour où une Log4Shell surgit. Une image obèse multiplie la surface d'attaque ; un secret oublié dans une couche fuite vers tous les consommateurs ; une image de base empoisonnée (cas xz-utils) contamine les dérivés. Le packaging suit donc un chemin contrôlé : produire l'artefact avec son SBOM (CycloneDX ou SPDX), le durcir (image minimale, non-root, sans secret), l'analyser (scan de vulnérabilités, de malware et de secrets, bloquant) puis le publier dans un registre immuable, signé et à provenance attachée.
Concrètement, ces exigences parent : l'exposition inconnue à un CVE sans SBOM, la vulnérabilité publiée faute de scan, le secret embarqué dans une image, la charge malveillante non détectée, et le tag réécrit qui substitue un artefact. Cette page couvre les 17 exigences SOCLE du domaine, des fondamentales (R1) aux souveraines (R3).
Un artefact altéré ou fuitant des secrets se propage à tous ses consommateurs.
Les pièges à éviter
Section intitulée « Les pièges à éviter »Les erreurs les plus fréquentes sur ce périmètre :
Les exigences essentielles
Section intitulée « Les exigences essentielles »Quatre exigences forment la base : un SBOM par artefact, un scan avant publication, des images minimales durcies sans secret, et un registre contrôlé et immuable.
SBOM généré pour chaque artefact (CycloneDX ou SPDX).#
Sans SBOM, vous ignorez ce que contient l'artefact livré : une faille comme Log4Shell vous laisse incapable de dire « suis-je concerné ? ». Générer un SBOM par artefact (CycloneDX ou SPDX) crée l'inventaire interrogeable qui permet de répondre en minutes le jour où un CVE touche un composant.
- Preuve attendue
- SBOM (CycloneDX/SPDX) généré par artefact.
- Outillage
- Trivy Syft
Correspondances & menaces parées 6 standards · 1 menace
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).
scan de vulnérabilités des images/artefacts avant publication.#
Publier un artefact sans le scanner, c'est diffuser des vulnérabilités connues à tous ses consommateurs. Scanner images et artefacts avant publication attrape ces failles au dernier moment maîtrisable, avant qu'elles ne se propagent en aval où chaque utilisateur hérite du problème.
- Preuve attendue
- Rapport de scan de vulnérabilités des images/artefacts avant publication.
- Outillage
- Trivy Syft
Correspondances & menaces parées 4 standards · 1 menace
L'artefact est modifié après sa construction mais avant sa publication ou son déploiement, échappant aux contrôles appliqués au code source. Sans intégrité de bout en bout, l'artefact livré diffère de celui qui a été buildé SLSA (F).
images de base minimales et durcies ; aucun secret dans les artefacts.#
Chaque binaire superflu dans une image est une surface d'attaque de plus ; un secret embarqué fuit avec elle. Des images minimales et durcies, sans secret, réduisent ce qu'un attaquant peut exploiter une fois dans le conteneur et suppriment la fuite triviale du secret laissé en couche.
- Preuve attendue
- Images minimales et durcies ; inspection d'absence de secrets dans les artefacts.
- Outillage
- Trivy Syft
Correspondances & menaces parées 4 standards · 1 menace
Un secret (clé, jeton, mot de passe) est inclus par erreur dans l'image ou le paquet publié, exposé à tous ses consommateurs. La fuite se propage à chaque téléchargement de l'artefact CICD-SEC-6.
artefacts stockés dans un registre contrôlé, avec rétention et immutabilité.#
Un artefact stocké n'importe où, sans contrôle, peut être remplacé ou supprimé à l'insu de tous. Un registre contrôlé avec rétention et immutabilité garantit que l'artefact publié reste exactement celui qu'on a produit : un tag ne peut être réécrit, une version reste disponible et inchangée.
- Preuve attendue
- Configuration du registre : rétention et immutabilité.
- Outillage
- Trivy Syft
Correspondances & menaces parées 3 standards · 2 menaces
L'artefact est modifié après sa construction mais avant sa publication ou son déploiement, échappant aux contrôles appliqués au code source. Sans intégrité de bout en bout, l'artefact livré diffère de celui qui a été buildé SLSA (F). Un tag mutable (latest, une version) est réécrit pour pointer vers un artefact malveillant, livré aux consommateurs qui font confiance au tag plutôt qu'au digest. La mutabilité brise l'immuabilité attendue d'une version publiée CNCF Publishing.
SBOM et transparence des composants
Section intitulée « SBOM et transparence des composants »Le SBOM (Software Bill of Materials) liste les composants directs et transitifs, leurs licences et empreintes, au format normalisé CycloneDX ou SPDX. Il doit être généré au build (pas reconstitué a posteriori), attaché à l'artefact et conservé pour que les consommateurs le récupèrent.
SBOM complet par artefact (composants directs et transitifs, licences, empreintes) au format normalisé (CycloneDX ou SPDX).#
Un SBOM incomplet (transitifs manquants) donne une fausse assurance : la faille se cache dans ce qu'il n'a pas listé. Un SBOM complet (directs et transitifs, licences, empreintes) au format normalisé garantit une nomenclature exploitable et fiable, base de tout suivi de vulnérabilités et de licences sérieux.
- Preuve attendue
- SBOM complet par artefact (composants, licences, hashes) au format CycloneDX/SPDX.
- Outillage
- Syft cdxgen
Correspondances & menaces parées 4 standards · 1 menace
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).
SBOM attaché à l'artefact et conservé (versionné, récupérable par les consommateurs).#
Un SBOM détaché ou jeté est introuvable le jour de l'incident. L'attacher à l'artefact et le conserver (versionné, récupérable par les consommateurs) garantit qu'il reste disponible des mois plus tard, pour retrouver en minutes quels artefacts embarquent un composant compromis.
- Preuve attendue
- SBOM attaché et conservé, récupérable par les consommateurs.
- Outillage
- Syft cdxgen
Correspondances & menaces parées 2 standards · 1 menace
complétude du SBOM vérifiée (pas de composant fantôme) ; SBOM généré au build, pas a posteriori.#
Un SBOM produit a posteriori rate des composants et ne reflète pas le build réel. Le générer au build et vérifier sa complétude (pas de composant fantôme) garantit qu'il décrit exactement ce qui a été assemblé, condition pour qu'il soit une preuve fiable plutôt qu'une approximation rassurante.
- Preuve attendue
- Vérification de complétude du SBOM (généré au build).
- Outillage
- Syft cdxgen
Correspondances & menaces parées 2 standards · 1 menace
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).
Durcir les images et artefacts
Section intitulée « Durcir les images et artefacts »Une image se réduit au strict nécessaire : base minimale (distroless), exécution non-root, pas de shell ni d'outillage superflu, et surtout aucun secret dans les build args, layers ou variables d'environnement. Les builds reproductibles rendent l'artefact vérifiable.
images minimales (distroless / base réduite) ; surface d'attaque réduite au nécessaire.#
Une image pléthorique embarque shells, gestionnaires de paquets et outils que l'attaquant détournera. Des images minimales (distroless, base réduite) retirent ces moyens : moins de binaires, moins de CVE, moins d'outils pour pivoter une fois à l'intérieur, réduisant la surface au strict nécessaire de fonctionnement.
- Preuve attendue
- Image minimale (distroless / base réduite).
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 standards · 2 menaces
Un job exploite une mauvaise configuration ou une faille du runtime de conteneurs pour s'échapper vers l'hôte du runner et atteindre d'autres charges. Le cloisonnement supposé entre jobs est rompu CICD-SEC-7 CIS Benchmarks. L'image de base utilisée pour construire les conteneurs contient une charge malveillante ou une vulnérabilité, héritée par tous les artefacts qui en dérivent. Le socle d'exécution contamine toute la production CNCF SLSA.
conteneur tournant sous utilisateur non-root ; pas de shell ni d'outillage superflu en production.#
Un conteneur tournant en root facilite l'évasion vers l'hôte ; un shell en production offre un outil prêt à l'emploi à l'attaquant. Exécuter en non-root et retirer shell et outillage superflu privent une charge compromise des moyens d'escalader ou d'explorer le système.
- Preuve attendue
- Conteneur en non-root ; pas d'outillage superflu.
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 standards · 1 menace
Un job exploite une mauvaise configuration ou une faille du runtime de conteneurs pour s'échapper vers l'hôte du runner et atteindre d'autres charges. Le cloisonnement supposé entre jobs est rompu CICD-SEC-7 CIS Benchmarks.
aucun secret embarqué dans l'artefact ou l'image (build args, layers, variables d'environnement).#
Un secret glissé dans un build arg, une couche ou une variable d'environnement d'image est récupérable par quiconque tire l'image. Bannir tout secret de l'artefact supprime cette fuite, parmi les plus courantes : une image partagée ne doit jamais transporter de quoi s'authentifier ailleurs.
- Preuve attendue
- Inspection : aucun secret embarqué dans l'artefact/l'image.
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 standards · 1 menace
Un secret (clé, jeton, mot de passe) est inclus par erreur dans l'image ou le paquet publié, exposé à tous ses consommateurs. La fuite se propage à chaque téléchargement de l'artefact CICD-SEC-6.
builds d'images reproductibles ; layers déterministes.#
Si reconstruire une image donne un résultat différent, impossible de prouver qu'elle correspond à ses sources. Des builds reproductibles (layers déterministes) permettent à un tiers de reconstruire à l'identique et de détecter toute divergence, donc toute injection survenue pendant la construction de l'image.
- Preuve attendue
- Attestation de build d'image reproductible.
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 standards · 1 menace
Analyser avant publication
Section intitulée « Analyser avant publication »Avant de publier, un gate bloquant arrête les artefacts à risque : scan de vulnérabilités (bloquant sur criticités hautes), scan de malware et de secrets (pas seulement les CVE) et conformité des licences.
scan de vulnérabilités des artefacts/images avant publication ; gate bloquant sur criticités hautes.#
Un scan qui ne bloque jamais se réduit à un rapport ignoré. Scanner les artefacts avant publication avec un gate bloquant sur les criticités hautes empêche de publier un artefact gravement vulnérable : la correction devient une condition de sortie, pas une suggestion qu'on remet à plus tard.
- Preuve attendue
- Rapport de scan de vulnérabilités avant publication ; gate bloquant.
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 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). L'image de base utilisée pour construire les conteneurs contient une charge malveillante ou une vulnérabilité, héritée par tous les artefacts qui en dérivent. Le socle d'exécution contamine toute la production CNCF SLSA.
scan de malware et de secrets de l'artefact (pas seulement CVE) avant publication.#
Un scan CVE ne détecte ni une charge malveillante ajoutée ni un secret oublié. Scanner le malware et les secrets de l'artefact avant publication, pas seulement les vulnérabilités connues, attrape ce qu'un attaquant glisse délibérément et ce qu'un développeur a laissé fuiter par accident.
- Preuve attendue
- Scan malware/secrets de l'artefact avant publication.
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 standards · 1 menace
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.
conformité des licences vérifiée (politique de licences) avant publication.#
Une licence incompatible dans une dépendance peut créer une obligation juridique inattendue (copyleft) sur le produit livré. Vérifier la conformité des licences avant publication selon une politique évite cette dette légale, repérée pendant qu'on peut encore remplacer le composant, pas après distribution à des clients.
- Preuve attendue
- Vérification de conformité des licences avant publication.
- Outillage
- Trivy Grype
Correspondances & menaces parées 2 standards · 1 menace
Le mainteneur saborde délibérément son propre composant pour des raisons idéologiques ou politiques (protestware) : code destructeur, messages, ou comportements ciblant certains utilisateurs. La confiance accordée au paquet se retourne contre ses consommateurs lors d'une simple mise à jour (cas node-ipc) CNCF Malicious Maintainer SoK.
Registre et intégrité
Section intitulée « Registre et intégrité »L'artefact est stocké dans un registre contrôlé : immutabilité des tags (jamais réécrits), RBAC au moindre privilège (push réservé à la chaîne de build), et signature avec provenance attachée à la publication, en cohérence avec le domaine Release.
artefacts stockés dans un registre contrôlé, avec immutabilité (tags non réécrits) et rétention.#
Un tag réécrit dans le registre fait pointer la même référence vers un artefact différent, potentiellement piégé. Un registre contrôlé avec immutabilité (tags non réécrits) et rétention garantit que ce qu'on a publié reste inchangé et disponible : la référence d'hier désigne toujours le même contenu.
- Preuve attendue
- Registre contrôlé : immutabilité des tags et rétention.
- Outillage
- Harbor
Correspondances & menaces parées 1 standard · 2 menaces
L'artefact est modifié après sa construction mais avant sa publication ou son déploiement, échappant aux contrôles appliqués au code source. Sans intégrité de bout en bout, l'artefact livré diffère de celui qui a été buildé SLSA (F). Un tag mutable (latest, une version) est réécrit pour pointer vers un artefact malveillant, livré aux consommateurs qui font confiance au tag plutôt qu'au digest. La mutabilité brise l'immuabilité attendue d'une version publiée CNCF Publishing.
accès au registre au moindre privilège (RBAC) ; push restreint à la chaîne de build.#
Un droit de push trop largement distribué laisse n'importe quel compte compromis empoisonner le registre. Un RBAC au moindre privilège réservant le push à la chaîne de build garantit que seuls les artefacts produits par le pipeline officiel y entrent, fermant la porte à l'injection directe d'artefacts hostiles.
- Preuve attendue
- RBAC du registre ; push restreint à la chaîne de build.
- Outillage
- Harbor
Correspondances & menaces parées 2 standards · 1 menace
Le registre de paquets ou un miroir est compromis, permettant d'altérer ou de substituer des artefacts pour tous ses utilisateurs. L'infrastructure de distribution devient le point de défaillance unique CNCF Publishing.
signature de l'artefact à la publication et provenance attachée.#
Un artefact non signé ne se distingue pas d'un faux substitué dans le registre. Signer à la publication et attacher la provenance permettent aux consommateurs de vérifier qu'il vient bien de votre chaîne et n'a pas été altéré, transformant un artefact anonyme en élément vérifiable de confiance.
- Preuve attendue
- Signature de l'artefact à la publication ; provenance attachée.
- Outillage
- Harbor
Correspondances & menaces parées 2 standards · 2 menaces
L'artefact est modifié après sa construction mais avant sa publication ou son déploiement, échappant aux contrôles appliqués au code source. Sans intégrité de bout en bout, l'artefact livré diffère de celui qui a été buildé SLSA (F). 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).
Pièges courants
Section intitulée « Pièges courants »- SBOM reconstitué après coup : il rate les composants réels du build ; générez-le au build (PKG-K1-3).
- Secret dans une layer :
docker historyle révèle ; unARGou unCOPYmalheureux suffit (PKG-K2-3). - Image
latestobèse : shell et paquets inutiles élargissent la surface d'attaque (PKG-K2-1, K2-2). - Scan en mode rapport : sans gate bloquant, les artefacts vulnérables passent quand même (PKG-K3-1).
- Tags réécrits : un tag mutable casse la traçabilité et la vérification d'admission (PKG-K4-1).
À retenir
Section intitulée « À retenir »- Le packaging produit un artefact transparent (SBOM) et intègre.
- Les essentielles : SBOM par artefact, scan avant publication, image durcie sans secret, registre immuable.
- Le SBOM se génère au build, complet, et accompagne l'artefact.
- Les images sont minimales, non-root, sans secret et idéalement reproductibles.
- Le registre applique immutabilité, RBAC et signature à la publication.