Näin generoit SBOM:n GitHub Actionsissa

Neljä lähestymistapaa

1. Vie riippuvuusgraafi

GitHub rakentaa riippuvuusgraafin repositorion manifesteista ja lukitustiedostoista (lockfile) ja voi viedä sen SPDX-SBOM:ina. Se ei vaadi muutoksia työnkulkuun: avaa repositorion Insights-välilehti, valitse Dependency graph ja napsauta Export SBOM. Se kuvaa repositoriota oletushaarassa, ei tiettyä buildia, joten työnkulun asentamat työkalut ja paketit eivät ole siinä mukana.

Skriptausta varten käytä REST-API:a. GET /repos/{owner}/{repo}/dependency-graph/sbom palauttaa SPDX JSONin yhdellä kutsulla, mutta GitHub poistaa sen käytöstä 13.11.2026 jälkeen. Korvaaja on asynkroninen: pyydä raportti ja hae sitten sen palauttama sbom_url. Osoite vastaa 202, kun SBOM:ia generoidaan, ja ohjaa sitten SPDX JSON -tiedostoon, jota GitHub säilyttää enintään viikon.

# 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. Lisää generaattorivaihe

Työnkulun vaihe ajaa generaattorin työtilaa tai kuvaa vasten. anchore/sbom-action ajaa Syftiä: oletuksena se skannaa työtilan hakemiston ja tuottaa SPDX JSONia, se voi skannata sen sijaan konttikuvan, ja se lataa SBOM:n työnkulun artefaktiksi ja liittää sen julkaisuihin. Sen README pyytää oikeutta contents: write sekä oikeutta actions: read, kun se liittää SBOM:n julkaisuun:

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 hyväksyy arvot spdx, spdx-json, cyclonedx tai cyclonedx-json. Jos haluat skannata kuvan, korvaa path parametrilla image, esimerkiksi image: ghcr.io/OWNER/app:1.0. BuildKitin omista kuva-SBOM:eista kerrotaan sivulla Docker-SBOM.

Trivyn ja cdxgenin voi ajaa samalla tavalla, tavallisina run-vaiheina. cdxgen kirjoittaa CycloneDX:ää; versiosta 13 lähtien sen npm-paketti on @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

Ajoitus on tärkeä. Aja vaihe vasta, kun riippuvuudet on asennettu, muuten se ei näe niitä. Silloinkin generaattori näkee vain edessään olevat tiedostot: skriptin lataama, käyttämä ja poistama paketti tai paketinhallinnan ulkopuolella asennettu työkalu voi puuttua.

3. Allekirjoita se attestaationa

GitHubin artefaktiattestaatiot sitovat SBOM:n kuvaamaansa artefaktiin ja allekirjoittavat sen Sigstorella. actions/attest@v4 hyväksyy SPDX- tai CycloneDX-JSONin parametrilla sbom-path, enintään 16 Mt. Ilman parametria sbom-path se tuottaa sen sijaan SLSA-buildin alkuperätiedot. actions/attest-sbom on poistumassa käytöstä actions/attestin hyväksi, jota se nykyään käärii. Jobi tarvitsee oikeuden id-token: write saadakseen allekirjoitusvarmenteen ja oikeuden attestations: write tuloksen tallentamiseen:

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

Konttikuvalle anna subject-name ja subject-digest parametrin subject-path sijaan, aseta push-to-registry: true ja lisää packages: write. Artefaktiattestaatiot toimivat julkisissa repositorioissa kaikilla nykyisillä GitHubin paketeilla; yksityiset ja sisäiset repositoriot edellyttävät GitHub Enterprise Cloudia.

GitHub CLI tarkistaa sitten, kuka SBOM:n tuotti ja mille artefaktille. SBOM-attestaatiot vaativat parametrin --predicate-type; lisää --format json nähdäksesi itse SBOM:n. Kuvalle käytä tiedostopolun tilalla oci:// ja sen perään kuvan nimeä.

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

Attestaatio todistaa, kuka SBOM:n tuotti ja mille artefaktille. Se ei tee SBOM:sta kattavampaa.

4. Tallenna se buildin aikana

CRACI tallentaa SBOM:n jobin ajon aikana. Vaihdat runs-on-arvoksi craci:

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

Runnerilla toimiva paketit tunnistava välityspalvelin (proxy) tallentaa sitten jokaisen paketin, jonka jobi haki, myös CI-välimuisteista palautetut paketit ja piilotetut riippuvuudet, joita mikään lukitustiedosto ei listaa, kuten asennusskriptien lataaman koodin. Generaattorivaihetta ei tarvitse sijoittaa mihinkään, joten ajoituskysymys katoaa. Jokainen SBOM, CycloneDX- tai SPDX-muodossa, ilmoittaa kattavuutensa jobeittain ja välimuisteittain, ja API palauttaa SBOM:t, verkkojäljet ja alkuperätiedot. Käyttöönotto, mukaan lukien CRACI GitHub App ja verkkoasetukset, on kuvattu CRACI:n dokumentaatiossa, ja kunkin kattavuustilan merkitys sivulla job and cache SBOM completeness.

Minkä valita

• Nopea inventaario repositoriosta: riippuvuusgraafin vienti.
• Konttikuvan SBOM: generaattorivaihe kuvaa vasten.
• Todiste siitä, kuka tuotti SBOM:n mille artefaktille: attestaatio jommankumman päälle.
• Kirjaus siitä, mitä buildi todella käytti, haavoittuvuuksiin reagointia tai EU:n kyberkestävyyssäädöstä (Cyber Resilience Act, CRA) varten: buildin aikainen tallennus. Katso SBOM-työkalut vertailussa.

SBOM:t GitHub Actionsissa: usein kysytyt kysymykset

Miten generoin SBOM:n GitHub Actionsissa?

Lisää generaattorivaihe asennusvaiheen jälkeen. Lyhin tapa on anchore/sbom-action@v0, joka ajaa Syftin työtilaa vasten ja lataa SPDX JSON -SBOM:n työnkulun artefaktiksi. Allekirjoitettua SBOM:ia varten anna tiedosto toiminnolle actions/attest@v4 parametrilla sbom-path.

Generoiko GitHub SBOM:n automaattisesti?

GitHub voi viedä repositorion riippuvuusgraafin SPDX-SBOM:ina Insights-välilehdeltä tai REST-API:n kautta. Se kuvaa repositorion manifesteja ja lukitustiedostoja, ei tiettyä buildia, joten siinä eivät näy työnkulun lataamat työkalut tai paketit.

Mikä action generoi SBOM:n GitHub Actionsissa?

anchore/sbom-action ajaa Syftiä. Oletuksena se skannaa työtilan hakemiston ja tuottaa SPDX JSONia; se voi skannata sen sijaan konttikuvan, lataa SBOM:n työnkulun artefaktiksi ja liittää sen julkaisuihin.

Mitä oikeuksia SBOM-työnkulku tarvitsee?

anchore/sbom-action pyytää oikeutta contents: write sekä oikeutta actions: read SBOM:n liittämiseen julkaisuun. Allekirjoitus toiminnolla actions/attest vaatii oikeudet id-token: write ja attestations: write, ja lisäksi packages: write, kun attestaatio viedään konttirekisteriin.

Miten allekirjoitan SBOM:n GitHub Actionsissa?

Käytä GitHubin artefaktiattestaatioita. actions/attest allekirjoittaa SPDX- tai CycloneDX-JSON-SBOM:n Sigstorella ja sitoo sen artefaktiin; tarkista se komennolla gh attestation verify. actions/attest-sbom on poistumassa käytöstä actions/attestin hyväksi, jota se nykyään käärii.

Miten generoin konttikuvan SBOM:n GitHub Actionsissa?

Anna kuva anchore/sbom-actionille syötteellä image syötteen path sijaan. Allekirjoittaaksesi sen anna toiminnolle actions/attest kuvan nimi ja tiiviste parametreilla subject-name ja subject-digest, aseta push-to-registry: true ja tarkista komennolla gh attestation verify oci://IMAGE.

Pitäisikö työnkulun tuottaa SPDX:ää vai CycloneDX:ää?

Sitä, mitä SBOM:ia lukeva työkalu odottaa. Riippuvuusgraafin vienti on vain SPDX:ää, ja cdxgen kirjoittaa CycloneDX:ää. anchore/sbom-action kirjoittaa kumpaa tahansa, ja actions/attest hyväksyy kumman tahansa. Katso CycloneDX vs. SPDX.

Pitäisikö SBOM-vaiheen ajaa ennen buildia vai sen jälkeen?

Vasta kun riippuvuudet on asennettu, muuten se ei näe niitä. Silloinkin se näkee levyllä olevan, ei sitä, minkä jobi latasi ja poisti tai minkä skripti haki. Buildin aikainen tallennus poistaa ajoituskysymyksen.