{"id":453,"date":"2026-02-28T12:20:01","date_gmt":"2026-02-28T11:20:01","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=453"},"modified":"2026-03-25T08:40:00","modified_gmt":"2026-03-25T07:40:00","slug":"slsa-levels-explained-practical-compliance-checklist","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/slsa-levels-explained-practical-compliance-checklist\/","title":{"rendered":"Les Niveaux SLSA Expliqu\u00e9s : Checklist Pratique de Conformit\u00e9 pour les \u00c9quipes d&rsquo;Ing\u00e9nierie"},"content":{"rendered":"<h2>Introduction : Qu&rsquo;est-ce que SLSA et pourquoi devriez-vous vous en soucier ?<\/h2>\n<p>Supply-chain Levels for Software Artifacts \u2014 <strong>SLSA<\/strong> (prononc\u00e9 \u00ab salsa \u00bb) \u2014 est un framework de s\u00e9curit\u00e9 cr\u00e9\u00e9 par Google et d\u00e9sormais maintenu par l&rsquo;<a href=\"https:\/\/openssf.org\/\" target=\"_blank\" rel=\"noopener\">Open Source Security Foundation (OpenSSF)<\/a>. Son objectif est d&rsquo;une simplicit\u00e9 trompeuse : rendre plus difficile pour les attaquants de falsifier les logiciels que vous construisez et distribuez.<\/p>\n<p>Si vous avez suivi les incidents majeurs tels que <a href=\"https:\/\/en.wikipedia.org\/wiki\/2020_United_States_federal_government_data_breach\" target=\"_blank\" rel=\"noopener\">SolarWinds<\/a>, <a href=\"https:\/\/en.wikipedia.org\/wiki\/Codecov\" target=\"_blank\" rel=\"noopener\">Codecov<\/a> ou le <a href=\"https:\/\/www.sonatype.com\/resources\/vulnerability-timeline\" target=\"_blank\" rel=\"noopener\">flot de paquets npm malveillants<\/a>, vous savez d\u00e9j\u00e0 <em>pourquoi<\/em> la s\u00e9curit\u00e9 de la cha\u00eene d&rsquo;approvisionnement est importante. SLSA vous donne un framework concret et incr\u00e9mental pour savoir <em>comment<\/em> y rem\u00e9dier.<\/p>\n<p>La <strong>sp\u00e9cification SLSA v1.0<\/strong> (publi\u00e9e en avril 2023) a simplifi\u00e9 le mod\u00e8le original en une piste claire \u2014 les <strong>Build Levels 0 \u00e0 3<\/strong> \u2014 chacun ajoutant des garanties plus fortes sur l&rsquo;int\u00e9grit\u00e9 de votre processus de build et les m\u00e9tadonn\u00e9es de provenance qu&rsquo;il produit.<\/p>\n<p>Ce guide passe en revue chaque niveau en langage clair, vous fournit une checklist que vous pouvez remettre \u00e0 votre \u00e9quipe lundi matin, associe chaque exigence \u00e0 des outils concrets, montre \u00e0 quoi ressemble r\u00e9ellement la provenance, et propose une feuille de route d&rsquo;adoption \u00e9tape par \u00e9tape. C&rsquo;est parti.<\/p>\n<hr \/>\n<h2>Aper\u00e7u rapide : le Build Track SLSA en un coup d&rsquo;\u0153il<\/h2>\n<p>Avant de plonger dans chaque niveau, voici un tableau comparatif pour avoir une vue d&rsquo;ensemble.<\/p>\n<table style=\"width:100%; border-collapse:collapse; margin-bottom:2em;\">\n<thead>\n<tr style=\"background:#1a1a2e; color:#fff;\">\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Aspect<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L0<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L1<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L2<\/th>\n<th style=\"padding:10px; border:1px solid #ddd; text-align:left;\">Build L3<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Processus de build<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Aucune exigence<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Build script\u00e9 et coh\u00e9rent<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Service de build h\u00e9berg\u00e9<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Builders renforc\u00e9s et isol\u00e9s<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Provenance<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Non requise<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Existe et disponible<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Authentifi\u00e9e et g\u00e9n\u00e9r\u00e9e par le service<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Infalsifiable, signature isol\u00e9e<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Signataire de la provenance<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">N\/A<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">D\u00e9veloppeur ou CI<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Le service de build lui-m\u00eame<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Service de build renforc\u00e9<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Protection contre la falsification<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Aucune<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Erreurs et documentation<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Falsification apr\u00e8s le build<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Falsification pendant et apr\u00e8s le build<\/td>\n<\/tr>\n<tr>\n<td style=\"padding:10px; border:1px solid #ddd;\"><strong>Effort d&rsquo;adoption<\/strong><\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Z\u00e9ro<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Faible \u2014 heures \u00e0 jours<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">Moyen \u2014 jours \u00e0 semaines<\/td>\n<td style=\"padding:10px; border:1px solid #ddd;\">\u00c9lev\u00e9 \u2014 semaines \u00e0 mois<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<hr \/>\n<h2>Build Level 0 \u2014 Le point de d\u00e9part (aucune garantie)<\/h2>\n<p>Le Build L0 n&rsquo;est pas vraiment un niveau \u2014 c&rsquo;est l&rsquo;absence totale de conformit\u00e9 SLSA. Tout projet logiciel commence ici par d\u00e9faut.<\/p>\n<h3>Ce que cela signifie en langage clair<\/h3>\n<p>Vous n&rsquo;avez aucune exigence formelle. Les builds peuvent \u00eatre r\u00e9alis\u00e9s sur le portable d&rsquo;un d\u00e9veloppeur, sans aucun enregistrement du code source utilis\u00e9, des commandes ex\u00e9cut\u00e9es ou du r\u00e9sultat produit. Il n&rsquo;y a pas de document de provenance. Il n&rsquo;y a rien \u00e0 v\u00e9rifier.<\/p>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 <em>Rien de requis<\/em> \u2014 c&rsquo;est le point de d\u00e9part \u00e0 partir duquel vous progressez.<\/li>\n<\/ul>\n<h3>\u00c0 quoi ressemble la provenance au L0<\/h3>\n<p>Elle n&rsquo;existe pas. Il n&rsquo;y a pas d&rsquo;attestation, pas de m\u00e9tadonn\u00e9es, pas de signature. Si quelqu&rsquo;un demande \u00ab prouvez que ce binaire provient de ce commit \u00bb, la r\u00e9ponse honn\u00eate est : vous ne pouvez pas.<\/p>\n<p><strong>En r\u00e9sum\u00e9 :<\/strong> Le L0 est l\u00e0 o\u00f9 se trouvent la plupart des organisations aujourd&rsquo;hui. La bonne nouvelle ? Passer au L1 est \u00e9tonnamment facile.<\/p>\n<hr \/>\n<h2>Build Level 1 \u2014 La provenance existe<\/h2>\n<p>Le L1 est la premi\u00e8re \u00e9tape significative. Sa promesse centrale : <em>la provenance existe et le processus de build est script\u00e9.<\/em><\/p>\n<h3>Exigences en langage clair<\/h3>\n<ol>\n<li><strong>Build script\u00e9<\/strong> \u2014 Le build est d\u00e9fini dans du code (un Makefile, un Dockerfile, un fichier YAML de pipeline CI), et non une s\u00e9rie de commandes shell manuelles qu&rsquo;un d\u00e9veloppeur ex\u00e9cute de m\u00e9moire.<\/li>\n<li><strong>La provenance est g\u00e9n\u00e9r\u00e9e<\/strong> \u2014 Le build produit un document qui enregistre, au minimum, <em>qui<\/em> l&rsquo;a construit, <em>quel<\/em> code source a \u00e9t\u00e9 utilis\u00e9 et <em>quel<\/em> processus de build a \u00e9t\u00e9 ex\u00e9cut\u00e9.<\/li>\n<li><strong>La provenance est disponible<\/strong> \u2014 Les consommateurs peuvent effectivement t\u00e9l\u00e9charger et inspecter la provenance.<\/li>\n<\/ol>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 Le build est enti\u00e8rement d\u00e9fini dans un script de build ou un fichier de configuration CI (aucune \u00e9tape manuelle).<\/li>\n<li>\u2610 Chaque build produit des m\u00e9tadonn\u00e9es de provenance (format in-toto \/ SLSA provenance recommand\u00e9).<\/li>\n<li>\u2610 La provenance enregistre : la plateforme de build, le d\u00e9p\u00f4t source, le point d&rsquo;entr\u00e9e et les empreintes (digests) de l&rsquo;artefact produit.<\/li>\n<li>\u2610 La provenance est publi\u00e9e aux c\u00f4t\u00e9s de l&rsquo;artefact (par ex. dans un registre, un artefact OCI ou une URL publique).<\/li>\n<li>\u2610 Le format de provenance suit le <a href=\"https:\/\/slsa.dev\/provenance\/v1\" target=\"_blank\" rel=\"noopener\">sch\u00e9ma SLSA Provenance v1<\/a>.<\/li>\n<\/ul>\n<h3>Outils qui satisfont le L1<\/h3>\n<ul>\n<li><strong>GitHub Actions<\/strong> \u2014 Utilisez les workflows r\u00e9utilisables <a href=\"https:\/\/github.com\/slsa-framework\/slsa-github-generator\" target=\"_blank\" rel=\"noopener\">slsa-github-generator<\/a>. Ils g\u00e9n\u00e8rent automatiquement la provenance SLSA.<\/li>\n<li><strong>GitLab CI<\/strong> \u2014 GitLab 15.x+ prend en charge l&rsquo;<a href=\"https:\/\/docs.gitlab.com\/ee\/ci\/runners\/configure_runners.html#artifact-attestation\" target=\"_blank\" rel=\"noopener\">attestation d&rsquo;artefacts<\/a> nativement.<\/li>\n<li><strong>SLSA Verifier<\/strong> \u2014 Le CLI <code>slsa-verifier<\/code> pour valider la provenance c\u00f4t\u00e9 consommateur.<\/li>\n<li><strong>Sigstore \/ Cosign<\/strong> \u2014 Signez et stockez la provenance dans le <a href=\"https:\/\/www.sigstore.dev\/\" target=\"_blank\" rel=\"noopener\">journal de transparence de Sigstore (Rekor)<\/a>.<\/li>\n<li><strong>in-toto<\/strong> \u2014 Le <a href=\"https:\/\/in-toto.io\/\" target=\"_blank\" rel=\"noopener\">framework in-toto<\/a> fournit une sp\u00e9cification et des biblioth\u00e8ques pour g\u00e9n\u00e9rer des attestations.<\/li>\n<\/ul>\n<h3>\u00c0 quoi ressemble la provenance au L1<\/h3>\n<p>Un document de provenance SLSA v1 minimal au L1 pourrait ressembler \u00e0 ceci (JSON simplifi\u00e9) :<\/p>\n<pre><code>{\n  \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n  \"subject\": [{\n    \"name\": \"my-app\",\n    \"digest\": { \"sha256\": \"a1b2c3d4...\" }\n  }],\n  \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n  \"predicate\": {\n    \"buildDefinition\": {\n      \"buildType\": \"https:\/\/github.com\/slsa-framework\/slsa-github-generator\/...\",\n      \"externalParameters\": {\n        \"source\": {\n          \"uri\": \"git+https:\/\/github.com\/acme\/my-app@refs\/heads\/main\",\n          \"digest\": { \"sha1\": \"abc123...\" }\n        }\n      }\n    },\n    \"runDetails\": {\n      \"builder\": {\n        \"id\": \"https:\/\/github.com\/slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_generic_slsa3.yml@refs\/tags\/v1.9.0\"\n      }\n    }\n  }\n}<\/code><\/pre>\n<p><strong>Point cl\u00e9 :<\/strong> Au L1, la provenance peut \u00eatre auto-attest\u00e9e \u2014 c&rsquo;est le d\u00e9veloppeur ou son propre job CI qui la signe. C&rsquo;est acceptable \u00e0 ce niveau ; l&rsquo;objectif est l&rsquo;<em>existence<\/em>.<\/p>\n<hr \/>\n<h2>Build Level 2 \u2014 Provenance h\u00e9berg\u00e9e et authentifi\u00e9e<\/h2>\n<p>Le L2 rel\u00e8ve la barre : le build doit s&rsquo;ex\u00e9cuter sur un <strong>service de build h\u00e9berg\u00e9<\/strong>, et la provenance doit \u00eatre <strong>g\u00e9n\u00e9r\u00e9e et sign\u00e9e par ce service<\/strong> \u2014 et non par le d\u00e9veloppeur.<\/p>\n<h3>Exigences en langage clair<\/h3>\n<ol>\n<li><strong>Plateforme de build h\u00e9berg\u00e9e<\/strong> \u2014 Les builds s&rsquo;ex\u00e9cutent sur un service g\u00e9r\u00e9 (GitHub Actions, GitLab CI, Google Cloud Build, Jenkins sur infrastructure g\u00e9r\u00e9e, etc.), et non sur le portable d&rsquo;un d\u00e9veloppeur.<\/li>\n<li><strong>Provenance authentifi\u00e9e<\/strong> \u2014 Le service de build lui-m\u00eame g\u00e9n\u00e8re et signe la provenance. Un d\u00e9veloppeur ne peut pas la falsifier ou la modifier.<\/li>\n<li><strong>G\u00e9n\u00e9r\u00e9e par le service<\/strong> \u2014 La g\u00e9n\u00e9ration de la provenance est une fonctionnalit\u00e9 de la plateforme de build, et non un script que le d\u00e9veloppeur peut modifier dans son d\u00e9p\u00f4t.<\/li>\n<\/ol>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 Tous les builds de release s&rsquo;ex\u00e9cutent sur un service CI\/CD h\u00e9berg\u00e9 (aucun build local pour les artefacts de production).<\/li>\n<li>\u2610 Le service de build g\u00e9n\u00e8re la provenance \u2014 <em>pas<\/em> un script contr\u00f4l\u00e9 par l&rsquo;utilisateur.<\/li>\n<li>\u2610 La provenance est sign\u00e9e par l&rsquo;identit\u00e9 du service de build (par ex. signature keyless bas\u00e9e sur OIDC via Sigstore).<\/li>\n<li>\u2610 La provenance inclut l&rsquo;identit\u00e9 authentifi\u00e9e du builder (vous pouvez v\u00e9rifier <em>quel<\/em> service l&rsquo;a produite).<\/li>\n<li>\u2610 Les consommateurs peuvent v\u00e9rifier la signature de la provenance par rapport \u00e0 l&rsquo;identit\u00e9 connue du service de build.<\/li>\n<li>\u2610 Le d\u00e9p\u00f4t source et le point d&rsquo;entr\u00e9e dans la provenance sont renseign\u00e9s par le service, et non par des valeurs fournies par l&rsquo;utilisateur.<\/li>\n<\/ul>\n<h3>Outils qui satisfont le L2<\/h3>\n<ul>\n<li><strong>GitHub Actions + slsa-github-generator<\/strong> \u2014 Lorsque vous utilisez le workflow r\u00e9utilisable (et non une action composite), le jeton OIDC de GitHub signe la provenance. Cela satisfait le L2 nativement.<\/li>\n<li><strong>Google Cloud Build<\/strong> \u2014 Produit nativement une <a href=\"https:\/\/cloud.google.com\/build\/docs\/securing-builds\/view-build-provenance\" target=\"_blank\" rel=\"noopener\">provenance authentifi\u00e9e<\/a> pour les images de conteneurs stock\u00e9es dans Artifact Registry.<\/li>\n<li><strong>Sigstore Fulcio + Rekor<\/strong> \u2014 Signature keyless avec des certificats \u00e9ph\u00e9m\u00e8res li\u00e9s \u00e0 l&rsquo;identit\u00e9 OIDC du CI. Le journal de transparence (Rekor) fournit un enregistrement infalsifiable.<\/li>\n<li><strong>Tekton Chains<\/strong> \u2014 Pour le CI natif Kubernetes. <a href=\"https:\/\/tekton.dev\/docs\/chains\/\" target=\"_blank\" rel=\"noopener\">Tekton Chains<\/a> g\u00e9n\u00e8re et signe automatiquement la provenance SLSA pour les ex\u00e9cutions de pipelines Tekton.<\/li>\n<li><strong>SLSA Verifier<\/strong> \u2014 C\u00f4t\u00e9 consommateur, <code>slsa-verifier verify-artifact<\/code> v\u00e9rifie la signature et l&rsquo;identit\u00e9 du builder.<\/li>\n<\/ul>\n<h3>\u00c0 quoi ressemble la provenance au L2<\/h3>\n<p>La structure JSON est similaire au L1, mais la diff\u00e9rence essentielle est l&rsquo;<strong>enveloppe de signature<\/strong>. La provenance est encapsul\u00e9e dans un <a href=\"https:\/\/github.com\/secure-systems-lab\/dsse\" target=\"_blank\" rel=\"noopener\">DSSE (Dead Simple Signing Envelope)<\/a> :<\/p>\n<pre><code>{\n  \"payloadType\": \"application\/vnd.in-toto+json\",\n  \"payload\": \"<base64-encoded provenance statement>\",\n  \"signatures\": [{\n    \"keyid\": \"\",\n    \"sig\": \"MEUCIQD...base64...signature\"\n  }]\n}<\/code><\/pre>\n<p>La signature provient de l&rsquo;identit\u00e9 du <em>service de build<\/em> \u2014 v\u00e9rifi\u00e9e via le journal de transparence des certificats de Sigstore \u2014 et non de la cl\u00e9 personnelle d&rsquo;un d\u00e9veloppeur. C&rsquo;est ce qui rend la provenance <strong>authentifi\u00e9e<\/strong>.<\/p>\n<hr \/>\n<h2>Build Level 3 \u2014 Builds renforc\u00e9s<\/h2>\n<p>Le L3 est le standard le plus \u00e9lev\u00e9 dans SLSA v1.0. Il ajoute des <strong>garanties d&rsquo;isolation<\/strong> : l&rsquo;environnement de build est renforc\u00e9 de sorte que m\u00eame un script de build compromis ou une d\u00e9pendance malveillante ne puisse falsifier la provenance ou affecter d&rsquo;autres locataires du syst\u00e8me de build.<\/p>\n<h3>Exigences en langage clair<\/h3>\n<ol>\n<li><strong>Plateforme de build renforc\u00e9e<\/strong> \u2014 Le service de build fournit une isolation forte entre les jobs de build (par ex. des VMs \u00e9ph\u00e9m\u00e8res, et non des conteneurs partag\u00e9s). Un job ne peut pas influencer un autre.<\/li>\n<li><strong>Provenance infalsifiable<\/strong> \u2014 La provenance est g\u00e9n\u00e9r\u00e9e de mani\u00e8re \u00e0 ce que le job de build lui-m\u00eame (le code d\u00e9fini par l&rsquo;utilisateur) ne puisse pas la modifier ou la falsifier. La cl\u00e9 de signature ou l&rsquo;identit\u00e9 OIDC n&rsquo;est pas accessible au script de build.<\/li>\n<li><strong>Secrets isol\u00e9s<\/strong> \u2014 Le mat\u00e9riel de signature (cl\u00e9s, jetons OIDC utilis\u00e9s pour la signature) est hors du contr\u00f4le du locataire. M\u00eame si le script de build est enti\u00e8rement compromis, il ne peut pas produire une attestation de provenance valide pour un artefact qu&rsquo;il n&rsquo;a pas construit.<\/li>\n<\/ol>\n<h3>Checklist<\/h3>\n<ul>\n<li>\u2610 Les jobs de build s&rsquo;ex\u00e9cutent dans des environnements \u00e9ph\u00e9m\u00e8res et isol\u00e9s (VMs, et non des runners partag\u00e9s de longue dur\u00e9e).<\/li>\n<li>\u2610 Les environnements de build sont fra\u00eechement provisionn\u00e9s pour chaque build et d\u00e9truits apr\u00e8s.<\/li>\n<li>\u2610 Les \u00e9tapes de build d\u00e9finies par l&rsquo;utilisateur ne peuvent pas acc\u00e9der \u00e0 la cl\u00e9 ou au jeton de signature de la provenance.<\/li>\n<li>\u2610 La plateforme emp\u00eache le build d&rsquo;un locataire d&rsquo;influencer celui d&rsquo;un autre.<\/li>\n<li>\u2610 La provenance est g\u00e9n\u00e9r\u00e9e par la plateforme <em>apr\u00e8s<\/em> la fin du build \u2014 et non en ligne avec le code utilisateur.<\/li>\n<li>\u2610 Des builds herm\u00e9tiques ou sandbox\u00e9s sont utilis\u00e9s dans la mesure du possible (pas d&rsquo;acc\u00e8s r\u00e9seau arbitraire pendant le build).<\/li>\n<li>\u2610 L&rsquo;identit\u00e9 du builder dans la provenance est une valeur v\u00e9rifi\u00e9e et contr\u00f4l\u00e9e par la plateforme.<\/li>\n<li>\u2610 Vous avez v\u00e9rifi\u00e9 que le mod\u00e8le de menace de votre plateforme de build documente comment elle satisfait l&rsquo;isolation L3 de SLSA.<\/li>\n<\/ul>\n<h3>Outils qui satisfont le L3<\/h3>\n<ul>\n<li><strong>GitHub Actions (avec les workflows r\u00e9utilisables slsa-github-generator)<\/strong> \u2014 Les runners h\u00e9berg\u00e9s par GitHub utilisent des VMs \u00e9ph\u00e9m\u00e8res. Le workflow r\u00e9utilisable s&rsquo;ex\u00e9cute dans un job s\u00e9par\u00e9 que le workflow appelant ne peut pas alt\u00e9rer. Cette architecture satisfait le L3 lorsque vous utilisez le <code>slsa-github-generator<\/code> officiel.<\/li>\n<li><strong>Google Cloud Build<\/strong> \u2014 Les builds s&rsquo;ex\u00e9cutent sur des VMs \u00e9ph\u00e9m\u00e8res avec une signature isol\u00e9e. La documentation de Google mappe explicitement Cloud Build au SLSA L3.<\/li>\n<li><strong>Tekton Chains sur Kubernetes renforc\u00e9<\/strong> \u2014 Lorsque Tekton s&rsquo;ex\u00e9cute sur des n\u0153uds avec une isolation au niveau VM (par ex. gVisor, Kata Containers) et que Chains g\u00e8re la signature de mani\u00e8re externe.<\/li>\n<li><strong>Buildkite avec des agents isol\u00e9s<\/strong> \u2014 Lorsque les agents s&rsquo;ex\u00e9cutent sur une infrastructure \u00e9ph\u00e9m\u00e8re (instances EC2 auto-scal\u00e9es termin\u00e9es apr\u00e8s chaque job).<\/li>\n<\/ul>\n<h3>\u00c0 quoi ressemble la provenance au L3<\/h3>\n<p>Le format du document de provenance est le m\u00eame qu&rsquo;au L2 \u2014 une d\u00e9claration in-toto encapsul\u00e9e dans une enveloppe DSSE. La diff\u00e9rence ne r\u00e9side pas dans le <em>format<\/em> mais dans les <em>propri\u00e9t\u00e9s de confiance<\/em> derri\u00e8re la signature. Au L3 :<\/p>\n<ul>\n<li>L&rsquo;identit\u00e9 de signature est v\u00e9rifiablement li\u00e9e \u00e0 une plateforme de build renforc\u00e9e.<\/li>\n<li>Le champ <code>builder.id<\/code> r\u00e9f\u00e9rence un builder reconnu comme satisfaisant les exigences d&rsquo;isolation L3.<\/li>\n<li>Les outils de v\u00e9rification comme <code>slsa-verifier<\/code> v\u00e9rifient l&rsquo;identit\u00e9 du builder par rapport \u00e0 une liste d&rsquo;autorisation de builders conformes au L3.<\/li>\n<\/ul>\n<pre><code># V\u00e9rifier un artefact au SLSA Build L3\nslsa-verifier verify-artifact my-app-linux-amd64 \\\n  --provenance-path my-app-linux-amd64.intoto.jsonl \\\n  --source-uri github.com\/acme\/my-app \\\n  --builder-id https:\/\/github.com\/slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_generic_slsa3.yml@refs\/tags\/v1.9.0<\/code><\/pre>\n<hr \/>\n<h2>Feuille de route d&rsquo;adoption \u00e9tape par \u00e9tape<\/h2>\n<p>N&rsquo;essayez pas de sauter directement au L3. SLSA est con\u00e7u pour une <strong>adoption incr\u00e9mentale<\/strong>. Voici une feuille de route pratique.<\/p>\n<h3>Phase 1 : Atteindre le Build L1 (Semaine 1-2)<\/h3>\n<ol>\n<li><strong>Auditez vos builds.<\/strong> Listez chaque artefact que vous livrez. Comment chacun est-il construit ? Sur le portable de qui ? Quel job CI ?<\/li>\n<li><strong>Scriptez tout.<\/strong> Si une \u00e9tape de build est manuelle, d\u00e9placez-la dans votre configuration CI. Chaque build doit \u00eatre reproductible \u00e0 partir d&rsquo;une seule commande ou d&rsquo;un seul d\u00e9clencheur.<\/li>\n<li><strong>Ajoutez la g\u00e9n\u00e9ration de provenance.<\/strong> Pour GitHub Actions, ajoutez le workflow r\u00e9utilisable <code>slsa-github-generator<\/code>. Pour d&rsquo;autres plateformes, int\u00e9grez la g\u00e9n\u00e9ration d&rsquo;attestations <code>in-toto<\/code> dans votre pipeline.<\/li>\n<li><strong>Publiez la provenance.<\/strong> Attachez la provenance \u00e0 vos artefacts de release. Pour les images de conteneurs, poussez-la comme un artefact OCI aux c\u00f4t\u00e9s de l&rsquo;image. Pour les binaires, publiez le fichier <code>.intoto.jsonl<\/code>.<\/li>\n<li><strong>V\u00e9rifiez que cela fonctionne.<\/strong> Utilisez <code>slsa-verifier<\/code> pour confirmer que la provenance est valide et que l&#8217;empreinte de l&rsquo;artefact correspond.<\/li>\n<\/ol>\n<h3>Phase 2 : Atteindre le Build L2 (Semaine 3-6)<\/h3>\n<ol>\n<li><strong>\u00c9liminez les builds locaux.<\/strong> Imposez une politique : aucun artefact de production n&rsquo;est construit en dehors du CI. Utilisez des r\u00e8gles de protection de branches et des v\u00e9rifications de statut obligatoires.<\/li>\n<li><strong>Passez \u00e0 la provenance g\u00e9n\u00e9r\u00e9e par le service.<\/strong> Passez de la provenance auto-attest\u00e9e \u00e0 la provenance g\u00e9n\u00e9r\u00e9e par la plateforme. Avec GitHub Actions, cela signifie utiliser le workflow r\u00e9utilisable (et non une action composite). Avec GCB, activez l&rsquo;attestation int\u00e9gr\u00e9e.<\/li>\n<li><strong>Activez la signature keyless.<\/strong> Utilisez Sigstore Fulcio pour des certificats \u00e9ph\u00e9m\u00e8res bas\u00e9s sur OIDC. Cela lie la signature \u00e0 l&rsquo;identit\u00e9 du CI, et non \u00e0 une cl\u00e9 longue dur\u00e9e que vous g\u00e9rez.<\/li>\n<li><strong>Ajoutez la v\u00e9rification \u00e0 votre pipeline de d\u00e9ploiement.<\/strong> Avant de d\u00e9ployer, ex\u00e9cutez <code>slsa-verifier<\/code> ou un moteur de politiques (comme <a href=\"https:\/\/kyverno.io\/\" target=\"_blank\" rel=\"noopener\">Kyverno<\/a> ou <a href=\"https:\/\/open-policy-agent.github.io\/gatekeeper\/\" target=\"_blank\" rel=\"noopener\">OPA Gatekeeper<\/a>) pour v\u00e9rifier la provenance de chaque artefact entrant en production.<\/li>\n<\/ol>\n<h3>Phase 3 : Atteindre le Build L3 (Mois 2-4)<\/h3>\n<ol>\n<li><strong>V\u00e9rifiez le mod\u00e8le d&rsquo;isolation de votre plateforme.<\/strong> Lisez la documentation de s\u00e9curit\u00e9 de votre fournisseur CI. Utilise-t-il des VMs \u00e9ph\u00e9m\u00e8res ? Un job peut-il acc\u00e9der \u00e0 l&rsquo;environnement d&rsquo;un autre ? Pour les runners h\u00e9berg\u00e9s par GitHub, la r\u00e9ponse est oui (\u00e9ph\u00e9m\u00e8res) \u2014 pour les runners auto-h\u00e9berg\u00e9s, vous devrez probablement reconfigurer.<\/li>\n<li><strong>Migrez hors des runners partag\u00e9s ou auto-h\u00e9berg\u00e9s<\/strong> (ou renforcez-les). Si vous utilisez des runners GitHub Actions auto-h\u00e9berg\u00e9s, passez \u00e0 des instances \u00e9ph\u00e9m\u00e8res auto-scal\u00e9es (par ex. <a href=\"https:\/\/github.com\/actions\/actions-runner-controller\" target=\"_blank\" rel=\"noopener\">Actions Runner Controller<\/a> avec des pods \u00e9ph\u00e9m\u00e8res ou des groupes d&rsquo;auto-scaling AWS).<\/li>\n<li><strong>Verrouillez le chemin de signature.<\/strong> Assurez-vous que la cl\u00e9 de signature ou le jeton OIDC utilis\u00e9 pour la provenance n&rsquo;est pas accessible aux \u00e9tapes de build utilisateur. Avec les workflows r\u00e9utilisables <code>slsa-github-generator<\/code>, cela est garanti par conception.<\/li>\n<li><strong>Documentez votre mod\u00e8le de menace.<\/strong> D\u00e9crivez ce contre quoi votre plateforme de build prot\u00e8ge et ce qu&rsquo;elle ne couvre pas. Partagez-le avec votre \u00e9quipe de s\u00e9curit\u00e9 pour revue.<\/li>\n<\/ol>\n<hr \/>\n<h2>Pi\u00e8ges courants<\/h2>\n<p>M\u00eame les \u00e9quipes bien intentionn\u00e9es tr\u00e9buchent sur ces probl\u00e8mes. \u00c9vitez-les d\u00e8s le d\u00e9part.<\/p>\n<ul>\n<li><strong>Utiliser une action composite au lieu d&rsquo;un workflow r\u00e9utilisable sur GitHub.<\/strong> Une action composite s&rsquo;ex\u00e9cute <em>\u00e0 l&rsquo;int\u00e9rieur<\/em> du job de l&rsquo;appelant, ce qui signifie que l&rsquo;appelant peut alt\u00e9rer la g\u00e9n\u00e9ration de provenance. Seul un workflow r\u00e9utilisable s&rsquo;ex\u00e9cute dans un job s\u00e9par\u00e9 et isol\u00e9. C&rsquo;est la diff\u00e9rence entre le L1 et le L2+ sur GitHub Actions.<\/li>\n<li><strong>Traiter la provenance comme une case \u00e0 cocher.<\/strong> G\u00e9n\u00e9rer de la provenance ne sert \u00e0 rien si personne ne la v\u00e9rifie. Mettez en place une v\u00e9rification automatis\u00e9e dans votre pipeline de d\u00e9ploiement \u2014 pas seulement dans un rapport d&rsquo;audit.<\/li>\n<li><strong>Stocker les cl\u00e9s de signature dans le d\u00e9p\u00f4t ou les variables d&rsquo;environnement CI.<\/strong> Cela annule l&rsquo;objectif. Utilisez la signature keyless (Sigstore) ou un KMS externe. L&rsquo;identit\u00e9 de signature ne doit pas \u00eatre accessible au script de build.<\/li>\n<li><strong>Ignorer les runners auto-h\u00e9berg\u00e9s.<\/strong> Les runners auto-h\u00e9berg\u00e9s sont souvent des VMs de longue dur\u00e9e partag\u00e9es entre les jobs. Cela brise l&rsquo;isolation L3. Passez \u00e0 des runners \u00e9ph\u00e9m\u00e8res ou utilisez une isolation au niveau VM.<\/li>\n<li><strong>N\u00e9gliger la v\u00e9rification des sources.<\/strong> Le Build Track SLSA se concentre sur le build. Mais si un attaquant peut pousser du code malveillant dans votre d\u00e9p\u00f4t, un build parfaitement conforme ne fait que produire un artefact alt\u00e9r\u00e9 avec une provenance valide. Associez SLSA \u00e0 des contr\u00f4les de source solides (protection de branches, revue de code, signature de commits).<\/li>\n<\/ul>\n<hr \/>\n<h2>Questions fr\u00e9quemment pos\u00e9es<\/h2>\n<h3>SLSA est-il r\u00e9serv\u00e9 aux images de conteneurs ?<\/h3>\n<p>Non. SLSA s&rsquo;applique \u00e0 <em>tout<\/em> artefact logiciel \u2014 binaires, paquets npm, Python wheels, Helm charts, modules Terraform, et bien plus. Le format de provenance (in-toto) est agnostique vis-\u00e0-vis du type d&rsquo;artefact.<\/p>\n<h3>SLSA remplace-t-il le SBOM ?<\/h3>\n<p>Non. Ils sont compl\u00e9mentaires. Un <strong>SBOM<\/strong> (Software Bill of Materials) vous dit <em>ce que contient<\/em> l&rsquo;artefact. La <strong>provenance SLSA<\/strong> vous dit <em>comment il a \u00e9t\u00e9 construit<\/em> et <em>d&rsquo;o\u00f9 il vient<\/em>. Utilisez les deux ensemble pour une visibilit\u00e9 compl\u00e8te de la cha\u00eene d&rsquo;approvisionnement.<\/p>\n<h3>Dois-je atteindre le L3 pour \u00eatre \u00ab conforme \u00bb ?<\/h3>\n<p>Pas n\u00e9cessairement. SLSA est un framework de maturit\u00e9, pas une r\u00e9glementation pass\/fail. Le L1 est d\u00e9j\u00e0 une am\u00e9lioration significative par rapport au L0. De nombreuses organisations visent le L2 comme un point d&rsquo;\u00e9quilibre pratique. Le L3 est destin\u00e9 aux environnements \u00e0 haute s\u00e9curit\u00e9 ou aux projets avec des exigences strictes en mati\u00e8re de cha\u00eene d&rsquo;approvisionnement (par ex. gouvernement, infrastructures critiques).<\/p>\n<h3>Quel est le lien entre SLSA et le NIST SSDF ou l&rsquo;EO 14028 ?<\/h3>\n<p>L&rsquo;Executive Order 14028 et le Secure Software Development Framework (SSDF) du NIST appellent tous deux \u00e0 des pratiques de s\u00e9curit\u00e9 de la cha\u00eene d&rsquo;approvisionnement que SLSA soutient directement. La provenance SLSA et l&rsquo;int\u00e9grit\u00e9 du build sont des impl\u00e9mentations concr\u00e8tes des pratiques SSDF comme PS.1 (prot\u00e9ger le logiciel) et PW.4 (archiver et prot\u00e9ger les processus de build). Adopter SLSA vous aide \u00e0 cocher de nombreuses cases dans ces frameworks.<\/p>\n<h3>Que faire si ma plateforme CI ne supporte pas SLSA nativement ?<\/h3>\n<p>Vous pouvez toujours g\u00e9n\u00e9rer de la provenance en utilisant les <a href=\"https:\/\/in-toto.io\/\" target=\"_blank\" rel=\"noopener\">biblioth\u00e8ques in-toto<\/a> et la signer avec <a href=\"https:\/\/www.sigstore.dev\/\" target=\"_blank\" rel=\"noopener\">Sigstore<\/a>. Cela vous am\u00e8ne au L1. Pour le L2+, vous devrez probablement ajouter une \u00e9tape de g\u00e9n\u00e9ration de provenance qui s&rsquo;ex\u00e9cute dans un job ou service s\u00e9par\u00e9 et de confiance que le build principal ne peut pas alt\u00e9rer.<\/p>\n<hr \/>\n<h2>Lectures compl\u00e9mentaires et ressources<\/h2>\n<ul>\n<li><strong>Sp\u00e9cification officielle SLSA :<\/strong> <a href=\"https:\/\/slsa.dev\/spec\/v1.0\/\" target=\"_blank\" rel=\"noopener\">slsa.dev\/spec\/v1.0<\/a><\/li>\n<li><strong>Format de provenance SLSA :<\/strong> <a href=\"https:\/\/slsa.dev\/provenance\/v1\" target=\"_blank\" rel=\"noopener\">slsa.dev\/provenance\/v1<\/a><\/li>\n<li><strong>slsa-github-generator :<\/strong> <a href=\"https:\/\/github.com\/slsa-framework\/slsa-github-generator\" target=\"_blank\" rel=\"noopener\">D\u00e9p\u00f4t GitHub<\/a><\/li>\n<li><strong>slsa-verifier :<\/strong> <a href=\"https:\/\/github.com\/slsa-framework\/slsa-verifier\" target=\"_blank\" rel=\"noopener\">D\u00e9p\u00f4t GitHub<\/a><\/li>\n<li><strong>Sigstore :<\/strong> <a href=\"https:\/\/www.sigstore.dev\/\" target=\"_blank\" rel=\"noopener\">sigstore.dev<\/a><\/li>\n<li><strong>in-toto :<\/strong> <a href=\"https:\/\/in-toto.io\/\" target=\"_blank\" rel=\"noopener\">in-toto.io<\/a><\/li>\n<li><strong>Notre guide de provenance SLSA :<\/strong> <a href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/artifact-provenance-attestations-slsa-in-toto-2\/\">Provenance SLSA en profondeur<\/a><\/li>\n<li><strong>Atelier pratique :<\/strong> <a href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/lab-generating-verifying-slsa-provenance-container-images\/\">Atelier Provenance SLSA \u2014 G\u00e9n\u00e9rez et v\u00e9rifiez votre premi\u00e8re attestation<\/a><\/li>\n<\/ul>\n<hr \/>\n<h2>Conclusion : Commencez au L1, livrez lundi<\/h2>\n<p>SLSA n&rsquo;est pas un framework tout-ou-rien. L&rsquo;objectif m\u00eame du syst\u00e8me de niveaux est de pouvoir <strong>commencer petit et progresser de mani\u00e8re incr\u00e9mentale<\/strong>.<\/p>\n<p>Voici votre plan d&rsquo;action pour lundi matin :<\/p>\n<ol>\n<li><strong>Choisissez un artefact<\/strong> \u2014 votre binaire ou image de conteneur la plus critique.<\/li>\n<li><strong>Ajoutez la g\u00e9n\u00e9ration de provenance<\/strong> \u00e0 son pipeline CI en utilisant <code>slsa-github-generator<\/code> ou l&rsquo;\u00e9quivalent de votre plateforme.<\/li>\n<li><strong>Publiez la provenance<\/strong> aux c\u00f4t\u00e9s de l&rsquo;artefact.<\/li>\n<li><strong>V\u00e9rifiez-la<\/strong> avec <code>slsa-verifier<\/code>.<\/li>\n<li><strong>C\u00e9l\u00e9brez.<\/strong> Vous \u00eates maintenant au SLSA Build L1 \u2014 en avance sur la grande majorit\u00e9 des projets logiciels.<\/li>\n<\/ol>\n<p>Puis it\u00e9rez. Passez au L2 en vous assurant que le service de build signe la provenance. Renforcez vos runners pour le L3. Chaque \u00e9tape r\u00e9duit mat\u00e9riellement votre risque li\u00e9 \u00e0 la cha\u00eene d&rsquo;approvisionnement.<\/p>\n<p>Les attaques sur la cha\u00eene d&rsquo;approvisionnement continueront. La question n&rsquo;est pas <em>s&rsquo;il faut<\/em> adopter SLSA \u2014 c&rsquo;est <em>\u00e0 quelle vitesse<\/em> vous pouvez y arriver. Commencez d\u00e8s aujourd&rsquo;hui.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Introduction : Qu&rsquo;est-ce que SLSA et pourquoi devriez-vous vous en soucier ? Supply-chain Levels for Software Artifacts \u2014 SLSA (prononc\u00e9 \u00ab salsa \u00bb) \u2014 est un framework de s\u00e9curit\u00e9 cr\u00e9\u00e9 par Google et d\u00e9sormais maintenu par l&rsquo;Open Source Security Foundation (OpenSSF). Son objectif est d&rsquo;une simplicit\u00e9 trompeuse : rendre plus difficile pour les attaquants de &#8230; <a title=\"Les Niveaux SLSA Expliqu\u00e9s : Checklist Pratique de Conformit\u00e9 pour les \u00c9quipes d&rsquo;Ing\u00e9nierie\" class=\"read-more\" href=\"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/slsa-levels-explained-practical-compliance-checklist\/\" aria-label=\"En savoir plus sur Les Niveaux SLSA Expliqu\u00e9s : Checklist Pratique de Conformit\u00e9 pour les \u00c9quipes d&rsquo;Ing\u00e9nierie\">Lire la suite<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[49,50],"tags":[],"post_folder":[],"class_list":["post-453","post","type-post","status-publish","format-standard","hentry","category-ci-cd-security","category-software-supply-chain"],"_links":{"self":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/453","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/comments?post=453"}],"version-history":[{"count":2,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/453\/revisions"}],"predecessor-version":[{"id":736,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/453\/revisions\/736"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=453"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=453"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=453"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=453"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}