{"id":476,"date":"2026-02-03T11:37:47","date_gmt":"2026-02-03T10:37:47","guid":{"rendered":"https:\/\/secure-pipelines.com\/?p=476"},"modified":"2026-03-24T12:54:34","modified_gmt":"2026-03-24T11:54:34","slug":"signing-verifying-container-images-sigstore-cosign","status":"publish","type":"post","link":"https:\/\/secure-pipelines.com\/fr\/ci-cd-security\/signing-verifying-container-images-sigstore-cosign\/","title":{"rendered":"Signature et V\u00e9rification des Images Container avec Sigstore et Cosign"},"content":{"rendered":"

Introduction : Pourquoi la signature des artefacts est essentielle en CI\/CD<\/h2>\n

Les pipelines modernes de livraison logicielle sont remarquablement efficaces pour construire et livrer du code rapidement. Mais la rapidit\u00e9 sans confiance est un risque. Entre le moment o\u00f9 le code source est commit\u00e9 et celui o\u00f9 une image container s’ex\u00e9cute en production, il existe un intervalle \u2014 un intervalle o\u00f9 la falsification, la substitution ou la corruption silencieuse peuvent survenir sans que personne ne s’en aper\u00e7oive.<\/p>\n

Il ne s’agit pas d’une pr\u00e9occupation th\u00e9orique. L’attaque SolarWinds<\/strong> en 2020 a d\u00e9montr\u00e9 comment des adversaires pouvaient injecter du code malveillant dans un processus de build, produisant des artefacts sign\u00e9s mais compromis qui se sont propag\u00e9s \u00e0 des milliers d’organisations. La br\u00e8che Codecov<\/strong> en 2021 a montr\u00e9 comment un script CI falsifi\u00e9 pouvait exfiltrer des secrets de chaque d\u00e9p\u00f4t l’utilisant. Dans les deux cas, la supply chain \u2014 l’infrastructure entre le code et le d\u00e9ploiement \u2014 constituait la surface d’attaque.<\/p>\n

La signature des artefacts r\u00e9pond \u00e0 une pi\u00e8ce critique de ce puzzle : l’authenticit\u00e9 et l’int\u00e9grit\u00e9<\/strong>. En signant cryptographiquement une image container, vous cr\u00e9ez un lien v\u00e9rifiable entre l’image et l’identit\u00e9 (personne, \u00e9quipe ou syst\u00e8me CI) qui l’a produite. Les consommateurs de cette image peuvent alors v\u00e9rifier la signature avant de l’ex\u00e9cuter, s’assurant qu’elle n’a pas \u00e9t\u00e9 modifi\u00e9e depuis sa construction.<\/p>\n

Pendant des ann\u00e9es, la signature \u00e9tait impraticable dans la plupart des organisations. La gestion des cl\u00e9s GPG \u00e9tait fastidieuse, la distribution des cl\u00e9s \u00e9tait fragile, et l’outillage n\u00e9cessitait une expertise cryptographique approfondie. Sigstore<\/strong> a chang\u00e9 la donne. Il a introduit une suite d’outils open-source qui rendent la signature et la v\u00e9rification accessibles, automatis\u00e9es et \u2014 point crucial \u2014 sans cl\u00e9 (keyless).<\/p>\n

Ce guide parcourt l’\u00e9cosyst\u00e8me Sigstore, vous montre comment signer et v\u00e9rifier des images container avec Cosign<\/strong>, int\u00e9grer la signature dans les pipelines CI\/CD, et attacher des attestations et des SBOMs. \u00c0 la fin, vous aurez une compr\u00e9hension pratique de la fa\u00e7on d’int\u00e9grer la signature des artefacts comme partie standard de votre processus de livraison.<\/p>\n

Qu’est-ce que Sigstore ?<\/h2>\n

Sigstore est un projet open-source sous la Linux Foundation qui fournit des outils gratuits, transparents et faciles \u00e0 utiliser pour signer, v\u00e9rifier et prot\u00e9ger les artefacts logiciels. Il a \u00e9t\u00e9 cr\u00e9\u00e9 pour r\u00e9soudre un probl\u00e8me sp\u00e9cifique : rendre la signature cryptographique pratique pour l’\u00e9cosyst\u00e8me open-source et au-del\u00e0.<\/p>\n

L’\u00e9cosyst\u00e8me Sigstore se compose de trois composants fondamentaux :<\/p>\n

Cosign<\/h3>\n

Cosign<\/strong> est l’outil c\u00f4t\u00e9 client pour signer et v\u00e9rifier les images container et autres artefacts OCI. C’est ce avec quoi les d\u00e9veloppeurs et les pipelines CI\/CD interagissent directement. Cosign prend en charge \u00e0 la fois la signature traditionnelle par paire de cl\u00e9s et le nouveau flux de signature keyless.<\/p>\n

Fulcio<\/h3>\n

Fulcio<\/strong> est une autorit\u00e9 de certification (CA) gratuite qui \u00e9met des certificats \u00e0 courte dur\u00e9e de vie bas\u00e9s sur une identit\u00e9 OpenID Connect (OIDC). Lorsque vous utilisez la signature keyless, Fulcio v\u00e9rifie votre identit\u00e9 via un fournisseur OIDC (tel que Google, GitHub ou Microsoft) et \u00e9met un certificat qui lie votre identit\u00e9 \u00e0 une cl\u00e9 de signature. Le certificat n’est valide que quelques minutes \u2014 suffisamment longtemps pour signer un artefact, mais assez court pour que la compromission de cl\u00e9 ne soit pas un risque persistant.<\/p>\n

Rekor<\/h3>\n

Rekor<\/strong> est un log de transparence \u2014 un registre immuable, en ajout seul, qui enregistre les \u00e9v\u00e9nements de signature. Chaque fois qu’un artefact est sign\u00e9, un enregistrement est ajout\u00e9 \u00e0 Rekor. Cela fournit une piste publique et auditable de qui a sign\u00e9 quoi et quand. C’est conceptuellement similaire aux logs de Certificate Transparency utilis\u00e9s dans l’\u00e9cosyst\u00e8me TLS.<\/p>\n

En quoi la signature keyless diff\u00e8re de GPG<\/h3>\n

La signature traditionnelle bas\u00e9e sur GPG vous oblige \u00e0 g\u00e9n\u00e9rer une paire de cl\u00e9s \u00e0 longue dur\u00e9e de vie, prot\u00e9ger la cl\u00e9 priv\u00e9e, distribuer la cl\u00e9 publique, et g\u00e9rer la rotation et la r\u00e9vocation des cl\u00e9s. C’est op\u00e9rationnellement lourd et sujet aux erreurs, c’est pourquoi la plupart des projets n’ont jamais adopt\u00e9 la signature.<\/p>\n

La signature keyless de Sigstore \u00e9limine cette charge :<\/p>\n

    \n
  • Pas de cl\u00e9s \u00e0 longue dur\u00e9e de vie<\/strong> \u2014 Les cl\u00e9s de signature sont \u00e9ph\u00e9m\u00e8res. Elles n’existent que pendant la dur\u00e9e de l’op\u00e9ration de signature.<\/li>\n
  • Confiance bas\u00e9e sur l’identit\u00e9<\/strong> \u2014 Au lieu de faire confiance \u00e0 une cl\u00e9, vous faites confiance \u00e0 une identit\u00e9 (par exemple, un workflow GitHub Actions, une adresse e-mail sp\u00e9cifique). Fulcio lie l’identit\u00e9 \u00e0 la cl\u00e9 \u00e9ph\u00e9m\u00e8re via un certificat \u00e0 courte dur\u00e9e de vie.<\/li>\n
  • Transparence par d\u00e9faut<\/strong> \u2014 Chaque \u00e9v\u00e9nement de signature est enregistr\u00e9 dans Rekor, cr\u00e9ant un enregistrement auditable sans n\u00e9cessiter l’exploitation de votre propre infrastructure.<\/li>\n
  • Pas de probl\u00e8me de distribution de cl\u00e9s<\/strong> \u2014 Les v\u00e9rificateurs n’ont pas besoin d’obtenir une cl\u00e9 publique par un canal s\u00e9par\u00e9. Ils v\u00e9rifient par rapport \u00e0 l’identit\u00e9 et au log de transparence.<\/li>\n<\/ul>\n

    Signer des images container avec Cosign<\/h2>\n

    Installation de Cosign<\/h3>\n

    Cosign est distribu\u00e9 sous forme de binaire unique. Vous pouvez l’installer sur la plupart des plateformes :<\/p>\n

    # macOS (Homebrew)\nbrew install cosign\n\n# Linux (Go install)\ngo install github.com\/sigstore\/cosign\/v2\/cmd\/cosign@latest\n\n# Linux (binary release)\ncurl -LO https:\/\/github.com\/sigstore\/cosign\/releases\/latest\/download\/cosign-linux-amd64\nchmod +x cosign-linux-amd64\nsudo mv cosign-linux-amd64 \/usr\/local\/bin\/cosign\n\n# Verify installation\ncosign version<\/code><\/pre>\n
    Signature avec une paire de cl\u00e9s<\/h3>\n
    L’approche la plus simple consiste \u00e0 g\u00e9n\u00e9rer une paire de cl\u00e9s et \u00e0 l’utiliser pour signer les images. C’est utile lorsque vous souhaitez un contr\u00f4le total sur la gestion des cl\u00e9s ou lorsque la signature keyless n’est pas disponible dans votre environnement.<\/p>\n
    \u00c9tape 1 : G\u00e9n\u00e9rer une paire de cl\u00e9s<\/strong><\/p>\n
    cosign generate-key-pair<\/code><\/pre>\n
    Cela cr\u00e9e deux fichiers : cosign.key<\/code> (cl\u00e9 priv\u00e9e, prot\u00e9g\u00e9e par mot de passe) et cosign.pub<\/code> (cl\u00e9 publique). Stockez la cl\u00e9 priv\u00e9e en lieu s\u00fbr \u2014 dans un gestionnaire de secrets, un HSM ou un coffre-fort chiffr\u00e9.<\/p>\n
    \u00c9tape 2 : Signer une image container<\/strong><\/p>\n
    # Signer une image par son digest (toujours pr\u00e9f\u00e9rer le digest au tag)\ncosign sign --key cosign.key ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
    Cosign vous demandera le mot de passe de la cl\u00e9 priv\u00e9e, g\u00e9n\u00e9rera une signature et la poussera vers le m\u00eame registre OCI \u00e0 c\u00f4t\u00e9 de l’image. La signature est stock\u00e9e comme un artefact OCI s\u00e9par\u00e9, tagu\u00e9 selon une convention qui la lie au digest de l’image.<\/p>\n
    Important :<\/strong> Signez toujours par digest, pas par tag. Les tags sont mutables \u2014 quelqu’un pourrait d\u00e9placer un tag pour pointer vers une image diff\u00e9rente apr\u00e8s la signature. Les digests sont adress\u00e9s par contenu et immuables.<\/p>\n
    Signature keyless avec identit\u00e9 OIDC<\/h3>\n
    La signature keyless est l’approche recommand\u00e9e pour les pipelines CI\/CD. Elle supprime enti\u00e8rement la n\u00e9cessit\u00e9 de g\u00e9rer des cl\u00e9s de signature.<\/p>\n
    # Signature keyless (interactive \u2014 ouvre le navigateur pour la connexion OIDC)\ncosign sign ghcr.io\/myorg\/myapp@sha256:abc123...\n\n# Signature keyless (non interactive, pour CI\/CD)\n# Le flag --yes ignore l'invite de confirmation\ncosign sign --yes ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
    Dans un environnement CI\/CD comme GitHub Actions, Cosign d\u00e9tecte automatiquement le jeton OIDC ambiant fourni par la plateforme. Aucune interaction navigateur n’est n\u00e9cessaire.<\/p>\n
    Ce qui se passe en coulisses<\/h3>\n
    Lorsque vous ex\u00e9cutez cosign sign --yes<\/code> en mode keyless, la s\u00e9quence suivante se produit :<\/p>\n
      \n
    1. G\u00e9n\u00e9ration de cl\u00e9 \u00e9ph\u00e9m\u00e8re<\/strong> \u2014 Cosign g\u00e9n\u00e8re une paire de cl\u00e9s temporaire en m\u00e9moire.<\/li>\n
    2. Authentification OIDC<\/strong> \u2014 Cosign obtient un jeton d’identit\u00e9 OIDC depuis l’environnement (par exemple, le fournisseur OIDC de GitHub Actions) ou vous invite \u00e0 vous authentifier via un navigateur.<\/li>\n
    3. \u00c9mission du certificat<\/strong> \u2014 Cosign envoie la cl\u00e9 publique et le jeton OIDC \u00e0 Fulcio<\/strong>. Fulcio v\u00e9rifie le jeton, extrait l’identit\u00e9 (e-mail, URI du workflow, etc.) et \u00e9met un certificat X.509 \u00e0 courte dur\u00e9e de vie liant l’identit\u00e9 \u00e0 la cl\u00e9 publique.<\/li>\n
    4. Signature<\/strong> \u2014 Cosign signe le digest de l’image en utilisant la cl\u00e9 priv\u00e9e \u00e9ph\u00e9m\u00e8re.<\/li>\n
    5. Journalisation de transparence<\/strong> \u2014 La signature, le certificat et le digest de l’image sont enregistr\u00e9s dans Rekor<\/strong>. Cette entr\u00e9e est horodat\u00e9e et immuable.<\/li>\n
    6. T\u00e9l\u00e9versement de la signature<\/strong> \u2014 La signature est pouss\u00e9e vers le registre OCI en tant qu’artefact compagnon.<\/li>\n
    7. Destruction de la cl\u00e9<\/strong> \u2014 La cl\u00e9 priv\u00e9e \u00e9ph\u00e9m\u00e8re est supprim\u00e9e. Elle n’est jamais stock\u00e9e nulle part.<\/li>\n<\/ol>\n
      Le r\u00e9sultat est une image sign\u00e9e avec une cha\u00eene v\u00e9rifiable : le log Rekor prouve que la signature a \u00e9t\u00e9 cr\u00e9\u00e9e \u00e0 un moment pr\u00e9cis par une identit\u00e9 sp\u00e9cifique, et le certificat Fulcio prouve que l’identit\u00e9 a \u00e9t\u00e9 authentifi\u00e9e au moment de la signature.<\/p>\n
      V\u00e9rification des signatures<\/h2>\n
      La signature n’est utile que si les consommateurs v\u00e9rifient. Cosign fournit des commandes de v\u00e9rification simples pour les sc\u00e9narios bas\u00e9s sur des cl\u00e9s et keyless.<\/p>\n
      V\u00e9rification avec une cl\u00e9 publique<\/h3>\n
      Si l’image a \u00e9t\u00e9 sign\u00e9e avec une paire de cl\u00e9s, v\u00e9rifiez en utilisant la cl\u00e9 publique :<\/p>\n
      cosign verify --key cosign.pub ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
      Cosign r\u00e9cup\u00e8re la signature depuis le registre OCI, la v\u00e9rifie par rapport \u00e0 la cl\u00e9 publique et affiche le r\u00e9sultat. Si la signature est valide, il affiche la charge utile de signature. Sinon, il se termine avec une erreur.<\/p>\n
      V\u00e9rification keyless<\/h3>\n
      Pour les images sign\u00e9es en mode keyless, la v\u00e9rification est bas\u00e9e sur l’identit\u00e9 plut\u00f4t que sur une cl\u00e9. Vous sp\u00e9cifiez qui<\/em> vous vous attendez \u00e0 avoir sign\u00e9 l’image :<\/p>\n
      # V\u00e9rifier qu'un workflow GitHub Actions sp\u00e9cifique a sign\u00e9 l'image\ncosign verify \\\n  --certificate-identity \"https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/release.yml@refs\/heads\/main\" \\\n  --certificate-oidc-issuer \"https:\/\/token.actions.githubusercontent.com\" \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
      Cette commande v\u00e9rifie que :<\/p>\n
        \n
      • L’image poss\u00e8de une signature valide.<\/li>\n
      • Le certificat de signature a \u00e9t\u00e9 \u00e9mis par Fulcio.<\/li>\n
      • L’identit\u00e9 dans le certificat correspond au --certificate-identity<\/code> sp\u00e9cifi\u00e9.<\/li>\n
      • L’\u00e9metteur OIDC correspond au --certificate-oidc-issuer<\/code>.<\/li>\n
      • L’\u00e9v\u00e9nement de signature est enregistr\u00e9 dans le log de transparence Rekor.<\/li>\n<\/ul>\n
        Vous pouvez \u00e9galement utiliser la correspondance par expression r\u00e9guli\u00e8re pour des politiques plus flexibles :<\/p>\n
        cosign verify \\\n  --certificate-identity-regexp \"https:\/\/github.com\/myorg\/.*\" \\\n  --certificate-oidc-issuer \"https:\/\/token.actions.githubusercontent.com\" \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
        Application de la v\u00e9rification dans les contr\u00f4leurs d’admission<\/h3>\n
        La v\u00e9rification manuelle est utile pour le d\u00e9bogage, mais les environnements de production n\u00e9cessitent une application automatis\u00e9e. Les contr\u00f4leurs d’admission Kubernetes peuvent rejeter toute image qui ne poss\u00e8de pas de signature valide.<\/p>\n
        Kyverno<\/strong> est un moteur de politiques populaire avec une prise en charge int\u00e9gr\u00e9e de la v\u00e9rification Cosign :<\/p>\n
        apiVersion: kyverno.io\/v1\nkind: ClusterPolicy\nmetadata:\n  name: verify-image-signatures\nspec:\n  validationFailureAction: Enforce\n  background: false\n  rules:\n    - name: verify-cosign-signature\n      match:\n        any:\n          - resources:\n              kinds:\n                - Pod\n      verifyImages:\n        - imageReferences:\n            - \"ghcr.io\/myorg\/*\"\n          attestors:\n            - entries:\n                - keyless:\n                    subject: \"https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/release.yml@refs\/heads\/main\"\n                    issuer: \"https:\/\/token.actions.githubusercontent.com\"\n                    rekor:\n                      url: https:\/\/rekor.sigstore.dev<\/code><\/pre>\n
        Le Sigstore Policy Controller<\/strong> (anciennement Cosign Policy Webhook) fournit une fonctionnalit\u00e9 similaire avec une approche native Sigstore :<\/p>\n
        apiVersion: policy.sigstore.dev\/v1beta1\nkind: ClusterImagePolicy\nmetadata:\n  name: require-signed-images\nspec:\n  images:\n    - glob: \"ghcr.io\/myorg\/**\"\n  authorities:\n    - keyless:\n        identities:\n          - issuer: \"https:\/\/token.actions.githubusercontent.com\"\n            subject: \"https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/release.yml@refs\/heads\/main\"\n        ctlog:\n          url: https:\/\/rekor.sigstore.dev<\/code><\/pre>\n
        Avec l’une ou l’autre approche, tout pod qui r\u00e9f\u00e9rence une image non sign\u00e9e (ou incorrectement sign\u00e9e) de votre registre sera rejet\u00e9 au moment de l’admission.<\/p>\n
        Int\u00e9gration de la signature dans les pipelines CI\/CD<\/h2>\n
        GitHub Actions avec signature keyless<\/h3>\n
        GitHub Actions dispose d’un support OIDC natif, ce qui en fait l’environnement id\u00e9al pour la signature keyless. Voici un workflow complet qui construit, pousse et signe une image container :<\/p>\n
        name: Build and Sign Container Image\n\non:\n  push:\n    branches: [main]\n\npermissions:\n  contents: read\n  packages: write\n  id-token: write  # Required for keyless signing\n\njobs:\n  build-sign:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Checkout code\n        uses: actions\/checkout@v4\n\n      - name: Set up Docker Buildx\n        uses: docker\/setup-buildx-action@v3\n\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\n      - name: Build and push image\n        id: build\n        uses: docker\/build-push-action@v6\n        with:\n          push: true\n          tags: ghcr.io\/${{ github.repository }}:${{ github.sha }}\n\n      - name: Install Cosign\n        uses: sigstore\/cosign-installer@v3\n\n      - name: Sign the image\n        env:\n          DIGEST: ${{ steps.build.outputs.digest }}\n        run: |\n          cosign sign --yes \\\n            ghcr.io\/${{ github.repository }}@${DIGEST}<\/code><\/pre>\n
        Points cl\u00e9s :<\/p>\n
          \n
        • La permission id-token: write<\/code> active le fournisseur OIDC de GitHub Actions, que Cosign utilise pour la signature keyless.<\/li>\n
        • L’image est sign\u00e9e par digest<\/strong>, pas par tag, en utilisant la sortie de l’\u00e9tape de build.<\/li>\n
        • Aucun secret ni cl\u00e9 n’est n\u00e9cessaire \u2014 le jeton OIDC de GitHub est l’identit\u00e9.<\/li>\n<\/ul>\n
          Exemple GitLab CI<\/h3>\n
          GitLab CI prend \u00e9galement en charge les jetons OIDC pour la signature keyless. L’approche est similaire mais utilise le m\u00e9canisme de jeton d’identit\u00e9 de GitLab :<\/p>\n
          stages:\n  - build\n  - sign\n\nvariables:\n  IMAGE: ${CI_REGISTRY_IMAGE}:${CI_COMMIT_SHORT_SHA}\n\nbuild:\n  stage: build\n  image: docker:24\n  services:\n    - docker:24-dind\n  script:\n    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY\n    - docker build -t $IMAGE .\n    - docker push $IMAGE\n    - echo \"DIGEST=$(docker inspect --format='{{index .RepoDigests 0}}' $IMAGE | cut -d@ -f2)\" >> build.env\n  artifacts:\n    reports:\n      dotenv: build.env\n\nsign:\n  stage: sign\n  image: alpine:3.19\n  id_tokens:\n    SIGSTORE_ID_TOKEN:\n      aud: sigstore\n  before_script:\n    - apk add --no-cache cosign\n  script:\n    - cosign sign --yes ${CI_REGISTRY_IMAGE}@${DIGEST}<\/code><\/pre>\n
          Le bloc id_tokens<\/code> indique \u00e0 GitLab de g\u00e9n\u00e9rer un jeton OIDC avec l’audience sigstore<\/code>. Cosign r\u00e9cup\u00e8re automatiquement le jeton depuis la variable d’environnement SIGSTORE_ID_TOKEN<\/code>.<\/p>\n
          Stockage des signatures dans les registres OCI<\/h3>\n
          Par d\u00e9faut, Cosign stocke les signatures dans le m\u00eame registre OCI que l’image sign\u00e9e. La signature est pouss\u00e9e en tant que tag s\u00e9par\u00e9 suivant la convention sha256-<digest>.sig<\/code>. Cela signifie :<\/p>\n
            \n
          • Aucune infrastructure suppl\u00e9mentaire n’est n\u00e9cessaire pour le stockage des signatures.<\/li>\n
          • Les signatures accompagnent l’image lors de la mise en miroir ou de la r\u00e9plication.<\/li>\n
          • La plupart des registres majeurs (GHCR, Docker Hub, ECR, GCR, ACR, Harbor) prennent en charge les artefacts OCI et fonctionnent avec Cosign nativement.<\/li>\n<\/ul>\n
            Si vous devez stocker les signatures dans un registre diff\u00e9rent (par exemple, un stockage d\u00e9di\u00e9 aux signatures), vous pouvez utiliser la variable d’environnement COSIGN_REPOSITORY<\/code> :<\/p>\n
            export COSIGN_REPOSITORY=ghcr.io\/myorg\/signatures\ncosign sign --yes ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
            Attestations et rattachement de SBOM<\/h2>\n
            Les signatures prouvent qui<\/em> a construit une image. Les attestations vont plus loin \u2014 elles prouvent comment<\/em> elle a \u00e9t\u00e9 construite et ce qu’elle contient<\/em>. Cosign prend en charge le rattachement de m\u00e9tadonn\u00e9es structur\u00e9es aux images sous forme d’attestations in-toto.<\/p>\n
            Rattachement de la provenance SLSA avec cosign attest<\/code><\/h3>\n
            SLSA (Supply-chain Levels for Software Artifacts) d\u00e9crit le processus de build : quelle source a \u00e9t\u00e9 utilis\u00e9e, quel constructeur a \u00e9t\u00e9 ex\u00e9cut\u00e9, quelles \u00e9tapes ont \u00e9t\u00e9 r\u00e9alis\u00e9es. Vous pouvez rattacher une attestation de provenance SLSA \u00e0 une image :<\/p>\n
            # Cr\u00e9er une d\u00e9claration de provenance (exemple simplifi\u00e9)\ncat > provenance.json <<'EOF'\n{\n  \"_type\": \"https:\/\/in-toto.io\/Statement\/v1\",\n  \"subject\": [\n    {\n      \"name\": \"ghcr.io\/myorg\/myapp\",\n      \"digest\": {\n        \"sha256\": \"abc123...\"\n      }\n    }\n  ],\n  \"predicateType\": \"https:\/\/slsa.dev\/provenance\/v1\",\n  \"predicate\": {\n    \"buildDefinition\": {\n      \"buildType\": \"https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/release.yml\",\n      \"resolvedDependencies\": [\n        {\n          \"uri\": \"git+https:\/\/github.com\/myorg\/myapp@refs\/heads\/main\",\n          \"digest\": {\n            \"sha1\": \"def456...\"\n          }\n        }\n      ]\n    },\n    \"runDetails\": {\n      \"builder\": {\n        \"id\": \"https:\/\/github.com\/actions\/runner\"\n      }\n    }\n  }\n}\nEOF\n\n# Attester l'image avec la d\u00e9claration de provenance (keyless)\ncosign attest --yes \\\n  --predicate provenance.json \\\n  --type slsaprovenance \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
            En pratique, vous utiliseriez un g\u00e9n\u00e9rateur SLSA (tel que slsa-github-generator<\/code>) pour produire automatiquement la provenance plut\u00f4t que de la r\u00e9diger manuellement.<\/p>\n
            Rattachement des SBOMs<\/h3>\n
            Un Software Bill of Materials (SBOM) liste chaque composant \u00e0 l'int\u00e9rieur de votre image container. Cosign peut rattacher un SBOM \u00e0 une image afin que les consommateurs puissent inspecter son contenu :<\/p>\n
            # G\u00e9n\u00e9rer un SBOM avec Syft\nsyft ghcr.io\/myorg\/myapp@sha256:abc123... -o spdx-json > sbom.spdx.json\n\n# Rattacher le SBOM en tant qu'attestation (approche recommand\u00e9e)\ncosign attest --yes \\\n  --predicate sbom.spdx.json \\\n  --type spdxjson \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
            Alternativement, vous pouvez utiliser l'ancienne commande cosign attach sbom<\/code>, bien que l'approche par attestation soit pr\u00e9f\u00e9r\u00e9e car elle est sign\u00e9e et v\u00e9rifiable :<\/p>\n
            # Ancienne approche (rattach\u00e9 mais non sign\u00e9)\ncosign attach sbom --sbom sbom.spdx.json \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
            V\u00e9rification des attestations<\/h3>\n
            Les consommateurs peuvent v\u00e9rifier les attestations exactement comme les signatures. La commande cosign verify-attestation<\/code> v\u00e9rifie \u00e0 la fois la signature de l'attestation et l'identit\u00e9 du signataire :<\/p>\n
            # V\u00e9rifier l'attestation de provenance SLSA\ncosign verify-attestation \\\n  --type slsaprovenance \\\n  --certificate-identity \"https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/release.yml@refs\/heads\/main\" \\\n  --certificate-oidc-issuer \"https:\/\/token.actions.githubusercontent.com\" \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...\n\n# V\u00e9rifier l'attestation SBOM\ncosign verify-attestation \\\n  --type spdxjson \\\n  --certificate-identity \"https:\/\/github.com\/myorg\/myapp\/.github\/workflows\/release.yml@refs\/heads\/main\" \\\n  --certificate-oidc-issuer \"https:\/\/token.actions.githubusercontent.com\" \\\n  ghcr.io\/myorg\/myapp@sha256:abc123...<\/code><\/pre>\n
            Vous pouvez \u00e9galement utiliser des moteurs de politiques comme Kyverno pour v\u00e9rifier les attestations au moment de l'admission, garantissant que seules les images avec une provenance ou des SBOMs valides sont d\u00e9ploy\u00e9es sur vos clusters.<\/p>\n
            Consid\u00e9rations de s\u00e9curit\u00e9 et compromis<\/h2>\n
            La signature des artefacts est un outil puissant, mais il est important de comprendre ce contre quoi elle prot\u00e8ge et ce contre quoi elle ne prot\u00e8ge pas.<\/p>\n
            Ce contre quoi la signature prot\u00e8ge<\/h3>\n