So erzeugen Sie eine SBOM in GitHub Actions

Vier Ansätze

1. Den Abhängigkeitsgraphen exportieren

GitHub baut aus den Manifesten und Lockfiles eines Repositorys einen Abhängigkeitsgraphen und kann ihn als SPDX-SBOM exportieren. Dafür ist keine Workflow-Änderung nötig: Öffnen Sie im Repository den Tab Insights, wählen Sie Dependency graph und klicken Sie auf Export SBOM. Der Export beschreibt das Repository im Default-Branch, nicht einen bestimmten Build, sodass Tools und Pakete, die ein Workflow installiert, darin fehlen.

Zum Skripten nutzen Sie die REST-API. GET /repos/{owner}/{repo}/dependency-graph/sbom liefert das SPDX-JSON mit einem Aufruf, aber GitHub stellt diesen Endpunkt nach dem 13. November 2026 ein. Der Ersatz arbeitet asynchron: Sie fordern einen Bericht an und rufen dann die zurückgegebene sbom_url ab. Diese URL antwortet mit 202, solange die SBOM erzeugt wird, und leitet dann zur SPDX-JSON-Datei weiter, die GitHub bis zu eine Woche aufbewahrt.

# 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. Einen Generator-Schritt ergänzen

Ein Schritt im Workflow wendet einen Generator auf den Workspace oder ein Image an. anchore/sbom-action führt Syft aus: Standardmäßig scannt es das Workspace-Verzeichnis und gibt SPDX-JSON aus, es kann stattdessen ein Container-Image scannen, und es lädt die SBOM als Workflow-Artefakt hoch und hängt sie an Releases an. Sein README verlangt contents: write sowie actions: read, wenn es die SBOM an ein Release anhängt:

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 akzeptiert spdx, spdx-json, cyclonedx oder cyclonedx-json. Um ein Image zu scannen, ersetzen Sie path durch image, zum Beispiel image: ghcr.io/OWNER/app:1.0. Die eigenen Image-SBOMs von BuildKit finden Sie unter Docker-SBOM.

Trivy und cdxgen lassen sich auf dieselbe Weise als einfache run-Schritte ausführen. cdxgen schreibt CycloneDX; seit Version 13 heißt sein 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

Das Timing ist wichtig. Führen Sie den Schritt aus, nachdem die Abhängigkeiten installiert sind, sonst sieht er sie nicht. Selbst dann sieht ein Generator nur die Dateien, die ihm vorliegen: Ein Paket, das ein Skript heruntergeladen, genutzt und gelöscht hat, oder ein außerhalb eines Paketmanagers installiertes Tool kann fehlen.

3. Als Attestierung signieren

Die Artifact Attestations von GitHub binden eine SBOM an das beschriebene Artefakt und signieren sie mit Sigstore. actions/attest@v4 akzeptiert SPDX- oder CycloneDX-JSON über sbom-path, bis zu 16 MB. Ohne sbom-path erzeugt es stattdessen SLSA-Build-Provenienz. actions/attest-sbom wird zugunsten von actions/attest eingestellt, auf dem es inzwischen aufsetzt. Der Job braucht id-token: write, um ein Signaturzertifikat zu erhalten, und attestations: write, um das Ergebnis zu speichern:

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

Übergeben Sie bei einem Container-Image subject-name und subject-digest statt subject-path, setzen Sie push-to-registry: true und ergänzen Sie packages: write. Artifact Attestations funktionieren in öffentlichen Repositories mit jedem aktuellen GitHub-Plan; private und interne Repositories brauchen GitHub Enterprise Cloud.

Die GitHub CLI prüft anschließend, wer die SBOM erzeugt hat und für welches Artefakt. SBOM-Attestierungen brauchen --predicate-type; ergänzen Sie --format json, um die SBOM selbst zu sehen. Verwenden Sie bei einem Image oci:// gefolgt vom Image-Namen anstelle des Dateipfads.

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

Eine Attestierung belegt, wer die SBOM erzeugt hat und für welches Artefakt. Sie macht die SBOM nicht vollständiger.

4. Während des Builds aufzeichnen

CRACI zeichnet die SBOM auf, während der Job läuft. Sie ändern runs-on auf craci:

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

Ein paketbewusster Proxy auf dem Runner zeichnet dann jedes Paket auf, das der Job geladen hat, einschließlich der aus CI-Caches wiederhergestellten Pakete und versteckter Abhängigkeiten, die kein Lockfile auflistet, etwa Code, den Install-Skripte herunterladen. Ein Generator-Schritt muss nicht platziert werden, die Timing-Frage entfällt also. Jede SBOM, als CycloneDX oder SPDX, gibt ihre Vollständigkeit pro Job und pro Cache an, und die API liefert SBOMs, Netzwerk-Traces und Provenienz. Die Einrichtung, einschließlich CRACI GitHub App und Netzwerkeinstellungen, steht in der CRACI-Dokumentation, und was jeder Vollständigkeitsstatus bedeutet, unter SBOM-Vollständigkeit von Jobs und Caches.

Welchen Ansatz Sie wählen sollten

• Ein schnelles Inventar eines Repositorys: der Export des Abhängigkeitsgraphen.
• Eine SBOM eines Container-Images: ein Generator-Schritt für das Image.
• Ein Beleg, wer eine SBOM für welches Artefakt erzeugt hat: eine Attestierung, zusätzlich zu einem der beiden.
• Eine Aufzeichnung dessen, was der Build tatsächlich verwendet hat, für die Reaktion auf Schwachstellen oder den Cyber Resilience Act: die Aufzeichnung zur Build-Zeit. Siehe SBOM-Tools im Vergleich.

SBOMs in GitHub Actions: häufig gestellte Fragen

Wie erzeuge ich eine SBOM in GitHub Actions?

Ergänzen Sie nach dem Installationsschritt einen Generator-Schritt. Am kürzesten geht es mit anchore/sbom-action@v0, das Syft auf dem Workspace ausführt und eine SPDX-JSON-SBOM als Workflow-Artefakt hochlädt. Für eine signierte SBOM übergeben Sie die Datei an actions/attest@v4 mit sbom-path.

Erzeugt GitHub automatisch eine SBOM?

GitHub kann den Abhängigkeitsgraphen eines Repositorys als SPDX-SBOM exportieren, über den Tab Insights oder die REST-API. Sie beschreibt die Manifeste und Lockfiles im Repository, nicht einen bestimmten Build, und zeigt daher keine Tools oder Pakete, die ein Workflow herunterlädt.

Welche Action erzeugt eine SBOM in GitHub Actions?

anchore/sbom-action führt Syft aus. Standardmäßig scannt es das Workspace-Verzeichnis und gibt SPDX-JSON aus; es kann stattdessen ein Container-Image scannen, lädt die SBOM als Workflow-Artefakt hoch und hängt sie an Releases an.

Welche Berechtigungen braucht ein SBOM-Workflow?

anchore/sbom-action verlangt contents: write sowie actions: read, um die SBOM an ein Release anzuhängen. Das Signieren mit actions/attest braucht id-token: write und attestations: write sowie packages: write, wenn die Attestierung in eine Container-Registry gepusht wird.

Wie signiere ich eine SBOM in GitHub Actions?

Nutzen Sie die Artifact Attestations von GitHub. actions/attest signiert eine SBOM in SPDX- oder CycloneDX-JSON mit Sigstore und bindet sie an ein Artefakt; prüfen Sie sie mit gh attestation verify. actions/attest-sbom wird zugunsten von actions/attest eingestellt, auf dem es inzwischen aufsetzt.

Wie erzeuge ich in GitHub Actions eine SBOM für ein Container-Image?

Übergeben Sie das Image mit dem Input image statt path an anchore/sbom-action. Zum Signieren geben Sie actions/attest den Image-Namen und Digest über subject-name und subject-digest, setzen push-to-registry: true und prüfen mit gh attestation verify oci://IMAGE.

Sollte der Workflow SPDX oder CycloneDX erzeugen?

Das Format, das das Tool erwartet, das die SBOM liest. Der Export des Abhängigkeitsgraphen liefert nur SPDX, und cdxgen schreibt CycloneDX. anchore/sbom-action schreibt beides, und actions/attest akzeptiert beides. Siehe CycloneDX vs. SPDX.

Sollte der SBOM-Schritt vor oder nach dem Build laufen?

Nachdem die Abhängigkeiten installiert sind, sonst übersieht er sie. Selbst dann sieht er, was auf der Platte liegt, nicht, was der Job heruntergeladen und entfernt oder was ein Skript geladen hat. Die Aufzeichnung während des Builds umgeht die Timing-Frage.