Så genererar du en SBOM i GitHub Actions

Fyra metoder

1. Exportera beroendegrafen

GitHub bygger en beroendegraf från manifesten och lockfilerna i ett repo och kan exportera den som en SPDX-SBOM. Det kräver ingen ändring i arbetsflödet: öppna repots flik Insights, välj Dependency graph och klicka på Export SBOM. Den beskriver repot på standardgrenen, inte ett visst bygge, så verktyg och paket som ett arbetsflöde installerar finns inte med.

Använd REST-API:t för att skripta det. GET /repos/{owner}/{repo}/dependency-graph/sbom returnerar SPDX JSON i ett enda anrop, men GitHub stänger ner det efter den 13 november 2026. Ersättningen är asynkron: begär en rapport och hämta sedan den sbom_url som returneras. Den URL:en svarar 202 medan SBOM:en genereras och omdirigerar sedan till SPDX JSON-filen, som GitHub sparar i upp till en vecka.

# 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. Lägg till ett generatorsteg

Ett steg i arbetsflödet kör en generator mot arbetsytan eller en avbild. anchore/sbom-action kör Syft: som standard skannar den arbetskatalogen och ger SPDX JSON, den kan skanna en containeravbild i stället, och den laddar upp SBOM:en som en arbetsflödesartefakt och bifogar den till releaser. Dess README ber om contents: write, plus actions: read när den bifogar SBOM:en till 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 accepterar spdx, spdx-json, cyclonedx eller cyclonedx-json. För att skanna en avbild ersätter du path med image, till exempel image: ghcr.io/OWNER/app:1.0. Se Docker SBOM för BuildKits egna SBOM:er för avbilder.

Trivy och cdxgen kan köras på samma sätt, som vanliga run-steg. cdxgen skriver CycloneDX; sedan version 13 heter dess npm-paket @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

Tidpunkten spelar roll. Kör steget efter att beroendena har installerats, annars ser det dem inte. Även då ser en generator bara filerna framför den: ett paket som ett skript laddade ner, använde och tog bort, eller ett verktyg som installerats utanför en pakethanterare, kan saknas.

3. Signera den som en attestering

GitHubs artefaktattesteringar binder en SBOM till artefakten den beskriver och signerar den med Sigstore. actions/attest@v4 tar emot SPDX eller CycloneDX JSON via sbom-path, upp till 16 MB. Utan sbom-path producerar den i stället SLSA-byggproveniens. actions/attest-sbom fasas ut till förmån för actions/attest, som den nu omsluter. Jobbet behöver id-token: write för att få ett signeringscertifikat och attestations: write för att lagra 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

För en containeravbild skickar du subject-name och subject-digest i stället för subject-path, sätter push-to-registry: true och lägger till packages: write. Artefaktattesteringar fungerar i publika repon på alla aktuella GitHub-planer; privata och interna repon kräver GitHub Enterprise Cloud.

GitHub CLI kontrollerar sedan vem som producerade SBOM:en och för vilken artefakt. SBOM-attesteringar behöver --predicate-type; lägg till --format json för att se själva SBOM:en. För en avbild använder du oci:// följt av avbildens namn i stället för filsökvägen.

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

En attestering bevisar vem som producerade SBOM:en och för vilken artefakt. Den gör inte SBOM:en mer komplett.

4. Registrera den under bygget

CRACI registrerar SBOM:en medan jobbet körs. Du ändrar runs-on till craci:

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

En paketmedveten proxy på runnern registrerar sedan varje paket som jobbet hämtade, inklusive paket som återställs från CI-cachar och dolda beroenden som ingen lockfile listar, till exempel kod som laddas ner av installationsskript. Det finns inget generatorsteg att placera, så frågan om tidpunkt försvinner. Varje SBOM, i CycloneDX eller SPDX, anger sin fullständighet per jobb och per cache, och API:t returnerar SBOM:er, nätverksspårningar och proveniens. Konfigurationen, inklusive CRACI GitHub App och nätverksinställningar, finns i CRACI-dokumentationen, och vad varje fullständighetsstatus betyder finns i SBOM-fullständighet för jobb och cachar.

Vilken du ska använda

• En snabb förteckning över ett repo: export av beroendegrafen.
• En SBOM för en containeravbild: ett generatorsteg mot avbilden.
• Bevis på vem som producerade en SBOM för vilken artefakt: en attestering, ovanpå någon av dem.
• En registrering av vad bygget faktiskt använde, för hantering av sårbarheter eller Cyber Resilience Act: registrering under bygget. Se SBOM-verktyg i jämförelse.

SBOM:er i GitHub Actions: vanliga frågor

Hur genererar jag en SBOM i GitHub Actions?

Lägg till ett generatorsteg efter installationssteget. Det kortaste är anchore/sbom-action@v0, som kör Syft på arbetsytan och laddar upp en SBOM i SPDX JSON som en arbetsflödesartefakt. För en signerad SBOM skickar du filen till actions/attest@v4 med sbom-path.

Genererar GitHub en SBOM automatiskt?

GitHub kan exportera ett repos beroendegraf som en SPDX-SBOM, från fliken Insights eller via REST-API:t. Den beskriver manifesten och lockfilerna i repot, inte ett visst bygge, så den visar inte verktyg eller paket som ett arbetsflöde laddar ner.

Vilken action genererar en SBOM i GitHub Actions?

anchore/sbom-action kör Syft. Som standard skannar den arbetskatalogen och ger SPDX JSON; den kan skanna en containeravbild i stället, laddar upp SBOM:en som en arbetsflödesartefakt och bifogar den till releaser.

Vilka behörigheter behöver ett SBOM-arbetsflöde?

anchore/sbom-action ber om contents: write, plus actions: read för att bifoga SBOM:en till en release. Signering med actions/attest kräver id-token: write och attestations: write, och packages: write när attesteringen pushas till ett containerregister.

Hur signerar jag en SBOM i GitHub Actions?

Använd GitHubs artefaktattesteringar. actions/attest signerar en SBOM i SPDX eller CycloneDX JSON med Sigstore och binder den till en artefakt; verifiera den med gh attestation verify. actions/attest-sbom fasas ut till förmån för actions/attest, som den nu omsluter.

Hur genererar jag en SBOM för en containeravbild i GitHub Actions?

Skicka avbilden till anchore/sbom-action med indata image i stället för path. För att signera den ger du actions/attest avbildens namn och digest via subject-name och subject-digest, sätter push-to-registry: true och verifierar med gh attestation verify oci://IMAGE.

Ska arbetsflödet producera SPDX eller CycloneDX?

Det som verktyget som läser SBOM:en förväntar sig. Exporten av beroendegrafen är enbart SPDX och cdxgen skriver CycloneDX. anchore/sbom-action skriver båda, och actions/attest tar emot båda. Se CycloneDX vs SPDX.

Ska SBOM-steget köras före eller efter bygget?

Efter att beroendena har installerats, annars missar det dem. Även då ser det vad som finns på disken, inte vad jobbet laddade ner och tog bort, eller vad ett skript hämtade. Registrering under bygget undviker frågan om tidpunkt.