Attestations GitHub Actions

Les attestations permettent de prouver cryptographiquement l'origine de vos artefacts : qui les a construits, à partir de quel code, avec quel workflow. C'est un élément clé de la sécurité supply chain.

Ce que vous allez apprendre

• Comprendre les attestations et ce qu'elles prouvent cryptographiquement
• Distinguer attestation de provenance (SLSA) et attestation SBOM
• Générer une attestation pour un artefact ou une image Docker
• Attester un SBOM en complément de la provenance
• Savoir où GitHub et Sigstore conservent les attestations

Qu'est-ce qu'une attestation ?

Une attestation est un document signé qui certifie des informations sur un artefact :

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "my-app",
      "digest": {
        "sha256": "abc123..."
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v1",
  "predicate": {
    "buildDefinition": {
      "buildType": "https://actions.github.io/buildtypes/workflow/v1"
    },
    "runDetails": {
      "builder": {
        "id": "https://github.com/actions/runner"
      }
    }
  }
}

Ce que prouve l'attestation :

Information	Valeur
Artefact	Hash SHA256 de l'artefact
Builder	GitHub Actions runner
Repository	owner/repo
Commit	SHA du commit
Workflow	Fichier et référence
Signataire	Sigstore (Fulcio/Rekor)

Glissez pour voir

Types d'attestations

GitHub Actions produit deux types d'attestations standard, provenance et SBOM, et autorise des attestations sur mesure.

Attestation de provenance (SLSA)

Prouve comment l'artefact a été construit :

• Quel code source
• Quel workflow
• Quels paramètres de build

Attestation SBOM

Prouve ce que contient l'artefact :

• Liste des dépendances
• Versions exactes
• Licences

Attestation personnalisée

Vous pouvez ajouter vos propres informations :

• Résultats de tests
• Scan de sécurité
• Métadonnées métier

Générer une attestation

L'action officielle actions/attest-build-provenance génère et signe l'attestation. Le workflow a besoin de trois permissions : id-token, contents et attestations.

Avec actions/attest-build-provenance

Cette action produit une attestation de provenance pour n'importe quel fichier d'artefact.

name: Build and Attest

on:
  push:
    branches: [main]

permissions:
  id-token: write       # Pour signer avec Sigstore
  contents: read
  attestations: write   # Pour publier l'attestation

jobs:
  build:
    runs-on: ubuntu-24.04
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Builder l'artefact
        run: |
          npm ci
          npm run build
          tar -czf dist.tar.gz dist/

      - name: Générer l'attestation
        uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
        with:
          subject-path: dist.tar.gz

Pour une image Docker

Pour une image, l'attestation cible le digest publié et peut être attachée directement au registre.

jobs:
  build:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
      contents: read
      attestations: write
      packages: write
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Se connecter à GHCR
        uses: docker/login-action@4907a6ddec9925e35a0a9e82d7399ccc52663121 # v4.1.0
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Builder et pousser l'image
        id: build
        uses: docker/build-push-action@f9f3042f7e2789586610d6e8b85c8f03e5195baf # v7.2.0
        with:
          push: true
          tags: ghcr.io/${{ github.repository }}:${{ github.sha }}

      - name: Générer l'attestation
        uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
        with:
          subject-name: ghcr.io/${{ github.repository }}
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

Attestation SBOM

Générez un SBOM (Software Bill of Materials) puis attestez-le, pour prouver le contenu exact de l'artefact :

jobs:
  sbom:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Générer le SBOM
        uses: anchore/sbom-action@e22c389904149dbc22b58101806040fa8d37a610 # v0.24.0
        id: sbom
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Attester le SBOM
        uses: actions/attest-sbom@c604332985a26aa8cf1bdc465b92731239ec6b9e # v4.1.0
        with:
          subject-path: dist.tar.gz
          sbom-path: sbom.spdx.json

Où sont stockées les attestations ?

Une attestation générée est conservée à deux endroits, ce qui la rend à la fois interrogeable et infalsifiable.

GitHub Attestations API

Les attestations sont stockées dans GitHub et accessibles via :

• L'API REST : GET /repos/{owner}/{repo}/attestations/{digest}
• La CLI : gh attestation verify

Sigstore Transparency Log

Les attestations sont aussi enregistrées dans Rekor, le log de transparence de Sigstore. Cela garantit qu'elles ne peuvent pas être modifiées après coup.

Workflow complet

Voici un workflow de release complet : build, SBOM, double attestation (provenance et SBOM), puis publication.

name: Build, Attest and Release

on:
  push:
    tags:
      - 'v*'

permissions:
  id-token: write
  contents: write
  attestations: write
  packages: write

jobs:
  build:
    runs-on: ubuntu-24.04
    outputs:
      digest: ${{ steps.build.outputs.digest }}
    steps:
      - name: Récupérer le code
        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          persist-credentials: false

      - name: Builder l'artefact
        id: build
        env:
          REF_NAME: ${{ github.ref_name }}
        run: |
          npm ci
          npm run build
          tar -czf "my-app-$REF_NAME.tar.gz" dist/
          echo "digest=$(sha256sum "my-app-$REF_NAME.tar.gz" | cut -d' ' -f1)" >> "$GITHUB_OUTPUT"

      - name: Générer le SBOM
        uses: anchore/sbom-action@e22c389904149dbc22b58101806040fa8d37a610 # v0.24.0
        with:
          format: spdx-json
          output-file: sbom.spdx.json

      - name: Attester la provenance
        uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
        with:
          subject-path: my-app-${{ github.ref_name }}.tar.gz

      - name: Attester le SBOM
        uses: actions/attest-sbom@c604332985a26aa8cf1bdc465b92731239ec6b9e # v4.1.0
        with:
          subject-path: my-app-${{ github.ref_name }}.tar.gz
          sbom-path: sbom.spdx.json

      - name: Créer la release
        uses: softprops/action-gh-release@b4309332981a82ec1c5618f44dd2e27cc8bfbfda # v3.0.0
        with:
          files: |
            my-app-${{ github.ref_name }}.tar.gz
            sbom.spdx.json

Bonnes pratiques

Quelques réflexes garantissent que vos attestations servent réellement à sécuriser la chaîne de livraison.

1. Toujours attester les releases

Chaque artefact distribué doit avoir une attestation de provenance, sans elle, le consommateur ne peut pas vérifier d'où il vient.

2. Attester les images Docker

Pour une image, push-to-registry: true attache l'attestation directement à l'image dans le registre.

- uses: actions/attest-build-provenance@a2bbfa25375fe432b6a289bc6b6cd05ecd0c4c32 # v4.1.0
  with:
    subject-name: ghcr.io/${{ github.repository }}
    subject-digest: ${{ steps.build.outputs.digest }}
    push-to-registry: true  # Attache l'attestation à l'image

3. Générer aussi un SBOM

L'attestation de provenance dit comment l'artefact est construit ; le SBOM dit ce qu'il contient. Les deux sont complémentaires.

4. Vérifier avant déploiement

Une attestation n'a de valeur que si elle est vérifiée côté consommateur. Avant de déployer un artefact, validez sa provenance, voir Vérifier les attestations.

À retenir

• Une attestation est un document signé qui prouve l'origine d'un artefact : code source, workflow, builder.
• L'attestation de provenance (SLSA) dit comment l'artefact a été construit ; l'attestation SBOM dit ce qu'il contient.
• actions/attest-build-provenance et actions/attest-sbom exigent les permissions id-token: write et attestations: write.
• Les attestations sont signées via Sigstore et enregistrées dans le log de transparence Rekor, impossible de les modifier après coup.
• Une attestation ne protège que si elle est vérifiée avant déploiement.

Prochaines étapes

Vérifier les attestations Valider la provenance d'un artefact avant de le déployer

Sécuriser GitHub Actions Le guide complet de durcissement des workflows

Attaques supply chain Pourquoi prouver la provenance des artefacts est devenu vital

Épingler les actions par SHA Sécuriser les actions qui produisent vos artefacts

Pour la référence complète, consultez la documentation officielle sur les artifact attestations.

×

📖 Voir la documentation →