La signature de code est depuis longtemps un pilier de la s\u00e9curit\u00e9 logicielle. Lorsque vous v\u00e9rifiez une signature, vous savez qui<\/em> a sign\u00e9 un artefact. Mais savoir qui a sign\u00e9 quelque chose ne vous dit pas comment<\/em> il a \u00e9t\u00e9 construit, o\u00f9<\/em> il a \u00e9t\u00e9 construit, ni quel code source<\/em> a \u00e9t\u00e9 utilis\u00e9. Un mainteneur pourrait signer un binaire compil\u00e9 sur un ordinateur portable compromis avec des d\u00e9pendances inject\u00e9es \u2014 et la signature serait tout de m\u00eame valide.<\/p>\n C’est la lacune que la provenance des artefacts<\/strong> comble. La provenance est un enregistrement v\u00e9rifiable de la mani\u00e8re dont un artefact logiciel a \u00e9t\u00e9 produit. Elle capture la plateforme de build, le d\u00e9p\u00f4t source, le point d’entr\u00e9e, les param\u00e8tres de build et les d\u00e9pendances impliqu\u00e9es. Combin\u00e9e aux signatures, la provenance offre aux consommateurs une image compl\u00e8te : non seulement \u00ab qui se porte garant de cet artefact \u00bb, mais \u00ab quel processus l’a r\u00e9ellement cr\u00e9\u00e9 \u00bb.<\/p>\n Dans ce guide, nous explorerons les deux frameworks les plus importants dans ce domaine \u2014 SLSA<\/strong> (Supply-chain Levels for Software Artifacts) et in-toto<\/strong> \u2014 et nous parcourrons leur mise en \u0153uvre pratique dans les pipelines CI\/CD modernes. Que vous soyez un ing\u00e9nieur plateforme s\u00e9curisant votre infrastructure de build ou un d\u00e9veloppeur cherchant \u00e0 comprendre ce que le niveau 3 de SLSA exige r\u00e9ellement, cet article vous fournira la profondeur technique n\u00e9cessaire.<\/p>\n La provenance des artefacts est une m\u00e9tadonn\u00e9e qui d\u00e9crit l’origine et le processus de build d’un artefact logiciel. Consid\u00e9rez-la comme un re\u00e7u de build : un document structur\u00e9 et sign\u00e9 qui r\u00e9pond \u00e0 trois questions fondamentales :<\/p>\n Les signatures et la provenance sont compl\u00e9mentaires mais servent des objectifs diff\u00e9rents :<\/p>\n Vous avez besoin des deux. Une signature sans provenance est une d\u00e9claration de type \u00ab faites-moi confiance \u00bb. Une provenance sans signature est une affirmation non v\u00e9rifi\u00e9e. Ensemble, elles fournissent une preuve d’int\u00e9grit\u00e9, une auditabilit\u00e9 et une base pour l’application automatis\u00e9e de politiques.<\/p>\n La provenance r\u00e9pond \u00e0 plusieurs risques critiques de la cha\u00eene d’approvisionnement :<\/p>\n SLSA<\/strong> (prononc\u00e9 \u00ab salsa \u00bb) est un framework de s\u00e9curit\u00e9 d\u00e9velopp\u00e9 \u00e0 l’origine chez Google et maintenant maintenu par l’OpenSSF. Il d\u00e9finit un mod\u00e8le de maturit\u00e9 pour la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement, avec la provenance en son c\u0153ur. SLSA ne prescrit pas d’outils sp\u00e9cifiques \u2014 il d\u00e9finit des exigences<\/em> que les outils et les plateformes doivent satisfaire.<\/p>\n SLSA mod\u00e9lise la cha\u00eene d’approvisionnement logicielle comme un pipeline simple :<\/p>\n Source \u2192 Plateforme de Build \u2192 Artefact<\/strong><\/p>\n Chaque \u00e9tape pr\u00e9sente des menaces distinctes. La source peut \u00eatre alt\u00e9r\u00e9e (commits malveillants, VCS compromis). La plateforme de build peut \u00eatre compromise (scripts de build modifi\u00e9s, d\u00e9pendances inject\u00e9es). L’artefact peut \u00eatre alt\u00e9r\u00e9 apr\u00e8s le build (empoisonnement du registre, attaque de l’homme du milieu). SLSA r\u00e9pond \u00e0 chacune de ces menaces par des exigences de plus en plus strictes \u00e0 chaque niveau.<\/p>\n SLSA v1.0 d\u00e9finit quatre niveaux de build, chacun s’appuyant sur le pr\u00e9c\u00e9dent :<\/p>\n SLSA d\u00e9finit un format de provenance sp\u00e9cifique qui doit inclure :<\/p>\n Cette provenance est exprim\u00e9e sous forme de document JSON structur\u00e9, plus pr\u00e9cis\u00e9ment comme une attestation in-toto<\/strong> \u2014 ce qui nous am\u00e8ne \u00e0 la section suivante.<\/p>\n in-toto<\/strong> est un framework pour s\u00e9curiser les cha\u00eenes d’approvisionnement logicielles par le biais de m\u00e9tadonn\u00e9es sign\u00e9es cryptographiquement. Alors que SLSA d\u00e9finit ce que<\/em> la provenance doit contenir et quel niveau de s\u00e9curit\u00e9<\/em> elle fournit, in-toto d\u00e9finit le format de donn\u00e9es et le m\u00e9canisme de signature<\/em> utilis\u00e9s pour repr\u00e9senter et v\u00e9rifier cette provenance.<\/p>\n Dans le mod\u00e8le original d’in-toto, une cha\u00eene d’approvisionnement est d\u00e9crite par deux types de m\u00e9tadonn\u00e9es :<\/p>\n Ce mod\u00e8le est puissant pour les cha\u00eenes d’approvisionnement multi-\u00e9tapes o\u00f9 vous devez v\u00e9rifier que l’\u00e9tape A a produit la sortie X, qui a ensuite \u00e9t\u00e9 consomm\u00e9e par l’\u00e9tape B pour produire la sortie Y, chaque \u00e9tape \u00e9tant effectu\u00e9e par un acteur autoris\u00e9.<\/p>\n Le format moderne d’attestation in-toto (ITE-6) g\u00e9n\u00e9ralise le mod\u00e8le original en un framework flexible et extensible. Une attestation comporte trois couches :<\/p>\n 1. Statement :<\/strong> L’enveloppe ext\u00e9rieure qui lie un pr\u00e9dicat \u00e0 un ou plusieurs sujets.<\/p>\n 2. Predicate :<\/strong> Les m\u00e9tadonn\u00e9es r\u00e9elles concernant l’artefact. Diff\u00e9rents types de pr\u00e9dicats servent diff\u00e9rents objectifs :<\/p>\n 3. Subject :<\/strong> Une ou plusieurs r\u00e9f\u00e9rences d’artefacts, chacune identifi\u00e9e par un nom et un ensemble de digests cryptographiques. Cela lie le pr\u00e9dicat \u00e0 des artefacts sp\u00e9cifiques.<\/p>\n Les attestations in-toto sont encapsul\u00e9es dans un DSSE<\/strong> (Dead Simple Signing Envelope) pour la signature. DSSE r\u00e9sout plusieurs probl\u00e8mes des approches de signature pr\u00e9c\u00e9dentes :<\/p>\n DSSE signe \u00e0 la fois le type de payload et le payload ensemble (en utilisant un PAE \u2014 Pre-Authentication Encoding), emp\u00eachant les attaques de confusion o\u00f9 une signature pour un type de payload est r\u00e9utilis\u00e9e pour un autre. Il prend en charge les signatures multiples, permettant des sc\u00e9narios de signature multi-parties.<\/p>\n La relation est simple : la provenance SLSA est un type de pr\u00e9dicat in-toto<\/strong>. Lorsqu’une plateforme de build conforme \u00e0 SLSA g\u00e9n\u00e8re une provenance, elle produit une attestation in-toto avec Parcourons les impl\u00e9mentations pratiques dans les plateformes CI\/CD les plus courantes.<\/p>\n Le projet Pour les artefacts g\u00e9n\u00e9riques :<\/strong><\/p>\n Pour les images de conteneurs :<\/strong><\/p>\n GitHub propose d\u00e9sormais des attestations d’artefacts natives via GitLab ne dispose pas encore d’un g\u00e9n\u00e9rateur de provenance SLSA natif au m\u00eame niveau de maturit\u00e9 que celui de GitHub, mais vous pouvez g\u00e9n\u00e9rer et signer des m\u00e9tadonn\u00e9es de provenance en utilisant directement les outils du framework SLSA.<\/p>\n Pour les images de conteneurs, les attestations de provenance sont g\u00e9n\u00e9ralement stock\u00e9es aux c\u00f4t\u00e9s de l’image dans le registre OCI en utilisant le mod\u00e8le d’attestation Cosign. L’attestation est stock\u00e9e comme un artefact OCI s\u00e9par\u00e9 li\u00e9 \u00e0 l’image par son digest :<\/p>\n Cette approche tire parti de l’API referrers de la sp\u00e9cification de distribution OCI, qui permet aux clients de d\u00e9couvrir les attestations associ\u00e9es \u00e0 un manifeste d’image donn\u00e9. Des outils comme G\u00e9n\u00e9rer la provenance n’est que la moiti\u00e9 de l’histoire. Les consommateurs \u2014 qu’il s’agisse d’op\u00e9rateurs humains ou de syst\u00e8mes automatis\u00e9s \u2014 doivent v\u00e9rifier la provenance avant de faire confiance \u00e0 un artefact.<\/p>\n L’outil Le v\u00e9rificateur contr\u00f4le les \u00e9l\u00e9ments suivants :<\/p>\n Pour une v\u00e9rification plus flexible, Pour les artefacts attest\u00e9s avec la fonctionnalit\u00e9 d’attestation native de GitHub, le CLI Pour les portes de d\u00e9ploiement en production, les contr\u00f4leurs d’admission peuvent appliquer automatiquement des politiques de provenance. Voici un exemple utilisant le policy-controller de Sigstore dans un cluster Kubernetes :<\/p>\n Quel que soit l’outil utilis\u00e9, la v\u00e9rification de la provenance doit confirmer :<\/p>\n La provenance et SLSA sont des concepts puissants, mais l’adoption dans le monde r\u00e9el s’accompagne de d\u00e9fis significatifs. Une \u00e9valuation honn\u00eate aide les \u00e9quipes \u00e0 planifier des strat\u00e9gies d’adoption r\u00e9alistes.<\/p>\n Le niveau SLSA 3 exige des environnements de build renforc\u00e9s et isol\u00e9s \u2014 et c’est l\u00e0 que la plupart des organisations rencontrent des frictions. Les builds herm\u00e9tiques signifient que chaque d\u00e9pendance doit \u00eatre explicitement d\u00e9clar\u00e9e et r\u00e9cup\u00e9r\u00e9e via des canaux contr\u00f4l\u00e9s. Pas de t\u00e9l\u00e9chargement de packages al\u00e9atoires depuis Internet pendant le build. Pas d’acc\u00e8s r\u00e9seau \u00e0 des services non d\u00e9clar\u00e9s.<\/p>\n Pour de nombreux projets, cela n\u00e9cessite des changements fondamentaux dans le fonctionnement des builds. Les langages avec des \u00e9cosyst\u00e8mes de packages riches (Node.js, Python, Go) ont souvent des processus de build qui t\u00e9l\u00e9chargent implicitement des d\u00e9pendances. Passer \u00e0 un mod\u00e8le herm\u00e9tique signifie vendoriser les d\u00e9pendances, utiliser des fichiers de verrouillage avec des v\u00e9rifications d’int\u00e9grit\u00e9, ou ex\u00e9cuter les builds derri\u00e8re un proxy de d\u00e9pendances qui applique une liste blanche.<\/p>\n Les builders isol\u00e9s ajoutent un co\u00fbt op\u00e9rationnel. Les environnements de build \u00e9ph\u00e9m\u00e8res qui sont d\u00e9truits apr\u00e8s chaque build emp\u00eachent la contamination crois\u00e9e mais augmentent les temps de build et les d\u00e9penses d’infrastructure. Les runners auto-h\u00e9berg\u00e9s sur GitHub Actions, par exemple, ne fournissent pas les m\u00eames garanties d’isolation que les runners h\u00e9berg\u00e9s par GitHub.<\/p>\n L’\u00e9cosyst\u00e8me SLSA m\u00fbrit rapidement mais pr\u00e9sente encore des lacunes :<\/p>\n Alors que la provenance des images de conteneurs dispose d’un mod\u00e8le clair de stockage et de distribution (registres OCI et referrers), d’autres types d’artefacts font face \u00e0 des d\u00e9fis :<\/p>\n Des exigences strictes de provenance peuvent ralentir les workflows de d\u00e9veloppement :<\/p>\n La provenance des artefacts comble une lacune fondamentale dans la s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement logicielle. Alors que les signatures prouvent qui<\/em> a approuv\u00e9 un artefact, la provenance prouve comment il a r\u00e9ellement \u00e9t\u00e9 construit<\/em>. Combin\u00e9e au mod\u00e8le de maturit\u00e9 du framework SLSA et au format d’attestation d’in-toto, nous disposons d\u00e9sormais d’une approche pratique et standardis\u00e9e pour l’int\u00e9grit\u00e9 des builds.<\/p>\n Les points cl\u00e9s pour les \u00e9quipes qui d\u00e9butent ce parcours :<\/p>\n La s\u00e9curit\u00e9 de la cha\u00eene d’approvisionnement n’est pas un outil unique ou un contr\u00f4le unique. C’est une approche en couches o\u00f9 chaque contr\u00f4le \u2014 int\u00e9grit\u00e9 de la source, int\u00e9grit\u00e9 du build, provenance, v\u00e9rification \u2014 renforce les autres. La provenance est le tissu conjonctif qui rend l’ensemble du syst\u00e8me auditable et v\u00e9rifiable. Commencez \u00e0 la g\u00e9n\u00e9rer d\u00e8s aujourd’hui, et it\u00e9rez vers le haut.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction La signature de code est depuis longtemps un pilier de la s\u00e9curit\u00e9 logicielle. Lorsque vous v\u00e9rifiez une signature, vous savez qui a sign\u00e9 un artefact. Mais savoir qui a sign\u00e9 quelque chose ne vous dit pas comment il a \u00e9t\u00e9 construit, o\u00f9 il a \u00e9t\u00e9 construit, ni quel code source a \u00e9t\u00e9 utilis\u00e9. Un … 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-489","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\/489","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=489"}],"version-history":[{"count":1,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/489\/revisions"}],"predecessor-version":[{"id":490,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/posts\/489\/revisions\/490"}],"wp:attachment":[{"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/media?parent=489"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/categories?post=489"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/tags?post=489"},{"taxonomy":"post_folder","embeddable":true,"href":"https:\/\/secure-pipelines.com\/fr\/wp-json\/wp\/v2\/post_folder?post=489"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Qu’est-ce que la provenance des artefacts ?<\/h2>\n
\n
Provenance vs. Signatures<\/h3>\n
\n
Pourquoi la provenance est importante<\/h3>\n
\n
Le framework SLSA<\/h2>\n
Le mod\u00e8le de build SLSA<\/h3>\n
Les niveaux SLSA (v1.0)<\/h3>\n
Niveau de Build 1 \u2014 La provenance existe<\/h3>\n
\n
Niveau de Build 2 \u2014 Build h\u00e9berg\u00e9, provenance sign\u00e9e<\/h3>\n
\n
Niveau de Build 3 \u2014 Plateforme de build renforc\u00e9e<\/h3>\n
\n
Niveau de Build 4 \u2014 Revue \u00e0 deux parties et builds herm\u00e9tiques<\/h3>\n
\n
Sp\u00e9cification de la provenance SLSA<\/h3>\n
\n
Le framework d’attestation in-toto<\/h2>\n
Layout et m\u00e9tadonn\u00e9es de lien in-toto<\/h3>\n
\n
Le format d’attestation in-toto<\/h3>\n
{\n \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n \"subject\": [\n {\n \"name\": \"my-artifact\",\n \"digest\": {\n \"sha256\": \"a1b2c3d4e5f6...\"\n }\n }\n ],\n \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n \"predicate\": { ... }\n}<\/code><\/pre>\n\n
https:\/\/slsa.dev\/provenance\/v1<\/code> \u2014 Provenance SLSA (informations de build)<\/li>\nhttps:\/\/spdx.dev\/Document<\/code> \u2014 SBOM au format SPDX<\/li>\nhttps:\/\/cyclonedx.org\/bom<\/code> \u2014 SBOM au format CycloneDX<\/li>\nhttps:\/\/in-toto.io\/attestation\/vulns<\/code> \u2014 R\u00e9sultats d’analyse de vuln\u00e9rabilit\u00e9s<\/li>\n<\/ul>\nDSSE (Dead Simple Signing Envelope)<\/h3>\n
{\n \"payloadType\": \"application\/vnd.in-toto+json\",\n \"payload\": \"<base64-encoded statement>\",\n \"signatures\": [\n {\n \"keyid\": \"...\",\n \"sig\": \"<base64-encoded signature>\"\n }\n ]\n}<\/code><\/pre>\nComment in-toto se rapporte \u00e0 SLSA<\/h3>\n
predicateType: https:\/\/slsa.dev\/provenance\/v1<\/code>, la signe avec DSSE, et l’associe \u00e0 l’artefact construit via le champ subject. SLSA d\u00e9finit les exigences et le mod\u00e8le de menace ; in-toto fournit le format de donn\u00e9es et le framework de v\u00e9rification.<\/p>\nG\u00e9n\u00e9ration de la provenance en CI\/CD<\/h2>\n
GitHub Actions : slsa-github-generator<\/h3>\n
slsa-framework\/slsa-github-generator<\/code> fournit des workflows r\u00e9utilisables qui g\u00e9n\u00e8rent une provenance SLSA de niveau 3 sur GitHub Actions. La provenance est g\u00e9n\u00e9r\u00e9e par un workflow h\u00e9berg\u00e9 et isol\u00e9 que le locataire du build ne peut pas alt\u00e9rer.<\/p>\nname: SLSA Provenance for Generic Artifacts\non:\n push:\n tags:\n - \"v*\"\n\njobs:\n build:\n runs-on: ubuntu-latest\n outputs:\n digests: ${{ steps.hash.outputs.digests }}\n steps:\n - uses: actions\/checkout@v4\n - name: Build artifact\n run: |\n go build -o my-binary .\/cmd\/app\n - name: Generate subject digest\n id: hash\n run: |\n DIGEST=$(sha256sum my-binary | base64 -w0)\n echo \"digests=$DIGEST\" >> \"$GITHUB_OUTPUT\"\n - uses: actions\/upload-artifact@v4\n with:\n name: my-binary\n path: my-binary\n\n provenance:\n needs: [build]\n permissions:\n actions: read\n id-token: write\n contents: write\n uses: slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_generic_slsa3.yml@v2.1.0\n with:\n base64-subjects: ${{ needs.build.outputs.digests }}\n upload-assets: true<\/code><\/pre>\nname: SLSA Provenance for Container Images\non:\n push:\n tags:\n - \"v*\"\n\njobs:\n build:\n runs-on: ubuntu-latest\n outputs:\n image: ${{ steps.build.outputs.image }}\n digest: ${{ steps.build.outputs.digest }}\n permissions:\n packages: write\n steps:\n - uses: actions\/checkout@v4\n - name: Log in to GHCR\n uses: docker\/login-action@v3\n with:\n registry: ghcr.io\n username: ${{ github.actor }}\n password: ${{ secrets.GITHUB_TOKEN }}\n - name: Build and push\n id: build\n uses: docker\/build-push-action@v5\n with:\n push: true\n tags: ghcr.io\/${{ github.repository }}:${{ github.ref_name }}\n\n provenance:\n needs: [build]\n permissions:\n actions: read\n id-token: write\n packages: write\n uses: slsa-framework\/slsa-github-generator\/.github\/workflows\/generator_container_slsa3.yml@v2.1.0\n with:\n image: ${{ needs.build.outputs.image }}\n digest: ${{ needs.build.outputs.digest }}\n registry-username: ${{ github.actor }}\n secrets:\n registry-password: ${{ secrets.GITHUB_TOKEN }}<\/code><\/pre>\nAttestations d’artefacts GitHub<\/h3>\n
actions\/attest-build-provenance<\/code>. C’est plus simple que le g\u00e9n\u00e9rateur SLSA et produit des attestations sign\u00e9es par Sigstore stock\u00e9es dans l’API d’attestation de GitHub.<\/p>\nname: Build and Attest\non:\n push:\n branches: [main]\n\njobs:\n build:\n runs-on: ubuntu-latest\n permissions:\n id-token: write\n contents: read\n attestations: write\n steps:\n - uses: actions\/checkout@v4\n - name: Build binary\n run: go build -o my-binary .\/cmd\/app\n - name: Attest build provenance\n uses: actions\/attest-build-provenance@v2\n with:\n subject-path: my-binary\n - name: Attest container image\n uses: actions\/attest-build-provenance@v2\n with:\n subject-name: ghcr.io\/${{ github.repository }}\n subject-digest: ${{ steps.push.outputs.digest }}\n push-to-registry: true<\/code><\/pre>\nGitLab CI : G\u00e9n\u00e9ration de m\u00e9tadonn\u00e9es de provenance<\/h3>\n
stages:\n - build\n - provenance\n\nbuild:\n stage: build\n image: golang:1.22\n script:\n - go build -o my-binary .\/cmd\/app\n - sha256sum my-binary > checksums.txt\n artifacts:\n paths:\n - my-binary\n - checksums.txt\n\ngenerate-provenance:\n stage: provenance\n image: ghcr.io\/slsa-framework\/slsa-generator-generic:v2.1.0\n needs: [build]\n script:\n - |\n cat > provenance.json <<PROV\n {\n \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n \"subject\": [\n {\n \"name\": \"my-binary\",\n \"digest\": {\n \"sha256\": \"$(sha256sum my-binary | awk '{print $1}')\"\n }\n }\n ],\n \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n \"predicate\": {\n \"buildDefinition\": {\n \"buildType\": \"https:\/\/gitlab.com\/gitlab-ci\",\n \"externalParameters\": {\n \"repository\": \"${CI_PROJECT_URL}\",\n \"ref\": \"${CI_COMMIT_SHA}\"\n }\n },\n \"runDetails\": {\n \"builder\": {\n \"id\": \"https:\/\/gitlab.com\/${CI_PROJECT_PATH}\/-\/runners\/${CI_RUNNER_ID}\"\n },\n \"metadata\": {\n \"invocationId\": \"${CI_PIPELINE_URL}\",\n \"startedOn\": \"${CI_PIPELINE_CREATED_AT}\"\n }\n }\n }\n }\n PROV\n - cosign attest-blob --predicate provenance.json --type slsaprovenance my-binary\n artifacts:\n paths:\n - provenance.json<\/code><\/pre>\nStockage de la provenance dans les registres OCI<\/h3>\n
# Attacher la provenance \u00e0 une image de conteneur dans le registre\ncosign attest --predicate provenance.json \\\n --type slsaprovenance \\\n --key cosign.key \\\n ghcr.io\/myorg\/myimage@sha256:abc123...\n\n# Pour la signature sans cl\u00e9 avec Sigstore\ncosign attest --predicate provenance.json \\\n --type slsaprovenance \\\n --yes \\\n ghcr.io\/myorg\/myimage@sha256:abc123...<\/code><\/pre>\ncosign<\/code> et crane<\/code> peuvent alors r\u00e9cup\u00e9rer et v\u00e9rifier ces attestations lors du d\u00e9ploiement.<\/p>\nV\u00e9rification de la provenance<\/h2>\n
CLI slsa-verifier<\/h3>\n
slsa-verifier<\/code> v\u00e9rifie la provenance SLSA g\u00e9n\u00e9r\u00e9e par des builders de confiance (actuellement les builders bas\u00e9s sur GitHub Actions).<\/p>\n# V\u00e9rifier un artefact g\u00e9n\u00e9rique\nslsa-verifier verify-artifact my-binary \\\n --provenance-path my-binary.intoto.jsonl \\\n --source-uri github.com\/myorg\/myrepo \\\n --source-tag v1.2.3\n\n# V\u00e9rifier une image de conteneur\nslsa-verifier verify-image ghcr.io\/myorg\/myimage@sha256:abc123... \\\n --source-uri github.com\/myorg\/myrepo \\\n --source-tag v1.2.3<\/code><\/pre>\n\n
cosign verify-attestation<\/h3>\n
cosign verify-attestation<\/code> vous permet de v\u00e9rifier les attestations in-toto attach\u00e9es aux images de conteneurs avec filtrage par type :<\/p>\n# V\u00e9rifier l'attestation de provenance SLSA\ncosign verify-attestation \\\n --type slsaprovenance \\\n --certificate-identity \"https:\/\/github.com\/myorg\/myrepo\/.github\/workflows\/release.yml@refs\/tags\/v1.2.3\" \\\n --certificate-oidc-issuer \"https:\/\/token.actions.githubusercontent.com\" \\\n ghcr.io\/myorg\/myimage@sha256:abc123...\n\n# V\u00e9rifier avec une politique CUE\ncosign verify-attestation \\\n --type slsaprovenance \\\n --policy policy.cue \\\n ghcr.io\/myorg\/myimage@sha256:abc123...\n\n# V\u00e9rifier avec une politique Rego\ncosign verify-attestation \\\n --type slsaprovenance \\\n --policy policy.rego \\\n ghcr.io\/myorg\/myimage@sha256:abc123...<\/code><\/pre>\ngh attestation verify<\/h3>\n
gh<\/code> fournit une v\u00e9rification int\u00e9gr\u00e9e :<\/p>\n# V\u00e9rifier un artefact local\ngh attestation verify my-binary \\\n --owner myorg\n\n# V\u00e9rifier une image de conteneur\ngh attestation verify oci:\/\/ghcr.io\/myorg\/myimage@sha256:abc123... \\\n --owner myorg\n\n# T\u00e9l\u00e9charger et inspecter le bundle d'attestation\ngh attestation download my-binary \\\n --owner myorg \\\n --output attestation.jsonl<\/code><\/pre>\nProvenance dans les contr\u00f4leurs d’admission<\/h3>\n
apiVersion: policy.sigstore.dev\/v1beta1\nkind: ClusterImagePolicy\nmetadata:\n name: require-slsa-provenance\nspec:\n images:\n - glob: \"ghcr.io\/myorg\/**\"\n authorities:\n - keyless:\n url: https:\/\/fulcio.sigstore.dev\n identities:\n - issuer: https:\/\/token.actions.githubusercontent.com\n subject: \"https:\/\/github.com\/myorg\/*\"\n attestations:\n - name: must-have-slsa-provenance\n predicateType: https:\/\/slsa.dev\/provenance\/v1\n policy:\n type: cue\n data: |\n predicateType: \"https:\/\/slsa.dev\/provenance\/v1\"\n predicate: buildDefinition: {\n buildType: =~\"^https:\/\/github.com\/slsa-framework\/slsa-github-generator\/\"\n }<\/code><\/pre>\nQue v\u00e9rifier lors de la validation<\/h3>\n
\n
D\u00e9fis pratiques<\/h2>\n
Atteindre le niveau SLSA 3+ est difficile<\/h3>\n
Maturit\u00e9 de l’outillage et lacunes de l’\u00e9cosyst\u00e8me<\/h3>\n
\n
Provenance pour les artefacts non-conteneurs<\/h3>\n
\n
\u00c9quilibrer la rigueur et la v\u00e9locit\u00e9 des d\u00e9veloppeurs<\/h3>\n
\n
Conclusion<\/h2>\n
\n