Comment générer une SBOM dans GitHub Actions

Quatre approches

1. Exporter le graphe de dépendances

GitHub construit un graphe de dépendances à partir des manifestes et des lockfiles d'un dépôt et peut l'exporter sous forme de SBOM SPDX. Aucune modification de workflow n'est nécessaire : ouvrez l'onglet Insights du dépôt, choisissez Dependency graph et cliquez sur Export SBOM. Il décrit le dépôt sur la branche par défaut, et non un build particulier : les outils et paquets qu'un workflow installe n'y figurent donc pas.

Pour l'automatiser, utilisez l'API REST. GET /repos/{owner}/{repo}/dependency-graph/sbom renvoie le SPDX JSON en un seul appel, mais GitHub fermera ce point d'accès après le 13 novembre 2026. Son remplacement est asynchrone : demandez un rapport, puis récupérez le sbom_url qu'il renvoie. Cette URL répond 202 pendant la génération de la SBOM, puis redirige vers le fichier SPDX JSON, que GitHub conserve jusqu'à une semaine.

# Export the dependency graph as SPDX JSON (closing down after November 13, 2026)
curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/dependency-graph/sbom

# The replacement: request a report; the response carries an sbom_url
curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer $GITHUB_TOKEN" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/repos/OWNER/REPO/dependency-graph/sbom/generate-report

2. Ajouter une étape de génération

Une étape du workflow exécute un générateur sur l'espace de travail ou sur une image. anchore/sbom-action exécute Syft : par défaut, il scanne le répertoire de l'espace de travail et produit du SPDX JSON, il peut scanner une image de conteneur à la place, et il téléverse la SBOM comme artefact de workflow et l'attache aux releases. Son README demande contents: write, plus actions: read lorsqu'il attache la SBOM à une release :

name: sbom
on:
  push:
    branches: [main]
  release:
    types: [published]

jobs:
  sbom:
    runs-on: ubuntu-latest
    permissions:
      contents: write # upload the SBOM
      actions: read # attach it to a release
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
      - run: npm ci
      # Scan the workspace after the install step
      - uses: anchore/sbom-action@v0
        with:
          path: .
          format: cyclonedx-json

format accepte spdx, spdx-json, cyclonedx ou cyclonedx-json. Pour scanner une image, remplacez path par image, par exemple image: ghcr.io/OWNER/app:1.0. Voir SBOM Docker pour les SBOM d'image propres à BuildKit.

Trivy et cdxgen peuvent s'exécuter de la même façon, sous forme de simples étapes run. cdxgen écrit du CycloneDX ; depuis la version 13, son paquet npm est @cdxgen/cdxgen :

    steps:
      - uses: actions/checkout@v7
      - run: npm ci
      - run: npm install -g @cdxgen/cdxgen --ignore-scripts
      - run: cdxgen -o bom.json .
      - uses: actions/upload-artifact@v7
        with:
          name: sbom
          path: bom.json

Le moment compte. Exécutez l'étape après l'installation des dépendances, sinon elle ne les verra pas. Même dans ce cas, un générateur voit les fichiers qu'il a devant lui : un paquet qu'un script a téléchargé, utilisé et supprimé, ou un outil installé en dehors d'un gestionnaire de paquets, peut manquer.

3. La signer sous forme d'attestation

Les attestations d'artefacts de GitHub lient une SBOM à l'artefact qu'elle décrit et la signent avec Sigstore. actions/attest@v4 accepte du SPDX ou du CycloneDX JSON via sbom-path, jusqu'à 16 Mo. Sans sbom-path, il produit à la place une provenance de build SLSA. actions/attest-sbom est en cours d'abandon au profit d'actions/attest, qu'il encapsule désormais. Le job a besoin de id-token: write pour obtenir un certificat de signature et de attestations: write pour stocker le résultat :

jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write # sign with a Sigstore certificate
      contents: read
      attestations: write # store the attestation
    steps:
      - uses: actions/checkout@v7
      - run: make build # writes dist/my-app
      - uses: anchore/sbom-action@v0
        with:
          path: .
          format: spdx-json
          output-file: sbom.spdx.json
          upload-artifact: false
      - uses: actions/attest@v4
        with:
          subject-path: dist/my-app
          sbom-path: sbom.spdx.json

Pour une image de conteneur, transmettez subject-name et subject-digest au lieu de subject-path, réglez push-to-registry: true et ajoutez packages: write. Les attestations d'artefacts fonctionnent dans les dépôts publics sur toutes les offres GitHub actuelles ; les dépôts privés et internes nécessitent GitHub Enterprise Cloud.

Le GitHub CLI vérifie ensuite qui a produit la SBOM et pour quel artefact. Les attestations SBOM nécessitent --predicate-type ; ajoutez --format json pour voir la SBOM elle-même. Pour une image, utilisez oci:// suivi du nom de l'image à la place du chemin de fichier.

gh attestation verify dist/my-app \
  -R OWNER/REPO \
  --predicate-type https://spdx.dev/Document/v2.3

Une attestation prouve qui a produit la SBOM et pour quel artefact. Elle ne rend pas la SBOM plus complète.

4. L'enregistrer pendant le build

CRACI enregistre la SBOM pendant l'exécution du job. Vous passez runs-on à craci :

jobs:
  build:
    runs-on: craci # was: ubuntu-latest

Un proxy qui comprend les paquets, sur le runner, enregistre alors chaque paquet récupéré par le job, y compris les paquets restaurés depuis les caches CI et les dépendances cachées qu'aucun lockfile ne liste, comme le code téléchargé par les scripts d'installation. Il n'y a aucune étape de génération à placer : la question du moment disparaît donc. Chaque SBOM, en CycloneDX ou SPDX, indique sa complétude par job et par cache, et l'API renvoie les SBOM, les traces réseau et la provenance. La mise en place, y compris la GitHub App CRACI et les réglages réseau, est décrite dans la documentation CRACI, et la signification de chaque état de complétude dans la complétude des SBOM de job et de cache.

Laquelle utiliser

• Un inventaire rapide d'un dépôt : l'export du graphe de dépendances.
• Une SBOM d'une image de conteneur : une étape de génération sur l'image.
• La preuve de qui a produit une SBOM pour quel artefact : une attestation, en plus de l'une ou l'autre.
• Un enregistrement de ce que le build a réellement utilisé, pour la réponse aux vulnérabilités ou le Cyber Resilience Act : l'enregistrement au build. Voir le comparatif des outils SBOM.

Les SBOM dans GitHub Actions : questions fréquentes

Comment générer une SBOM dans GitHub Actions ?

Ajoutez une étape de génération après votre étape d'installation. La plus courte est anchore/sbom-action@v0, qui exécute Syft sur l'espace de travail et téléverse une SBOM SPDX JSON comme artefact de workflow. Pour une SBOM signée, transmettez le fichier à actions/attest@v4 avec sbom-path.

GitHub génère-t-il automatiquement une SBOM ?

GitHub peut exporter le graphe de dépendances d'un dépôt sous forme de SBOM SPDX, depuis l'onglet Insights ou l'API REST. Elle décrit les manifestes et les lockfiles du dépôt, et non un build particulier : elle ne montre donc pas les outils ni les paquets qu'un workflow télécharge.

Quelle action génère une SBOM dans GitHub Actions ?

anchore/sbom-action exécute Syft. Par défaut, il scanne le répertoire de l'espace de travail et produit du SPDX JSON ; il peut scanner une image de conteneur à la place, téléverse la SBOM comme artefact de workflow et l'attache aux releases.

De quelles autorisations un workflow SBOM a-t-il besoin ?

anchore/sbom-action demande contents: write, plus actions: read pour attacher la SBOM à une release. La signature avec actions/attest nécessite id-token: write et attestations: write, ainsi que packages: write lorsque l'attestation est poussée vers un registre de conteneurs.

Comment signer une SBOM dans GitHub Actions ?

Utilisez les attestations d'artefacts de GitHub. actions/attest signe une SBOM SPDX ou CycloneDX JSON avec Sigstore et la lie à un artefact ; vérifiez-la avec gh attestation verify. actions/attest-sbom est en cours d'abandon au profit d'actions/attest, qu'il encapsule désormais.

Comment générer une SBOM pour une image de conteneur dans GitHub Actions ?

Transmettez l'image à anchore/sbom-action avec l'entrée image au lieu de path. Pour la signer, donnez à actions/attest le nom et le digest de l'image via subject-name et subject-digest, réglez push-to-registry: true et vérifiez avec gh attestation verify oci://IMAGE.

Le workflow doit-il produire du SPDX ou du CycloneDX ?

Celui qu'attend l'outil qui lit la SBOM. L'export du graphe de dépendances est uniquement en SPDX et cdxgen écrit du CycloneDX. anchore/sbom-action écrit l'un ou l'autre, et actions/attest accepte l'un ou l'autre. Voir CycloneDX vs SPDX.

L'étape SBOM doit-elle s'exécuter avant ou après le build ?

Après l'installation des dépendances, sinon elle les ratera. Même dans ce cas, elle voit ce qui est sur le disque, et non ce que le job a téléchargé puis retiré, ni ce qu'un script a récupéré. Enregistrer pendant le build évite la question du moment.