Cyber Security Academy · leksjon

Programvarekomponentliste (SBOM)

Kartlegge hva programvaren din inneholder.

Leksjon 2 av 413 trinn

Programvarekomponentliste (SBOM) er en gratis leksjon i Cyber Security Academy på CoddyKit. Dette er leksjon 2 av 4. Du kan lese valgfritt 3 leksjoner fra denne læringsstien gratis i sin helhet – deretter låser CoddyKit PRO opp alle leksjoner, samt praktisk øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i Cyber Security Academy, og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i Cyber Security Academy inneholder totalt 4 leksjoner.

Hva er en SBOM

En Software Bill of Materials (SBOM) er en formell, maskinlesbar oversikt over alle komponentene i et program: biblioteker, versjonene deres, lisenser og leverandøropplysninger.

På samme måte som en matvareetikett lister opp ingredienser, gjør en SBOM det mulig å svare på sekunder: inneholder dette produktet den sårbare versjonen av X? Uten en SBOM kan dette spørsmålet kreve flere dager med manuelt detektivarbeid.

Hvorfor SBOM-er er viktige nå

Når en kritisk sårbarhet blir kjent, er det første operative spørsmålet omfanget: hvilke av produktene våre leveres med den berørte komponenten?

Under Log4Shell-hendelsen kunne organisasjoner med SBOM-er søke i oversikten sin og prioritere tiltak i løpet av timer. Organisasjoner uten SBOM-er brukte uker på å søke gjennom byggkataloger. Tilsynsmyndigheter og store innkjøpere krever i økende grad SBOM-er som et innkjøpskrav.

  • Rask analyse av sårbarhetens påvirkning
  • Lisenssamsvar og sporing av forpliktelser
  • Åpenhet i programvareforsyningskjeden overfor kunder og revisorer

Standardformater for SBOM

To åpne standarder dominerer. Verktøy kan som regel konvertere mellom dem.

  • SPDX — en standard fra Linux Foundation, sterk på lisensinformasjon og bredt akseptert av tilsynsmyndigheter
  • CycloneDX — en OWASP-standard med sikkerhetsfokus, som støtter data om sårbarheter og avhengighetsforhold

Unngå å finne opp et eget format. Mottakere og skannere forventer disse formatene.

Hva skal en oppføring inneholde

Hver komponentoppføring bør inneholde nok identifikasjon til å kunne matches mot sårbarhetskilder. Viktige felt er:

  • navn og versjon — nøyaktig, ikke et intervall
  • PURL (package URL) — en universell identifikator som pkg:npm/lodash@4.17.21
  • hash — for å bekrefte integriteten
  • lisens — SPDX-lisensidentifikator
  • leverandør — hvem som produserte komponenten
# A PURL uniquely identifies a component across ecosystems
pkg:npm/lodash@4.17.21
pkg:pypi/requests@2.31.0
pkg:golang/github.com/gin-gonic/gin@v1.9.1

Generering av en SBOM

Generer SBOM-er automatisk fra kildekode eller fra et bygget artefakt. Syft er en vanlig generator på tvers av økosystemer som kan skrive ut begge standardformatene.

# from a project directory (CycloneDX JSON)
syft dir:. -o cyclonedx-json=sbom.cdx.json

# from a container image (SPDX JSON)
syft my-app:1.4.0 -o spdx-json=sbom.spdx.json

# CycloneDX has native generators per ecosystem too
cyclonedx-npm --output-file sbom.json

SBOM-er for kildekode, bygg og kjøretid

En SBOM som genereres på ulike stadier, gir ulike bilder av innholdet.

  • Kildekode-SBOM — det manifestet deklarerer; kan mangle bundlet eller vendoret kode
  • Bygg-SBOM — det bygget faktisk hentet inn; mest nøyaktig for utgivelsen
  • Kjøretids-/distribuert SBOM — det som faktisk finnes i det kjørende avbildningen, inkludert OS-pakker

For å sikre programvareforsyningskjeden bør SBOM-en genereres ved byggetidspunktet fra det faktiske artefaktet, og den endelige containeren bør også skannes for pakker på OS-nivå.

Skanning av en SBOM etter sårbarheter

En SBOM blir kraftfull når den sendes til en matcher som kobler komponenter til kjente CVE-er. Dette skiller generering fra analyse: En gammel SBOM kan skannes på nytt den dagen en ny CVE offentliggjøres.

# match an SBOM against vulnerability databases
grype sbom:sbom.cdx.json

# OSV scanner consumes SBOMs directly
osv-scanner --sbom=sbom.spdx.json

# fail CI above a severity threshold
grype sbom:sbom.cdx.json --fail-on high

VEX: Angi hva som kan utnyttes

En SBOM kan vise en sårbar komponent som faktisk ikke kan utnyttes i produktet (den sårbare funksjonen kalles aldri). Et VEX-dokument (Vulnerability Exploitability eXchange) registrerer denne vurderingen.

VEX reduserer støyen: I stedet for at alle kunder får panikk over en oppført CVE, kan det publiseres en erklæring om not_affected med begrunnelse, eller affected med informasjon om utbedring. Det gjør en rå oversikt om til et grunnlag for konkrete prioriteringer.

Distribusjon og signering av SBOM-er

En SBOM er bare til å stole på hvis den er autentisk og knyttet til det nøyaktige artefaktet den beskriver. Signer den og legg den ved som en attestasjon, i stedet for som en løs fil.

# attach a signed SBOM attestation to an image with cosign
cosign attest --predicate sbom.cdx.json \
  --type cyclonedx \
  my-registry/my-app:1.4.0

# verify the attached SBOM attestation
cosign verify-attestation --type cyclonedx my-registry/my-app:1.4.0

Automatisering av SBOM-er i CI

Manuelle SBOM-er blir umiddelbart utdaterte. Koble genereringen til pipeline-en slik at hver utgivelse genererer og lagrer en SBOM som et byggeartefakt, helst signert og skannet i samme jobb.

  • Generer fra det bygde artefaktet, ikke bare fra repoet
  • Lag­re SBOM-er i et søkbart register som er indeksert etter versjon
  • Skann lagrede SBOM-er på nytt etter en tidsplan mot oppdaterte CVE-kilder
  • La skanneresultatet avgjøre om utgivelser tillates

Vanlige fallgruver med SBOM-er

SBOM-er svikter ubemerket når de behandles som et avkrysningspunkt.

  • Utdaterte — generert én gang og aldri generert på nytt
  • Ufullstendige — mangler OS-pakker, statisk lenket eller vendoret kode
  • Ubekreftede — ingen hash som knytter dem til det distribuerte artefaktet
  • Ubrukte — produsert, men aldri skannet eller søkt i

Målet er en nøyaktig SBOM som genereres på nytt, signeres og skannes kontinuerlig – ikke en enkeltstående JSON-fil.

Hurtigsjekk: Formålet med SBOM

Bruk det som er lært, på et scenario med en hendelse.

Oppsummering: SBOM

Nå kan innholdet i programvaren kartlegges og brukes som grunnlag for tiltak.

  • En SBOM er en maskinlesbar liste over alle komponenter, i formatet SPDX eller CycloneDX
  • Identifiser komponenter med PURL, versjon, hash og lisens
  • Generer ved byggetidspunktet, og send deretter SBOM-en til en matcher (grype, osv-scanner) for å finne CVE-er
  • Bruk VEX til å angi reell utnyttbarhet og redusere falske alarmer
  • Signer og automatiser i CI, og skann lagrede SBOM-er på nytt mot nye kilder

Neste leksjon handler om å dokumentere artefaktenes opphav ved hjelp av signering.

Gratis å komme i gang

Lær deg Cyber Security Academy med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
76
Leksjoner
303

Ofte stilte spørsmål

Er leksjonen «Programvarekomponentliste (SBOM)» gratis?

Ja – du kan lese valgfritt 3 av leksjonene i læringsstien Cyber Security Academy, inkludert «Programvarekomponentliste (SBOM)», gratis i sin helhet her på nettet. Deretter låser CoddyKit PRO opp alle leksjoner, samt interaktiv øving med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Kurset i Cyber Security Academy inneholder totalt 4 leksjoner.

Hva lærer jeg i «Programvarekomponentliste (SBOM)»?

Kartlegge hva programvaren din inneholder. Du øver på Cyber Security Academy med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med Cyber Security Academy?

Ingen tidligere erfaring er nødvendig. Cyber Security Academy på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Programvarekomponentliste (SBOM)»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne Cyber Security Academy-leksjonen?

Ja. Alle Cyber Security Academy-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Trusler mot forsyningskjeden
  2. Programvarekomponentliste (SBOM)
  3. Signering av avhengigheter og artefakter
  4. Sikring av CI/CD-pipelines
← Tilbake til Cyber Security Academy