Bedste praksis for SBOM'er

Generering af SBOM'er

1. Generér i CI, for hver release

En SBOM lavet i hånden er forældet, før nogen læser den. Gør den til et trin i den pipeline, der bygger releasen, eller brug en runner, der producerer en helt uden et trin, så ingen release leveres uden. For GitHub Actions, se sådan genererer du en SBOM i GitHub Actions.

2. Beskriv det build, der blev leveret

Builds er ikke reproducerbare som standard. To builds af det samme commit garanterer ikke de samme afhængigheder, fordi versioner resolves under buildet, og trin kan variere. En SBOM fra en laptop eller en senere scanning beskriver et lignende build, ikke det, du leverede. Kun en SBOM fra det CI-build, der producerede releasen, beviser, hvad der er i den. Se build-time SBOM'er.

3. Dæk mere end lockfilen

En lockfile er ikke en registrering af, hvad der blev leveret. Install-scripts downloader kode, Rust-build-scripts henter filer, og container-builds trækker et base-image ind med sine egne styresystempakker. Beslut, hvad SBOM'en skal dække, og test det så: Søg i din SBOM efter en pakke fra dit base-image og et build-værktøj.

4. Medtag transitive afhængigheder og relationer

Sårbarheder ligger som regel under dine direkte afhængigheder. En flad liste viser, at en komponent er der, men ikke hvad der skal opgraderes. Behold afhængighedsgrafen i SBOM'en, så et fund kommer med den pakke, der trækker det ind.

5. Angiv, hvad du ikke kunne se

2026 Minimum Elements beder SBOM-forfattere om udtrykkeligt at angive ukendte oplysninger. En delvis SBOM, der siger det, er mere værd end en delvis SBOM, der ser færdig ud. Registrér også værktøjet, dets version og genereringskonteksten, så en læser kan vurdere, hvad filen dækker.

Opbevaring af SBOM'er

6. Gem én SBOM pr. release, koblet til artefaktet

Når en kunde på en gammel version spørger, om de er udsat, skal du bruge den versions SBOM og ikke den seneste. Gem hver SBOM sammen med det build og det artefakt, den beskriver, og afgør, hvor længe den skal gemmes, ud fra hvor længe du understøtter releasen. Hashes i SBOM'en hjælper dig med at koble den til det præcise artefakt.

7. Vælg et format og en identifikator, og hold dig til dem

Standardisér på CycloneDX eller SPDX, en formatversion og package URLs som identifikatorer. Det meste besvær med at sammenligne SBOM'er kommer af, at værktøjer navngiver det samme forskelligt. Validér hver fil i pipelinen, og bed leverandører om det samme format.

Brug af SBOM'er

8. Overvåg det, der blev leveret, ikke kun det, du bygger

Det mest værdifulde øjeblik for en SBOM er dagen efter, at en advisory lander for software, der blev udgivet sidste år. En scanning i en pull request kan ikke hjælpe der. Genvurdér de gemte SBOM'er for understøttede releases mod nye sårbarhedsdata, så en ny advisory bliver til en liste over berørte releases.

9. Send fund til en ejer, og registrér beslutningen

En SBOM med tusind matchede sårbarheder er en liste, ikke en plan. Rangér fund med en prioriteringsmetode, send hvert fund til det team, der ejer rettelsen, og registrér, hvorfor du ikke handlede på resten, for eksempel i en VEX-erklæring.

10. Brug den samme SBOM til kunder og revisorer

Kunder, revisorer og myndigheder stiller lignende spørgsmål. Svar ud fra den SBOM, dine egne teams bruger, i stedet for at producere et separat dokument, der glider væk fra virkeligheden. Hvis du deler SBOM'er, så beslut, hvem der må se dem, og hvordan de får opdateringer, og bed dine leverandører om det samme.

Almindelige fejl

Fejl	Hvorfor det skader	I stedet
Én SBOM pr. repository	Den siger intet om en bestemt release	Én pr. release, koblet til artefaktet
Kun at generere ved revision	Den beskriver et build, ingen leverede	Hver release, i CI
At betragte SBOM'en som færdig	Nye advisories kommer efter release	Bliv ved med at overvåge den
Kun at sammenligne antallet af komponenter	Flere er ikke bedre, hvis posterne er forkerte	Tjek bestemte pakker, du ved er der

Sådan håndterer CRACI det

CRACI dækker den praksis, der afhænger af buildet. Det er en GitHub Actions-runner, der registrerer hver pakke, hvert job henter, inklusive skjulte afhængigheder, som ingen lockfile angiver, i en CycloneDX- eller SPDX-SBOM med en fuldstændighedsstatus. Det gemmer hvert tidligere build og dets SBOM inden for din plans opbevaringsperiode, genvurderer overvågede SBOM'er, efterhånden som nye sårbarheder dukker op, og viser, hvilke builds der indeholdt en sårbar afhængighed. Sikkerhedsteams triagerer fund og sender dem videre til de teams, der ejer rettelsen. Se SBOM-administration for, hvordan administrationsværktøjerne klarer sig i sammenligning, eller de bedste SBOM-værktøjer.

Bedste praksis for SBOM'er: ofte stillede spørgsmål

Hvornår skal du generere en SBOM?

Under det CI-build, der producerer releasen, hver gang. En SBOM lavet på det tidspunkt beskriver det, der blev leveret, mens en lavet senere beskriver et genbyg eller en scanning.

Hvor længe skal du gemme SBOM'er?

Mindst så længe du understøtter releasen, plus hvad dine myndigheder eller kontrakter kræver. Du skal bruge SBOM'en for en gammel version for at se, om dens brugere er ramt af en ny sårbarhed.

Skal SBOM'er automatiseres?

Ja. En manuel SBOM er forældet ved næste release. Generér SBOM'er i pipelinen, validér dem der, og gem dem sammen med buildet.

Skal du dele din SBOM med kunder?

Del den, når en kunde eller en myndighed beder om det, på vilkår, du er tryg ved. En SBOM afslører, hvad du bruger, så mange virksomheder deler den på anmodning i stedet for at offentliggøre den.

Hvad er forskellen på en SBOM og SBOM-administration?

En SBOM er én fil. SBOM-administration er det løbende arbejde med at gemme SBOM'er pr. release, overvåge dem for nye sårbarheder og gøre dem tilgængelige for dem, der har brug for dem.