Slik genererer du en SBOM i GitHub Actions

Fire tilnærminger

1. Eksporter avhengighetsgrafen

GitHub bygger en avhengighetsgraf ut fra manifestene og lockfilene i et repositorium og kan eksportere den som en SPDX-SBOM. Det krever ingen endring i workflowen: Åpne fanen Insights i repositoriet, velg Dependency graph og klikk på Export SBOM. Den beskriver repositoriet på standardgrenen, ikke et bestemt bygg, så verktøy og pakker som en workflow installerer, er ikke med.

For å skripte det bruker du REST-API-et. GET /repos/{owner}/{repo}/dependency-graph/sbom returnerer SPDX JSON i ett kall, men GitHub stenger det etter 13. november 2026. Erstatningen er asynkron: Be om en rapport, og hent deretter sbom_url den returnerer. Den URL-en svarer 202 mens SBOM-en genereres, og videresender deretter til SPDX JSON-filen, som GitHub beholder i opptil en uke.

# 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. Legg til et generatorsteg

Et steg i workflowen kjører en generator mot arbeidsområdet eller et image. anchore/sbom-action kjører Syft: Som standard skanner den arbeidskatalogen og gir SPDX JSON, den kan skanne et container-image i stedet, og den laster opp SBOM-en som en workflow-artefakt og knytter den til utgivelser. README-filen ber om contents: write, pluss actions: read når den knytter SBOM-en til en utgivelse:

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 tar spdx, spdx-json, cyclonedx eller cyclonedx-json. For å skanne et image bytter du ut 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 kjøres på samme måte, som vanlige run-steg. cdxgen skriver CycloneDX; siden versjon 13 er npm-pakken @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

Tidspunktet er viktig. Kjør steget etter at avhengighetene er installert, ellers ser det dem ikke. Selv da ser en generator bare filene den har foran seg: En pakke et skript lastet ned, brukte og slettet, eller et verktøy installert utenfor en pakkebehandler, kan mangle.

3. Signer den som en attestasjon

GitHubs artefaktattestasjoner binder en SBOM til artefakten den beskriver, og signerer den med Sigstore. actions/attest@v4 godtar SPDX eller CycloneDX JSON gjennom sbom-path, opptil 16 MB. Uten sbom-path produserer den SLSA build provenance i stedet. actions/attest-sbom fases ut til fordel for actions/attest, som den nå pakker inn. Jobben trenger id-token: write for å få et signeringssertifikat og attestations: write for å lagre 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 sender du subject-name og subject-digest i stedet for subject-path, setter push-to-registry: true og legger til packages: write. Artefaktattestasjoner fungerer i offentlige repositorier på alle gjeldende GitHub-planer; private og interne repositorier krever GitHub Enterprise Cloud.

GitHub CLI sjekker deretter hvem som produserte SBOM-en, og for hvilken artefakt. SBOM-attestasjoner krever --predicate-type; legg til --format json for å se selve SBOM-en. For et image bruker du oci:// fulgt av image-navnet i stedet for filstien.

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

En attestasjon beviser hvem som produserte SBOM-en, og for hvilken artefakt. Den gjør ikke SBOM-en mer fullstendig.

4. Registrer den under bygget

CRACI registrerer SBOM-en mens jobben kjører. Du endrer runs-on til craci:

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

En pakkebevisst proxy på runneren registrerer deretter hver pakke jobben hentet, inkludert pakker gjenopprettet fra CI-cacher og skjulte avhengigheter som ingen lockfile lister opp, for eksempel kode lastet ned av installasjonsskript. Det er ikke noe generatorsteg å plassere, så spørsmålet om tidspunkt forsvinner. Hver SBOM, i CycloneDX eller SPDX, angir fullstendigheten per jobb og per cache, og API-et returnerer SBOM-er, nettverksspor og provenance. Oppsettet, inkludert CRACI GitHub App og nettverksinnstillinger, står i CRACI-dokumentasjonen, og hva hver fullstendighetsstatus betyr, står i SBOM-fullstendighet for jobber og cacher.

Hvilken du bør bruke

• En rask oversikt over et repositorium: eksport av avhengighetsgrafen.
• En SBOM av et container-image: et generatorsteg mot imaget.
• Bevis på hvem som produserte en SBOM for hvilken artefakt: en attestasjon, oppå en av de to.
• En registrering av hva bygget faktisk brukte, for håndtering av sårbarheter eller Cyber Resilience Act: registrering under bygget. Se SBOM-verktøy sammenlignet.

SBOM-er i GitHub Actions: ofte stilte spørsmål

Hvordan genererer jeg en SBOM i GitHub Actions?

Legg til et generatorsteg etter installasjonssteget. Det korteste er anchore/sbom-action@v0, som kjører Syft på arbeidsområdet og laster opp en SPDX JSON-SBOM som en workflow-artefakt. For en signert SBOM gir du filen til actions/attest@v4 med sbom-path.

Genererer GitHub en SBOM automatisk?

GitHub kan eksportere avhengighetsgrafen til et repositorium som en SPDX-SBOM, fra fanen Insights eller via REST-API-et. Den beskriver manifestene og lockfilene i repositoriet, ikke et bestemt bygg, så den viser ikke verktøy eller pakker en workflow laster ned.

Hvilken action genererer en SBOM i GitHub Actions?

anchore/sbom-action kjører Syft. Som standard skanner den arbeidskatalogen og gir SPDX JSON; den kan skanne et container-image i stedet, laster opp SBOM-en som en workflow-artefakt og knytter den til utgivelser.

Hvilke tillatelser trenger en SBOM-workflow?

anchore/sbom-action ber om contents: write, pluss actions: read for å knytte SBOM-en til en utgivelse. Signering med actions/attest krever id-token: write og attestations: write, og packages: write når attestasjonen pushes til et containerregister.

Hvordan signerer jeg en SBOM i GitHub Actions?

Bruk GitHubs artefaktattestasjoner. actions/attest signerer en SPDX- eller CycloneDX JSON-SBOM med Sigstore og binder den til en artefakt; verifiser den med gh attestation verify. actions/attest-sbom fases ut til fordel for actions/attest, som den nå pakker inn.

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

Gi imaget til anchore/sbom-action med input-en image i stedet for path. For å signere det gir du actions/attest image-navnet og digesten gjennom subject-name og subject-digest, setter push-to-registry: true og verifiserer med gh attestation verify oci://IMAGE.

Bør workflowen produsere SPDX eller CycloneDX?

Det verktøyet som leser SBOM-en, forventer. Eksporten av avhengighetsgrafen er bare SPDX, og cdxgen skriver CycloneDX. anchore/sbom-action skriver begge, og actions/attest godtar begge. Se CycloneDX vs. SPDX.

Bør SBOM-steget kjøre før eller etter bygget?

Etter at avhengighetene er installert, ellers går det glipp av dem. Selv da ser det hva som ligger på disken, ikke hva jobben lastet ned og fjernet, eller hva et skript hentet. Registrering under bygget unngår spørsmålet om tidspunkt.