Zo genereert u een SBOM in GitHub Actions

Vier aanpakken

1. Exporteer de dependency graph

GitHub bouwt een dependency graph op uit de manifests en lockfiles in een repository en kan die als SPDX-SBOM exporteren. Er is geen wijziging in de workflow nodig: open het tabblad Insights van de repository, kies Dependency graph en klik op Export SBOM. De export beschrijft de repository op de standaardbranch, niet een bepaalde build, dus tools en pakketten die een workflow installeert, staan er niet in.

Om dit te scripten, gebruikt u de REST API. GET /repos/{owner}/{repo}/dependency-graph/sbom geeft de SPDX JSON in één aanroep terug, maar GitHub stelt dit na 13 november 2026 buiten gebruik. De vervanging is asynchroon: u vraagt een rapport aan en haalt daarna de sbom_url op die wordt teruggegeven. Die URL antwoordt met 202 terwijl de SBOM wordt gegenereerd, en verwijst daarna door naar het SPDX JSON-bestand, dat GitHub maximaal een week bewaart.

# 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. Voeg een generatorstap toe

Een stap in de workflow draait een generator op de workspace of een image. anchore/sbom-action draait Syft: standaard scant het de workspacemap en levert het SPDX JSON op, het kan in plaats daarvan een containerimage scannen, en het uploadt de SBOM als workflowartefact en voegt hem toe aan releases. De README vraagt om contents: write, plus actions: read wanneer de SBOM aan een release wordt toegevoegd:

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 accepteert spdx, spdx-json, cyclonedx of cyclonedx-json. Om een image te scannen, vervangt u path door image, bijvoorbeeld image: ghcr.io/OWNER/app:1.0. Zie Docker-SBOM voor de eigen image-SBOM's van BuildKit.

Trivy en cdxgen kunnen op dezelfde manier worden uitgevoerd, als gewone run-stappen. cdxgen schrijft CycloneDX; sinds versie 13 is het npm-pakket @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

De timing is belangrijk. Draai de stap nadat de afhankelijkheden zijn geïnstalleerd, anders ziet hij ze niet. Zelfs dan ziet een generator alleen de bestanden die hij voor zich heeft: een pakket dat een script heeft gedownload, gebruikt en verwijderd, of een tool die buiten een pakketbeheerder om is geïnstalleerd, kan ontbreken.

3. Onderteken hem als attestatie

De artifact attestations van GitHub koppelen een SBOM aan het artefact dat hij beschrijft en ondertekenen hem met Sigstore. actions/attest@v4 accepteert SPDX of CycloneDX JSON via sbom-path, tot 16 MB. Zonder sbom-path levert het in plaats daarvan SLSA-buildherkomst op. actions/attest-sbom wordt afgeschaft ten gunste van actions/attest, waar het nu een wrapper om is. De job heeft id-token: write nodig om een ondertekeningscertificaat te krijgen en attestations: write om het resultaat op te slaan:

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

Geef voor een containerimage subject-name en subject-digest door in plaats van subject-path, stel push-to-registry: true in en voeg packages: write toe. Artifact attestations werken in openbare repositories bij elk huidig GitHub-plan; privé- en interne repositories hebben GitHub Enterprise Cloud nodig.

De GitHub CLI controleert vervolgens wie de SBOM heeft gemaakt en voor welk artefact. SBOM-attestaties hebben --predicate-type nodig; voeg --format json toe om de SBOM zelf te zien. Gebruik voor een image oci:// gevolgd door de imagenaam in plaats van het bestandspad.

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

Een attestatie bewijst wie de SBOM heeft gemaakt en voor welk artefact. Ze maakt de SBOM niet completer.

4. Leg hem vast tijdens de build

CRACI legt de SBOM vast terwijl de job draait. U wijzigt runs-on in craci:

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

Een proxy op de runner die pakketten herkent, legt vervolgens elk pakket vast dat de job heeft opgehaald, inclusief pakketten die uit CI-caches zijn teruggezet en verborgen afhankelijkheden die in geen enkele lockfile staan, zoals code die door installatiescripts is gedownload. Er is geen generatorstap om te plaatsen, dus de timingvraag verdwijnt. Elke SBOM, in CycloneDX of SPDX, vermeldt de volledigheid per job en per cache, en de API levert SBOM's, netwerktraces en herkomstgegevens. De installatie, inclusief de CRACI GitHub App en de netwerkinstellingen, staat in de CRACI-documentatie, en wat elke volledigheidsstatus betekent, staat in SBOM-volledigheid van jobs en caches.

Welke aanpak u kiest

• Een snelle inventaris van een repository: de export van de dependency graph.
• Een SBOM van een containerimage: een generatorstap op de image.
• Bewijs van wie een SBOM voor welk artefact heeft gemaakt: een attestatie, boven op een van beide.
• Een record van wat de build daadwerkelijk heeft gebruikt, voor de afhandeling van kwetsbaarheden of de Cyber Resilience Act: vastleggen tijdens de build. Zie SBOM-tools vergeleken.

SBOM's in GitHub Actions: veelgestelde vragen

Hoe genereer ik een SBOM in GitHub Actions?

Voeg na uw installatiestap een generatorstap toe. De kortste manier is anchore/sbom-action@v0, dat Syft op de workspace draait en een SPDX JSON-SBOM als workflowartefact uploadt. Voor een ondertekende SBOM geeft u het bestand aan actions/attest@v4 door met sbom-path.

Genereert GitHub automatisch een SBOM?

GitHub kan de dependency graph van een repository als SPDX-SBOM exporteren, via het tabblad Insights of de REST API. Die beschrijft de manifests en lockfiles in de repository, niet een bepaalde build, dus hij toont geen tools of pakketten die een workflow downloadt.

Welke action genereert een SBOM in GitHub Actions?

anchore/sbom-action draait Syft. Standaard scant het de workspacemap en levert het SPDX JSON op; het kan in plaats daarvan een containerimage scannen, uploadt de SBOM als workflowartefact en voegt hem toe aan releases.

Welke rechten heeft een SBOM-workflow nodig?

anchore/sbom-action vraagt om contents: write, plus actions: read om de SBOM aan een release toe te voegen. Ondertekenen met actions/attest vereist id-token: write en attestations: write, en packages: write wanneer de attestatie naar een containerregistry wordt gepusht.

Hoe onderteken ik een SBOM in GitHub Actions?

Gebruik de artifact attestations van GitHub. actions/attest ondertekent een SPDX- of CycloneDX JSON-SBOM met Sigstore en koppelt die aan een artefact; verifieer met gh attestation verify. actions/attest-sbom wordt afgeschaft ten gunste van actions/attest, waar het nu een wrapper om is.

Hoe genereer ik een SBOM voor een containerimage in GitHub Actions?

Geef de image aan anchore/sbom-action door met de invoer image in plaats van path. Om hem te ondertekenen, geeft u actions/attest de imagenaam en digest via subject-name en subject-digest, stelt u push-to-registry: true in en verifieert u met gh attestation verify oci://IMAGE.

Moet de workflow SPDX of CycloneDX opleveren?

Wat de tool verwacht die de SBOM leest. De export van de dependency graph is alleen SPDX en cdxgen schrijft CycloneDX. anchore/sbom-action schrijft beide, en actions/attest accepteert beide. Zie CycloneDX vs SPDX.

Moet de SBOM-stap vóór of na de build draaien?

Nadat de afhankelijkheden zijn geïnstalleerd, anders mist hij ze. Zelfs dan ziet hij wat er op schijf staat, niet wat de job heeft gedownload en verwijderd, of wat een script heeft opgehaald. Vastleggen tijdens de build voorkomt de timingvraag.