Sådan genererer du en SBOM i GitHub Actions

Fire tilgange

1. Eksportér afhængighedsgrafen

GitHub bygger en afhængighedsgraf ud fra manifesterne og lockfilerne i et repository og kan eksportere den som en SPDX-SBOM. Det kræver ingen ændring af workflowet: Åbn repositoriets fane Insights, vælg Dependency graph, og klik på Export SBOM. Den beskriver repositoriet på default-branchen, ikke et bestemt build, så værktøjer og pakker, som et workflow installerer, er ikke med.

Vil du scripte det, så brug REST API'et. GET /repos/{owner}/{repo}/dependency-graph/sbom returnerer SPDX JSON i ét kald, men GitHub lukker det efter 13. november 2026. Afløseren er asynkron: Anmod om en rapport, og hent derefter den sbom_url, den returnerer. Den URL svarer 202, mens SBOM'en genereres, og omdirigerer derefter til SPDX JSON-filen, som GitHub gemmer i op til en uge.

# 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. Tilføj et generatortrin

Et trin i workflowet kører en generator mod workspacet eller et image. anchore/sbom-action kører Syft: Som standard scanner den workspace-mappen og giver SPDX JSON som output, den kan i stedet scanne et container-image, og den uploader SBOM'en som et workflow-artefakt og vedhæfter den til releases. Dens README beder om contents: write plus actions: read, når den vedhæfter SBOM'en til en 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 tager spdx, spdx-json, cyclonedx eller cyclonedx-json. For at scanne et image erstatter du path med image, for eksempel image: ghcr.io/OWNER/app:1.0. Se Docker-SBOM for BuildKits egne image-SBOM'er.

Trivy og cdxgen kan køres på samme måde, som almindelige run-trin. cdxgen skriver CycloneDX; siden version 13 hedder dens npm-pakke @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

Timingen betyder noget. Kør trinnet, efter at afhængighederne er installeret, ellers ser det dem ikke. Selv da ser en generator de filer, den har foran sig: En pakke, som et script downloadede, brugte og slettede, eller et værktøj installeret uden for en pakkehåndtering, kan mangle.

3. Signér den som en attestation

GitHubs artifact attestations binder en SBOM til det artefakt, den beskriver, og signerer den med Sigstore. actions/attest@v4 accepterer SPDX eller CycloneDX JSON via sbom-path, op til 16 MB. Uden sbom-path producerer den i stedet SLSA build provenance. actions/attest-sbom er ved at blive udfaset til fordel for actions/attest, som den nu pakker ind. Jobbet har brug for id-token: write for at få et signeringscertifikat og attestations: write for at gemme resultatet:

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

For et container-image angiver du subject-name og subject-digest i stedet for subject-path, sætter push-to-registry: true og tilføjer packages: write. Artifact attestations virker i offentlige repositories på alle aktuelle GitHub-planer; private og interne repositories kræver GitHub Enterprise Cloud.

GitHub CLI tjekker derefter, hvem der producerede SBOM'en, og for hvilket artefakt. SBOM-attestationer kræver --predicate-type; tilføj --format json for at se selve SBOM'en. For et image bruger du oci:// efterfulgt af imagets navn i stedet for filstien.

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

En attestation beviser, hvem der producerede SBOM'en, og for hvilket artefakt. Den gør ikke SBOM'en mere komplet.

4. Registrér den under buildet

CRACI registrerer SBOM'en, mens jobbet kører. Du ændrer runs-on til craci:

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

En pakkebevidst proxy på runneren registrerer derefter hver pakke, jobbet hentede, inklusive pakker gendannet fra CI-caches og skjulte afhængigheder, som ingen lockfile angiver, for eksempel kode downloadet af install-scripts. Der er intet generatortrin at placere, så spørgsmålet om timing forsvinder. Hver SBOM, i CycloneDX eller SPDX, angiver sin fuldstændighed pr. job og pr. cache, og API'et returnerer SBOM'er, netværkstraces og provenance. Opsætningen, inklusive CRACI GitHub App og netværksindstillinger, står i CRACI-dokumentationen, og hvad hver fuldstændighedsstatus betyder, står i SBOM-fuldstændighed for jobs og caches.

Hvilken du skal bruge

• En hurtig fortegnelse over et repository: eksport af afhængighedsgrafen.
• En SBOM for et container-image: et generatortrin mod imaget.
• Bevis for, hvem der producerede en SBOM for hvilket artefakt: en attestation oven på en af delene.
• En registrering af, hvad buildet faktisk brugte, til sårbarhedsrespons eller Cyber Resilience Act: registrering under buildet. Se SBOM-værktøjer sammenlignet.

SBOM'er i GitHub Actions: ofte stillede spørgsmål

Hvordan genererer jeg en SBOM i GitHub Actions?

Tilføj et generatortrin efter dit installationstrin. Det korteste er anchore/sbom-action@v0, som kører Syft på workspacet og uploader en SPDX JSON-SBOM som et workflow-artefakt. For en signeret SBOM giver du filen til actions/attest@v4 med sbom-path.

Genererer GitHub automatisk en SBOM?

GitHub kan eksportere et repositorys afhængighedsgraf som en SPDX-SBOM fra Insights-fanen eller via REST API'et. Den beskriver manifesterne og lockfilerne i repositoriet, ikke et bestemt build, så den viser ikke værktøjer eller pakker, som et workflow downloader.

Hvilken action genererer en SBOM i GitHub Actions?

anchore/sbom-action kører Syft. Som standard scanner den workspace-mappen og giver SPDX JSON som output; den kan i stedet scanne et container-image, uploader SBOM'en som et workflow-artefakt og vedhæfter den til releases.

Hvilke rettigheder har et SBOM-workflow brug for?

anchore/sbom-action beder om contents: write plus actions: read for at vedhæfte SBOM'en til en release. Signering med actions/attest kræver id-token: write og attestations: write samt packages: write, når attestationen pushes til et container-registry.

Hvordan signerer jeg en SBOM i GitHub Actions?

Brug GitHubs artifact attestations. actions/attest signerer en SPDX- eller CycloneDX JSON-SBOM med Sigstore og binder den til et artefakt; verificér den med gh attestation verify. actions/attest-sbom er ved at blive udfaset til fordel for actions/attest, som den nu pakker ind.

Hvordan genererer jeg en SBOM for et container-image i GitHub Actions?

Giv imaget til anchore/sbom-action med inputtet image i stedet for path. For at signere den giver du actions/attest imagets navn og digest via subject-name og subject-digest, sætter push-to-registry: true og verificerer med gh attestation verify oci://IMAGE.

Skal workflowet producere SPDX eller CycloneDX?

Det format, som værktøjet, der læser SBOM'en, forventer. Eksporten af afhængighedsgrafen er kun SPDX, og cdxgen skriver CycloneDX. anchore/sbom-action skriver begge, og actions/attest accepterer begge. Se CycloneDX vs SPDX.

Skal SBOM-trinnet køre før eller efter buildet?

Efter at afhængighederne er installeret, ellers overser det dem. Selv da ser det kun, hvad der er på disken, ikke hvad jobbet downloadede og fjernede, eller hvad et script hentede. Registrering under buildet undgår spørgsmålet om timing.