Gå til hovedinnhold

SBOM-er (Software Bill of Materials)

En SBOM (Software Bill of Materials) er ingredienslisten for et bygg – hver direkte og transitiv avhengighet som er bakt inn i en artefakt, med versjoner og hasher. fremforge lagrer SBOM-ene CI-en din lager, slik at oversikten overlever på tvers av bygg, bytte av imager og avhengigheter som glir over tid.

Når SBOM-er lages automatisk

Det er ingenting å installere. fremforge lager en CycloneDX 1.6-SBOM sentralt for hver pull request, på sine egne runnere, og knytter den SBOM-en til en utgivelse når du publiserer en – hvilken som helst tag, inkludert de vanlige semver- og calver-formene (v1.2.3, v2026.06).

Vi skanner bevisst ikke på nytt ved utgivelse. En SBOM er en funksjon av kildetreet, og treet du gir ut, er allerede skannet som toppen av pull requesten som merget det, så å lage en ny ville gi en byte-identisk fil. Å publisere en utgivelse markerer i stedet SBOM-en som allerede finnes for akkurat den commiten, som SBOM for utgivelsen. To konsekvenser som er verdt å vite:

  • Det skjer umiddelbart. Ingen bygg kjører, så SBOM-en for utgivelsen er tilgjengelig så snart utgivelsen er publisert.
  • Koblingen skjer på serveren. fremforge løser opp taggen din til commiten via Forgejo og matcher på den commiten, så ingenting i et bygg kan gjøre krav på en SBOM for en utgivelse den ikke har gjort seg fortjent til.

Publiserer du en utgivelse for en commit som aldri gikk gjennom en pull request – en tag på en svært gammel commit, eller et repository der historikken er eldre enn skanningen – finnes det ingen SBOM å knytte til. Den utgivelsen rapporteres som udekket i stedet for å bli hoppet over i stillhet; kjør en skanning på nytt på commiten for å dekke den.

Utløs en SBOM ved å tagge en utgivelse

Fra kommandolinjen:

git tag v1.2.3
git push origin v1.2.3

Fra Forgejo-grensesnittet: åpne repositoryet → Utgivelser → Ny utgivelse – sett et tag-navn som starter med v (for eksempel v1.2.3) og klikk Publish.

En enkeltstående SBOM for en vilkårlig commit er også tilgjengelig via fanen Handlinger → SBOM (Syft) → Run workflow.

Hvorfor bindes bare en utgivelse? Det lages en SBOM for hver pull request, men bare den for en commit som gis ut, blir en utgivelses-SBOM – revisorer vil ha SBOM-en «i det øyeblikket vi leverte utgivelse X». Å binde ved en utgivelse holder antallet utgivelses-SBOM-er i takt med den faktiske utgivelseskadensen.

Hva fremforge godtar

fremforge lager både CycloneDX 1.6- og SPDX 2.3-SBOM-er og godtar begge ved innlesing:

  • CycloneDX JSON (1.6) – oversikten hver fremforge-funksjon leser (kobling til utgivelser, sjekken for tom oversikt, oversiktssiden). Det bredere verktøyøkosystemet (Trivy, Syft, anchore) lager CycloneDX direkte.
  • SPDX JSON (2.3) – lages ved siden av av den samme Syft-kjøringen ved hver skanning av pull requests, og lagres under samme bygg, så SBOM-siden tilbyr begge nedlastingene for én utgivelse. Dine egne opplastinger kan være CycloneDX 1.5–1.7 eller SPDX 2.x/3.x; innlesingen validerer specVersion / spdxVersion før lagring.

SPDX-dokumentet er et eksportformat og lages etter beste evne: for et svært stort repository der de to dokumentene til sammen ville overskride leveringsgrensen på 14 MiB, lagres bare CycloneDX-SBOM-en, slik at oversikten aldri går tapt for å gi plass til det andre formatet.

Hver SBOM lagres med:

  • SHA-256-digesten av SBOM-filen. Den som laster opp, sender den, og serveren beregner den på nytt, så en avkortet eller endret opplasting avvises.
  • En valgfri in-toto-attesteringspakke (JSONL) – signert med Cosign når workflowen din signerer SBOM-en. Innlesingen validerer JSONL-formen og in-toto-feltene på hver linje før lagring.
  • Navnet og versjonen på artefakten, nøyaktig slik workflowen din navngir den. Brukes som nøkkel for deduplisering (samme digest + navn + versjon = én rad, ikke mange).

Absolutt grense på 5 MiB per SBOM. Endepunktet for innlesing returnerer 413 payload-too-large over det – del opp store SBOM-er for monorepoer per modul hvis du treffer grensen.

Slik pusher du en SBOM fra CI

fremforges runner-image har med Syft og Trivy, så de fleste workflower trenger bare et kort utdrag:

- name: Generate + push SBOM
  run: |
    syft packages dir:. --output cyclonedx-json=sbom.json
    # The digest is the SHA-256 of the SBOM file itself; the server recomputes it
    # and refuses a mismatch with 400 digest-mismatch.
    DIGEST=$(sha256sum sbom.json | cut -d' ' -f1)
    curl -sS --fail \
      -H "Authorization: Bearer ${{ secrets.FREMFORGE_API_TOKEN }}" \
      -F "sbom=@sbom.json" \
      -F "artifact_name=myapp" \
      -F "artifact_version=${GITHUB_SHA}" \
      -F "sha256_digest=${DIGEST}" \
      -F "format=cyclonedx-json" \
      "https://frem.sh/_app/api/v1/orgs/${ORG}/sboms"

Tokenet trenger scopet sboms:write; lag et under Organisasjonsadministrasjon → API-tokener med scopet for SBOM-push krysset av.

To valgfrie felt registrerer hvor artefakten kjører og hvilket repository den ble bygget fra:

  • environment: miljøklassen artefakten kjører i, en av sandbox, development, test eller production. Alt annet avvises med invalid-environment.
  • source_repo: repositoryet artefakten ble bygget fra, som owner/repo. Alt annet avvises med invalid-source-repo.
      -F "environment=production" \
      -F "source_repo=acme/payments-api" \

Ingen av feltene endrer oppbevaring eller noen sperre. En CycloneDX-SBOM med source_repo låner også ut avhengighetsgrafen sin til avhengighetsstiene for det repositoryet, og det er slik Maven- og Gradle-repositoryer får dem.

Hvor SBOM-er vises i administrasjonsgrensesnittet

Organisasjonsadministrasjon → Sikkerhet › Komponenter › SBOM-er viser hver innleste SBOM, gruppert etter artefakt. Hver rad viser:

  • Navn og versjon på artefakten og SHA-256-digesten
  • Format (CycloneDX / SPDX) og størrelse
  • Tidspunkt for innlesing og brukeren/tokenet som pushet den
  • Lenken «Verify signature» når en attestering er vedlagt

Hvordan SBOM-er spiller sammen med andre sikkerhetssignaler

  • Scorecard – gir grunnlaget for poengene Dependencies og Vulnerabilities i beregningen av OpenSSF Scorecard.
  • OSV-anbefalinger – når et OSV-sårbarhetsvarsel samsvarer med en komponent i en SBOM, vises anbefalingen med konsekvensen knyttet til SBOM-en («dette påvirker bygget myapp@v1.2.3 fra 2026-05-12»).
  • Cosign – flyten for signering av SBOM-er bruker den samme tillitsroten i Cosign som signering av imager. Se Cosign for hvordan de bekreftes.

Oppbevaring

SBOM-er for utgivelser beholdes så lenge organisasjonen din finnes. SBOM-er for bygg som ikke ble utgitt, slettes etter oppbevaringen av bevis for sbom: 14 dager som standard, 0 til 3650 dager. SBOM-en for toppen av standardbranchen, SBOM-ene for nåværende imager og SBOM-ene for pakkefiler beholdes uansett alder. Ingenting slettes mens en rettslig tilbakeholdelse (legal hold) er aktiv. (Fram til 2026-10-08 sto det i denne seksjonen at SBOM-er fulgte forhåndsinnstillingene for oppbevaring av revisjonsdata; det gjorde de aldri.)

Se også

  • Cosign – signering av imager og SBOM-er.
  • OSV-anbefalinger – sårbarheter som samsvarer med komponenter i SBOM-er.
  • Scorecard – SBOM-er gir grunnlaget for poengene for avhengigheter og sårbarheter.
  • API-referanse – endepunktet for innlesing, POST /_app/api/v1/orgs/{slug}/sboms.
EksempelrepositoryAI-rettelse