Beste praksis for SBOM

Generere SBOM-er

1. Generer i CI, for hver utgivelse

En SBOM laget for hånd er utdatert før noen leser den. Gjør den til et steg i pipelinen som bygger utgivelsen, eller bruk en runner som produserer en helt uten et steg, slik at ingen utgivelse leveres uten. For GitHub Actions, se slik genererer du en SBOM i GitHub Actions.

2. Beskriv bygget som ble levert

Bygg er ikke reproduserbare som standard. Å bygge samme commit to ganger gir ingen garanti for de samme avhengighetene, fordi versjoner løses opp under bygget og steg kan variere. En SBOM fra en bærbar maskin eller en senere skanning beskriver et lignende bygg, ikke det du leverte. Bare en SBOM fra CI-bygget som produserte utgivelsen, beviser hva som er i den. Se SBOM-er fra bygget.

3. Dekk mer enn lockfilen

En lockfile er ikke en oversikt over hva som ble levert. Installasjonsskript laster ned kode, byggeskript i Rust henter filer, og containerbygg tar med et base-image med egne operativsystempakker. Bestem hva SBOM-en må dekke, og test det deretter: Søk i SBOM-en din etter en pakke fra base-imaget ditt og et byggeverktøy.

4. Ta med transitive avhengigheter og avhengighetsforhold

Sårbarheter ligger vanligvis under de direkte avhengighetene dine. En flat liste viser at en komponent finnes, men ikke hva du skal oppgradere. Behold avhengighetsgrafen i SBOM-en, så et funn følges av pakken som trekker det inn.

5. Oppgi hva du ikke kunne se

2026 Minimum Elements ber SBOM-forfattere om å oppgi ukjent informasjon eksplisitt. En delvis SBOM som sier det, er mer verdt enn en delvis SBOM som ser ferdig ut. Registrer også verktøyet, versjonen og genereringskonteksten, så en leser kan vurdere hva filen dekker.

Oppbevare SBOM-er

6. Ha én SBOM per utgivelse, knyttet til artefakten

Når en kunde på en gammel versjon spør om de er eksponert, trenger du SBOM-en til den versjonen, ikke den nyeste. Lagre hver SBOM sammen med bygget og artefakten den beskriver, og bestem hvor lenge du skal beholde den ut fra hvor lenge du støtter utgivelsen. Hasher i SBOM-en hjelper deg med å knytte den til den nøyaktige artefakten.

7. Velg et format og en identifikator, og hold deg til dem

Standardiser på CycloneDX eller SPDX, en formatversjon og package URL-er som identifikatorer. Det meste av bryderiet med å sammenligne SBOM-er kommer av at verktøy gir det samme ulike navn. Valider hver fil i pipelinen, og be leverandører om det samme formatet.

Bruke SBOM-er

8. Overvåk det som er levert, ikke bare det du bygger

Det mest verdifulle øyeblikket for en SBOM er dagen etter at en advisory kommer for programvare som ble utgitt i fjor. En skanning i en pull request kan ikke hjelpe da. Vurder de lagrede SBOM-ene for støttede utgivelser på nytt mot nye sårbarhetsdata, slik at en ny advisory blir til en liste over berørte utgivelser.

9. Send funn til en eier, og registrer beslutningen

En SBOM med tusen matchede sårbarheter er en liste, ikke en plan. Ranger funn med en prioriteringsmetode, send hvert funn til teamet som eier rettingen, og registrer hvorfor du ikke handlet på resten, for eksempel i en VEX-erklæring.

10. Bruk samme SBOM for kunder og revisorer

Kunder, revisorer og myndigheter stiller lignende spørsmål. Svar ut fra SBOM-en dine egne team bruker, i stedet for å produsere et eget dokument som glir fra virkeligheten. Hvis du deler SBOM-er, bestem hvem som får se dem og hvordan de får oppdateringer, og be leverandørene dine om det samme.

Vanlige feil

Feil	Hvorfor det skader	Gjør heller dette
Én SBOM per repositorium	Den sier ingenting om en bestemt utgivelse	Én per utgivelse, knyttet til artefakten
Generere bare ved revisjon	Den beskriver et bygg ingen leverte	Hver utgivelse, i CI
Behandle SBOM-en som ferdig	Nye advisories kommer etter utgivelse	Fortsett å overvåke den
Sammenligne bare antall komponenter	Flere er ikke bedre hvis oppføringene er feil	Sjekk bestemte pakker du vet er der

Slik håndterer CRACI dette

CRACI dekker rådene som avhenger av bygget. Det er en GitHub Actions-runner som registrerer hver pakke hver jobb henter, inkludert skjulte avhengigheter som ingen lockfile viser, i en CycloneDX- eller SPDX-SBOM med fullstendighetsstatus. CRACI beholder hvert tidligere bygg og SBOM-en til det innenfor oppbevaringstiden i planen din, vurderer overvåkede SBOM-er på nytt etter hvert som nye sårbarheter dukker opp, og viser hvilke bygg som inneholdt en sårbar avhengighet. Sikkerhetsteamene prioriterer funnene og sender dem videre til teamene som eier rettingen. Se SBOM-styring for hvordan styringsverktøyene står seg mot hverandre, eller de beste SBOM-verktøyene.

Beste praksis for SBOM: ofte stilte spørsmål

Når bør du generere en SBOM?

Under CI-bygget som produserer utgivelsen, hver gang. En SBOM laget på det tidspunktet beskriver det som ble levert, mens en som lages senere, beskriver et nytt bygg eller en skanning.

Hvor lenge bør du beholde SBOM-er?

Minst så lenge du støtter utgivelsen, pluss det myndigheter eller kontrakter krever. Du trenger SBOM-en til en gammel versjon for å avgjøre om brukerne av den er berørt av en ny sårbarhet.

Bør SBOM-er automatiseres?

Ja. En manuell SBOM er utdatert ved neste utgivelse. Generer SBOM-er i pipelinen, valider dem der og lagre dem sammen med bygget.

Bør du dele SBOM-en med kunder?

Del den når en kunde eller myndighet ber om det, på vilkår du er komfortabel med. En SBOM avslører hva du bruker, så mange selskaper deler den på forespørsel i stedet for å publisere den.

Hva er forskjellen på en SBOM og SBOM-styring?

En SBOM er én fil. SBOM-styring er det løpende arbeidet med å lagre SBOM-er per utgivelse, overvåke dem for nye sårbarheter og gjøre dem tilgjengelige for dem som trenger dem.