Au moment de la release, un build devient un livrable que d'autres vont consommer : sans preuve, rien ne distingue un artefact légitime d'un artefact falsifié. C'est exactement ce qui a rendu SolarWinds indétectable. Le domaine Release & provenance (REL) garantit l'authenticité et la provenance vérifiable des livrables.
Entre le build et la consommation, l'artefact transite par une publication et un registre où trois menaces se concentrent : l'altération à la publication (on remplace l'artefact en gardant la provenance d'origine), le vol de la clé de signature, et l'account takeover du compte de publication. La parade ne consiste pas à faire confiance au registre, mais à prouver : chaque artefact porte une signature et une provenance (qui atteste comment il a été produit) que le consommateur vérifie avant usage. Concrètement, un cycle outillé établit la confiance : générer la provenance et signer, publier via une identité courte (OIDC, trusted publishing) plutôt qu'un secret de longue durée, puis vérifier côté consommateur, le tout tracé dans un journal de transparence (Rekor). C'est le socle du framework SLSA.
Concrètement, ces exigences parent : l'artefact substitué en chemin (cas SolarWinds), la clé de signature volée, le compte de publication détourné, l'absence de vérification côté consommateur, et la menace post-quantique sur les signatures à longue conservation. Cette page couvre les 20 exigences SOCLE du domaine, des fondamentales (R1) aux souveraines (R3).
La provenance et la signature rendent un livrable authentique et vérifiable.
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 »Sept exigences forment la base : signer les artefacts, attacher une provenance vérifiable, vérifier l'intégrité avant publication, gérer les clés, publier via trusted publishing, et anticiper la crypto-agilité.
signature des artefacts publiés.#
Un artefact non signé ne se distingue pas d'un faux substitué en chemin (cas SolarWinds). Signer les artefacts publiés crée une preuve d'origine vérifiable : le consommateur confirme qu'ils viennent bien de vous et n'ont pas été altérés, première brique de confiance de toute distribution.
- Preuve attendue
- Signature des artefacts publiés.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 8 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).
provenance générée et attachée (in-toto), vérifiable par les consommateurs.#
Une signature dit qui a publié, pas comment l'artefact a été produit. Générer et attacher une provenance (in-toto), vérifiable par les consommateurs, décrit le builder, la source et les paramètres : on vérifie que l'artefact provient bien de la chaîne attendue, pas seulement d'un signataire connu.
- Preuve attendue
- Provenance in-toto générée et attachée, vérifiable par les consommateurs.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 6 standards · 1 menace
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).
vérification d'intégrité avant promotion / publication.#
Promouvoir un artefact sans vérifier son intégrité, c'est faire confiance à l'étape précédente sans contrôle. Vérifier signature et intégrité avant promotion/publication arrête un artefact altéré entre deux étapes, fermant la fenêtre d'injection au moment du passage d'un environnement à un autre.
- Preuve attendue
- Procédure de vérification d'intégrité avant promotion/publication.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 6 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). 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).
provenance non falsifiable (build isolé L3) pour les artefacts sensibles.#
Une provenance produite dans un build non isolé peut être falsifiée par l'attaquant qui contrôle l'environnement. Un build isolé (SLSA L3) rend la provenance non falsifiable : l'attestation ne peut être forgée, garantissant pour les artefacts sensibles une preuve d'origine à laquelle on peut réellement se fier.
- Preuve attendue
- Preuve de build isolé L3 et de provenance non falsifiable pour les artefacts sensibles.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 6 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.
gestion des clés de signature (rotation, HSM/KMS).#
Une clé de signature mal gérée (en clair, jamais tournée), compromise, permet de signer du faux comme du vrai, ruinant toute la confiance. La gérer dans un HSM/KMS avec rotation protège le secret le plus critique de la chaîne : sans accès à la clé, un attaquant ne peut usurper vos signatures.
- Preuve attendue
- Procédure de gestion des clés de signature (rotation, HSM/KMS).
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 7 standards · 1 menace
La clé privée de signature des artefacts est volée (stockage en clair, longue durée, hors HSM), permettant de signer des livrables malveillants présentés comme authentiques. La signature, censée prouver l'authenticité, est retournée contre les consommateurs CNCF Trust & Signing.
publication via trusted publishing (identité OIDC courte) plutôt que jetons de registre longue durée ; compte de publication protégé (2FA, contrôle des changements de propriété/email).#
Un jeton de registre de longue durée fuité permet de publier en votre nom (cas de paquets npm/PyPI détournés). Le trusted publishing par identité OIDC courte, et un compte de publication protégé (2FA, contrôle des changements de propriété), supprime le secret durable et l'angle de prise de contrôle du compte.
- Preuve attendue
- Configuration de trusted publishing (OIDC) ; protection du compte de publication (2FA, contrôle propriété/email).
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 8 standards · 6 menaces
Le jeton de publication (PAT) d'un éditeur d'extension fuite, permettant de pousser une mise à jour piégée diffusée automatiquement à toute la base installée. Une seule fuite de jeton compromet des milliers de postes via le canal de mise à jour de confiance CNCF Dev Tooling CNCF Publishing. Pendant un job, l'attaquant lit en mémoire le jeton OIDC court ou les identifiants fédérés pour s'authentifier auprès de services en aval. L'éphémérité du jeton ne protège pas si le job lui-même est compromis CICD-SEC-6. Le compte d'un éditeur sur un registre (npm, PyPI, conteneurs) est pris (phishing, réutilisation de mot de passe, absence de MFA), permettant de publier des versions malveillantes sous une identité de confiance. C'est le vecteur le plus fréquent des compromissions de paquets CNCF Publishing. Un jeton de publication de longue durée fuite (CI, poste, dépôt) et sert à pousser des versions piégées sans interaction avec le compte. La durée de vie excessive du jeton élargit la fenêtre d'abus CICD-SEC-6. Un paquet compromis vole les jetons de publication des mainteneurs qui l'installent et republie automatiquement d'autres paquets, se propageant de proche en proche (cas Shai-Hulud). L'auto-propagation transforme une compromission isolée en épidémie CNCF Attack Chaining. Un jeton d'accès de longue durée est volé et réutilisé tant qu'il n'est pas révoqué, sans nouvelle authentification. La durée de vie sans rotation maximise la valeur du vol CICD-SEC-6.
crypto-agilité : inventaire des algorithmes cryptographiques (CBOM), capacité de substitution/rotation des algorithmes, et trajectoire de migration post-quantique planifiée (horizon ANSSI/UE 2030).#
Les algorithmes cryptographiques vieillissent, et l'arrivée du quantique menace les signatures actuelles. La crypto-agilité (inventaire CBOM, capacité de substitution) et une trajectoire de migration post-quantique (horizon 2030) garantissent qu'on pourra changer d'algorithme sans tout casser, avant qu'une primitive obsolète ne devienne exploitable.
- Preuve attendue
- Inventaire cryptographique (CBOM) ; plan de crypto-agilité et de migration post-quantique daté.
- Outillage
- cosign slsa-verifier
Correspondances & menaces parées 7 standards · 1 menace
La clé privée de signature des artefacts est volée (stockage en clair, longue durée, hors HSM), permettant de signer des livrables malveillants présentés comme authentiques. La signature, censée prouver l'authenticité, est retournée contre les consommateurs CNCF Trust & Signing.
Signer et gérer les clés
Section intitulée « Signer et gérer les clés »Signer, c'est lier l'artefact à une identité. Deux écoles : les clés gérées en KMS/HSM (jamais en clair, avec rotation testée) et la signature keyless (identité éphémère via Fulcio), qui supprime la clé de longue durée à protéger. Sur le sensible longue conservation, la signature post-quantique (ML-DSA, SLH-DSA) anticipe l'échéance cryptographique.
clés de signature gérées dans un KMS/HSM ; aucune clé privée en clair.#
Une clé privée en clair (fichier, variable, dépôt) est volable et exploitable indéfiniment. La conserver dans un KMS/HSM, sans jamais l'exposer en clair, garantit que les signatures se font sans extraire la clé : même un accès au système ne livre pas le secret qui permettrait d'usurper vos artefacts.
- Preuve attendue
- Clés de signature en KMS/HSM ; absence de clé privée en clair.
- Outillage
- cosign
Correspondances & menaces parées 2 standards · 1 menace
La clé privée de signature des artefacts est volée (stockage en clair, longue durée, hors HSM), permettant de signer des livrables malveillants présentés comme authentiques. La signature, censée prouver l'authenticité, est retournée contre les consommateurs CNCF Trust & Signing.
rotation et révocation des clés de signature documentées et testées.#
Une clé qu'on ne sait pas tourner ni révoquer devient un point de défaillance le jour où elle est compromise. Documenter et tester rotation et révocation garantit qu'on peut neutraliser une clé fuitée et basculer sans interrompre la chaîne, plutôt que de découvrir l'impossibilité de réagir en pleine compromission.
- Preuve attendue
- Procédure de rotation/révocation des clés, testée.
- Outillage
- cosign
Correspondances & menaces parées 2 standards · 1 menace
La clé privée de signature des artefacts est volée (stockage en clair, longue durée, hors HSM), permettant de signer des livrables malveillants présentés comme authentiques. La signature, censée prouver l'authenticité, est retournée contre les consommateurs CNCF Trust & Signing.
signature sans clé de longue durée (identité éphémère, ex. keyless/Fulcio).#
Toute clé durable est un secret à protéger, faire fuir et faire tourner. La signature keyless (identité éphémère, ex. Fulcio) supprime ce fardeau : la clé n'existe que le temps de signer, liée à une identité vérifiée, éliminant le secret de longue durée qu'un attaquant pourrait dérober.
- Preuve attendue
- Configuration de signature keyless (identité éphémère).
- Outillage
- cosign
Correspondances & menaces parées 2 standards · 1 menace
La clé privée de signature des artefacts est volée (stockage en clair, longue durée, hors HSM), permettant de signer des livrables malveillants présentés comme authentiques. La signature, censée prouver l'authenticité, est retournée contre les consommateurs CNCF Trust & Signing.
signature post-quantique ou hybride (ML-DSA / SLH-DSA, NIST FIPS 204/205) pour les artefacts sensibles à longue durée de conservation.#
Un artefact à longue durée de conservation signé aujourd'hui avec un algorithme classique sera vérifiable par un attaquant quantique demain. La signature post-quantique ou hybride (ML-DSA/SLH-DSA, NIST FIPS 204/205) protège dès maintenant ces artefacts dont la confiance doit survivre des années.
- Preuve attendue
- Signature post-quantique/hybride en place sur les artefacts sensibles longue conservation ; agilité des algorithmes.
- Outillage
- cosign
Correspondances & menaces parées 4 standards · 1 menace
La clé privée de signature des artefacts est volée (stockage en clair, longue durée, hors HSM), permettant de signer des livrables malveillants présentés comme authentiques. La signature, censée prouver l'authenticité, est retournée contre les consommateurs CNCF Trust & Signing.
Générer une provenance vérifiable
Section intitulée « Générer une provenance vérifiable »La provenance répond à « qui a construit quoi, depuis quelle source, avec quels paramètres ». Au format in-toto, elle est non répudiable et vérifiable par le consommateur. On y attache des attestations complémentaires (SBOM, tests, scan). Au niveau souverain, l'attestation matérielle d'un environnement d'exécution de confiance (TEE) ancre la provenance dans le matériel.
la provenance décrit builder, source et paramètres de build (non répudiable).#
Une provenance vague ne permet pas de distinguer un build légitime d'un build pirate. Décrire builder, source et paramètres de façon non répudiable donne une attestation précise : on vérifie que l'artefact a été produit par la bonne chaîne, à partir de la bonne source, avec les bons paramètres, pas ailleurs.
- Preuve attendue
- Provenance décrivant builder, source et paramètres de build.
- Outillage
- slsa-verifier in-toto Witness
Correspondances & menaces parées 3 standards · 1 menace
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).
attestations complémentaires (SBOM, tests, scan) liées à l'artefact.#
Une signature seule ne dit rien des tests, scans ou SBOM de l'artefact. Lier des attestations complémentaires (SBOM, tests, scan) à l'artefact enrichit la preuve : le consommateur vérifie non seulement l'origine, mais aussi que les contrôles attendus ont été effectués sur l'artefact exact qu'il reçoit.
- Preuve attendue
- Attestations complémentaires (SBOM, tests, scan) liées à l'artefact.
- Outillage
- slsa-verifier in-toto Witness
Correspondances & menaces parées 3 standards · 1 menace
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).
provenance ancrée matériellement : attestation à distance d'un environnement d'exécution de confiance (TEE - AMD SEV-SNP, Intel TDX, AWS Nitro) pour le builder, couplée à des builds reproductibles pour la vérification sémantique.#
Une provenance logicielle peut être falsifiée si l'environnement de build est compromis. L'ancrer matériellement via l'attestation à distance d'un TEE (AMD SEV-SNP, Intel TDX, AWS Nitro), couplée à des builds reproductibles, fournit une preuve d'origine de très haut niveau : le matériel atteste l'intégrité de l'environnement de production.
- Preuve attendue
- Attestation TEE du builder (SEV-SNP/TDX/Nitro) ; builds reproductibles vérifiés.
- Outillage
- slsa-verifier in-toto Witness
Correspondances & menaces parées 3 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). Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E).
Publier en confiance
Section intitulée « Publier en confiance »La publication est une cible privilégiée : un jeton de registre longue durée volé suffit à publier une version malveillante. Le trusted publishing (identité OIDC courte) supprime ce secret persistant. Le compte de publication est protégé (2FA, contrôle des changements d'email/propriété) et le registre applique immutabilité et rétention.
compte de publication protégé : MFA résistante au phishing (WebAuthn/FIDO2), contrôle des changements de propriété/email ; publication via OIDC / trusted publishing à jetons éphémères privilégiée.#
Le compte de publication est la cible directe pour diffuser du code malveillant sous votre nom. Le protéger par MFA résistante au phishing (WebAuthn/FIDO2), contrôler les changements de propriété/email et privilégier l'OIDC à jetons éphémères ferme les voies de prise de contrôle exploitées dans les détournements de paquets.
- Preuve attendue
- Protection du compte de publication (2FA, contrôle propriété/email).
- Outillage
- OpenSSF Trusted Publishers
Correspondances & menaces parées 3 standards · 2 menaces
Le jeton de publication (PAT) d'un éditeur d'extension fuite, permettant de pousser une mise à jour piégée diffusée automatiquement à toute la base installée. Une seule fuite de jeton compromet des milliers de postes via le canal de mise à jour de confiance CNCF Dev Tooling CNCF Publishing. Le compte d'un éditeur sur un registre (npm, PyPI, conteneurs) est pris (phishing, réutilisation de mot de passe, absence de MFA), permettant de publier des versions malveillantes sous une identité de confiance. C'est le vecteur le plus fréquent des compromissions de paquets CNCF Publishing.
artefacts publiés dans un registre contrôlé, avec rétention et immutabilité.#
Des releases publiées dans un registre non maîtrisé peuvent être réécrites ou supprimées. Un registre contrôlé avec rétention et immutabilité garantit qu'une version publiée reste inchangée et disponible : un consommateur retrouve exactement l'artefact attendu, et un tag ne désigne jamais un contenu différent du jour au lendemain.
- Preuve attendue
- Registre contrôlé avec rétention et immutabilité.
- Outillage
- OpenSSF Trusted Publishers
Correspondances & menaces parées 1 standard · 2 menaces
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. 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.
versionnement et étiquetage immuables des releases.#
Un tag mutable réécrit fait pointer une même version vers un contenu différent : la reproductibilité s'effondre et une substitution passe inaperçue. Un versionnement et étiquetage immuables garantissent qu'une release identifiée correspond pour toujours au même artefact, base de la confiance des consommateurs.
- Preuve attendue
- Versionnement et étiquetage immuables des releases.
- Outillage
- OpenSSF Trusted Publishers
Correspondances & menaces parées 2 standards · 1 menace
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.
Vérifier et tracer
Section intitulée « Vérifier et tracer »Signer et attester ne sert à rien si personne ne vérifie. Le consommateur contrôle signature et provenance avant usage, idéalement avec un journal de transparence (ex. Rekor) qui rend les signatures publiquement traçables et inaltérables. Sur la chaîne sensible, un registre de transparence de bout en bout complète le dispositif.
vérification de signature et de provenance par les consommateurs avant usage.#
Signer et attester ne sert à rien si personne ne vérifie côté réception. Imposer la vérification de signature et de provenance avant usage par les consommateurs ferme la boucle : un artefact non conforme est rejeté à l'entrée, transformant la preuve produite en amont en contrôle effectif au moment de consommer.
- Preuve attendue
- Vérification de signature et de provenance par les consommateurs.
- Outillage
- cosign slsa-verifier Rekor
Correspondances & menaces parées 2 standards · 1 menace
Le consommateur n'utilise ni la signature ni la provenance avant de consommer un artefact, annulant tout le bénéfice de leur génération. La chaîne de confiance ne tient que si le dernier maillon vérifie SLSA (verification).
journal de transparence des signatures/attestations (ex. Rekor).#
Une signature peut être émise discrètement sans laisser de trace publique. Un journal de transparence (ex. Rekor) enregistre signatures et attestations de façon inaltérable et auditable : une signature frauduleuse y devient visible, et l'on peut prouver a posteriori ce qui a été signé, par qui et quand.
- Preuve attendue
- Journal de transparence des signatures/attestations (ex. Rekor).
- Outillage
- cosign slsa-verifier Rekor
Correspondances & menaces parées 2 standards · 2 menaces
Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E). Le consommateur n'utilise ni la signature ni la provenance avant de consommer un artefact, annulant tout le bénéfice de leur génération. La chaîne de confiance ne tient que si le dernier maillon vérifie SLSA (verification).
registre de transparence de bout en bout pour la chaîne sensible.#
Pour une chaîne sensible, des preuves dispersées ne se vérifient pas globalement. Un registre de transparence de bout en bout relie et rend auditable l'ensemble de la chaîne de signatures et d'attestations : on vérifie l'intégrité du parcours complet de l'artefact, pas seulement de maillons isolés.
- Preuve attendue
- Registre de transparence de bout en bout pour la chaîne sensible.
- Outillage
- cosign slsa-verifier Rekor
Correspondances & menaces parées 2 standards · 1 menace
Le build est compromis en amont, si bien que la provenance est techniquement valide mais atteste d'un artefact malveillant. La provenance prouve l'origine, pas l'innocuité : un build corrompu produit une attestation correcte d'un mauvais résultat SLSA (D) SLSA (E).
Pièges courants
Section intitulée « Pièges courants »- Signer sans faire vérifier : sans contrôle côté consommateur (REL-P4-2), la signature ne bloque rien.
- Jetons de publication longue durée : un
NPM_TOKENvolé republie à votre place ; préférez le trusted publishing (REL-0-6). - Provenance présente mais non vérifiée contre la source/builder attendus : une provenance authentique sur un artefact piégé passe (voir admission, DPL).
- Clé privée dans le CI : à proscrire ; KMS/HSM ou keyless (REL-P1-2/P1-4).
- Tags mutables : une release doit être immuable (REL-P3-4).
À retenir
Section intitulée « À retenir »- La release produit un livrable de confiance : signature + provenance vérifiables, sinon le consommateur est aveugle.
- Les essentielles : signer, attacher une provenance in-toto, vérifier l'intégrité, trusted publishing.
- Keyless et KMS/HSM suppriment ou protègent la clé ; la crypto-agilité prépare l'après-quantique.
- La vérification consommateur et la transparence (Rekor) ferment la boucle.
- Le niveau R3 ajoute build isolé L3, attestation TEE et transparence de bout en bout.