Jak vygenerovat SBOM v GitHub Actions

Čtyři přístupy

1. Exportujte graf závislostí

GitHub sestavuje graf závislostí z manifestů a lockfilů v repozitáři a umí ho exportovat jako SBOM ve formátu SPDX. Nevyžaduje žádnou změnu workflow: otevřete v repozitáři kartu Insights, zvolte Dependency graph a klikněte na Export SBOM. Popisuje repozitář ve výchozí větvi, ne konkrétní build, takže nástroje a balíčky, které workflow instaluje, v něm nejsou.

Pro skriptování použijte REST API. GET /repos/{owner}/{repo}/dependency-graph/sbom vrátí SPDX JSON jedním voláním, GitHub ho ale po 13. listopadu 2026 ruší. Náhrada je asynchronní: vyžádejte si report a pak stáhněte sbom_url, který vrátí. Tato URL odpovídá kódem 202, dokud se SBOM generuje, a pak přesměruje na soubor SPDX JSON, který GitHub uchovává až týden.

# 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. Přidejte krok generátoru

Krok ve workflow spustí generátor nad pracovním adresářem nebo nad image. anchore/sbom-action spouští Syft: ve výchozím nastavení skenuje pracovní adresář a vypisuje SPDX JSON, místo toho umí skenovat image kontejneru a SBOM nahrává jako artefakt workflow a připojuje ji k vydáním. Jeho README vyžaduje contents: write a navíc actions: read, když SBOM připojuje k vydání:

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 přijímá spdx, spdx-json, cyclonedx nebo cyclonedx-json. Chcete-li skenovat image, nahraďte path za image, například image: ghcr.io/OWNER/app:1.0. Vlastní SBOM pro image z BuildKitu popisuje stránka SBOM pro Docker.

Trivy a cdxgen lze spustit stejně, jako běžné kroky run. cdxgen zapisuje CycloneDX; od verze 13 je jeho balíček npm @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

Záleží na načasování. Spusťte krok až po instalaci závislostí, jinak je neuvidí. I pak generátor vidí jen soubory, které má před sebou: balíček, který skript stáhl, použil a smazal, nebo nástroj nainstalovaný mimo správce balíčků mohou chybět.

3. Podepište ji jako atestaci

Atestace artefaktů na GitHubu svazují SBOM s artefaktem, který popisuje, a podepisují ji pomocí Sigstore. actions/attest@v4 přijímá SPDX nebo CycloneDX JSON přes sbom-path, až do 16 MB. Bez sbom-path místo toho vytvoří původ buildu podle SLSA. actions/attest-sbom se ruší ve prospěch actions/attest, který nyní obaluje. Job potřebuje id-token: write k získání podpisového certifikátu a attestations: write k uložení výsledku:

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

U image kontejneru předejte subject-name a subject-digest místo subject-path, nastavte push-to-registry: true a přidejte packages: write. Atestace artefaktů fungují ve veřejných repozitářích ve všech současných plánech GitHubu; soukromé a interní repozitáře vyžadují GitHub Enterprise Cloud.

GitHub CLI pak ověří, kdo SBOM vytvořil a pro jaký artefakt. Atestace SBOM vyžadují --predicate-type; přidejte --format json, chcete-li vidět samotnou SBOM. U image použijte místo cesty k souboru oci:// následované názvem image.

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

Atestace dokazuje, kdo SBOM vytvořil a pro jaký artefakt. SBOM tím ale úplnější nebude.

4. Zaznamenejte ji během buildu

CRACI zaznamenává SBOM, zatímco job běží. Stačí změnit runs-on na craci:

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

Proxy na runneru, která rozumí balíčkům, pak zaznamená každý balíček, který job stáhl, včetně balíčků obnovených z cache CI a skrytých závislostí, které neuvádí žádný lockfile, například kódu staženého instalačními skripty. Není kam umisťovat krok generátoru, takže otázka načasování odpadá. Každá SBOM ve formátu CycloneDX nebo SPDX uvádí svou úplnost pro každý job a každou cache a API vrací SBOM, síťové záznamy a údaje o původu. Nastavení, včetně aplikace CRACI GitHub App a síťových nastavení, najdete v dokumentaci CRACI a co který stav úplnosti znamená, popisuje stránka úplnost SBOM jobů a cache.

Který přístup zvolit

• Rychlý inventář repozitáře: export grafu závislostí.
• SBOM image kontejneru: krok generátoru nad image.
• Doklad o tom, kdo vytvořil SBOM pro jaký artefakt: atestace, nad kterýmkoli z nich.
• Záznam toho, co build skutečně použil, pro reakci na zranitelnosti nebo pro Cyber Resilience Act: záznam během buildu. Viz srovnání nástrojů SBOM.

SBOM v GitHub Actions: časté dotazy

Jak vygeneruji SBOM v GitHub Actions?

Přidejte krok generátoru za krok instalace. Nejkratší cestou je anchore/sbom-action@v0, který spustí Syft nad pracovním adresářem a nahraje SBOM ve formátu SPDX JSON jako artefakt workflow. Pro podepsanou SBOM předejte soubor do actions/attest@v4 přes sbom-path.

Generuje GitHub SBOM automaticky?

GitHub umí exportovat graf závislostí repozitáře jako SBOM ve formátu SPDX, z karty Insights nebo přes REST API. Popisuje manifesty a lockfily v repozitáři, ne konkrétní build, takže v něm neuvidíte nástroje ani balíčky, které workflow stahuje.

Která action generuje SBOM v GitHub Actions?

anchore/sbom-action spouští Syft. Ve výchozím nastavení skenuje pracovní adresář a vypisuje SPDX JSON; místo toho umí skenovat image kontejneru, SBOM nahrává jako artefakt workflow a připojuje ji k vydáním.

Jaká oprávnění workflow pro SBOM potřebuje?

anchore/sbom-action vyžaduje contents: write a navíc actions: read k připojení SBOM k vydání. Podepisování pomocí actions/attest potřebuje id-token: write a attestations: write a také packages: write, když se atestace odesílá do registru kontejnerů.

Jak podepíšu SBOM v GitHub Actions?

Použijte atestace artefaktů na GitHubu. actions/attest podepíše SBOM ve formátu SPDX nebo CycloneDX JSON pomocí Sigstore a sváže ji s artefaktem; ověříte ji příkazem gh attestation verify. actions/attest-sbom se ruší ve prospěch actions/attest, který nyní obaluje.

Jak vygeneruji SBOM pro image kontejneru v GitHub Actions?

Předejte image do anchore/sbom-action přes vstup image místo path. K podepsání předejte actions/attest název a digest image přes subject-name a subject-digest, nastavte push-to-registry: true a ověřte příkazem gh attestation verify oci://IMAGE.

Má workflow vytvářet SPDX, nebo CycloneDX?

Ten formát, který očekává nástroj, jenž SBOM čte. Export grafu závislostí je pouze v SPDX a cdxgen zapisuje CycloneDX. anchore/sbom-action zapisuje oba a actions/attest přijímá oba. Viz CycloneDX vs SPDX.

Má krok SBOM běžet před buildem, nebo po něm?

Až po instalaci závislostí, jinak je přehlédne. I pak vidí jen to, co je na disku, ne to, co job stáhl a odstranil, ani to, co stáhl skript. Záznam během buildu otázku načasování odstraňuje.