Bästa praxis för SBOM

Generera SBOM:er

1. Generera i CI, för varje release

En SBOM som tas fram för hand hinner bli inaktuell innan någon läser den. Gör den till ett steg i pipelinen som bygger releasen, eller använd en runner som tar fram en helt utan steg, så att ingen release levereras utan den. För GitHub Actions, se så genererar du en SBOM i GitHub Actions.

2. Beskriv bygget som levererades

Byggen är inte reproducerbara som standard. Att bygga samma commit två gånger ger ingen garanti för samma beroenden, eftersom versioner löses upp vid byggtillfället och steg kan variera. En SBOM från en laptop eller en senare skanning beskriver ett liknande bygge, inte det du levererade. Bara en SBOM från CI-bygget som producerade releasen bevisar vad den innehåller. Se SBOM:er från bygget.

3. Täck mer än lockfilen

En lockfile är ingen registrering av vad som levererades. Installationsskript laddar ner kod, byggskript i Rust hämtar filer, och containerbyggen drar in en basavbild med egna operativsystemspaket. Bestäm vad SBOM:en måste täcka och testa det sedan: sök i din SBOM efter ett paket från din basavbild och ett byggverktyg.

4. Ta med transitiva beroenden och relationer

Sårbarheter ligger oftast under dina direkta beroenden. En platt lista visar att en komponent finns, men inte vad du ska uppgradera. Behåll beroendegrafen i SBOM:en, så att ett fynd kommer med paketet som drar in det.

5. Ange vad du inte kunde se

2026 Minimum Elements ber SBOM-författare att uttryckligen ange okänd information. En ofullständig SBOM som säger det är värd mer än en ofullständig SBOM som ser färdig ut. Registrera också verktyget, dess version och genereringskontexten, så att läsaren kan bedöma vad filen täcker.

Spara SBOM:er

6. Spara en SBOM per release, kopplad till artefakten

När en kund på en gammal version frågar om de är exponerade behöver du den versionens SBOM, inte den senaste. Spara varje SBOM tillsammans med bygget och artefakten den beskriver, och bestäm hur länge den ska sparas utifrån hur länge du stöder releasen. Hashvärden i SBOM:en hjälper dig att koppla den till exakt rätt artefakt.

7. Välj ett format och en identifierare och håll fast vid dem

Standardisera på CycloneDX eller SPDX, en formatversion och package URL:er som identifierare. Det mesta av besväret med att jämföra SBOM:er kommer av att verktyg namnger samma sak på olika sätt. Validera varje fil i pipelinen, och be leverantörer om samma format.

Använda SBOM:er

8. Bevaka det som levererats, inte bara det du bygger

Det värdefullaste ögonblicket för en SBOM är dagen efter att ett säkerhetsmeddelande kommer för programvara som släpptes förra året. En skanning i en pull request hjälper inte då. Omvärdera de sparade SBOM:erna för releaser som stöds mot nya sårbarhetsdata, så att ett nytt säkerhetsmeddelande blir en lista över berörda releaser.

9. Skicka fynd till en ägare och registrera beslutet

En SBOM med tusen matchade sårbarheter är en lista, inte en plan. Rangordna fynd med en prioriteringsmetod, skicka vart och ett till teamet som äger åtgärden, och registrera varför du inte agerade på resten, till exempel i ett VEX-uttalande.

10. Använd samma SBOM för kunder och revisorer

Kunder, revisorer och tillsynsmyndigheter ställer liknande frågor. Besvara dem utifrån den SBOM som dina egna team använder, i stället för att ta fram ett separat dokument som glider isär. Om du delar SBOM:er, bestäm vem som får se dem och hur de får uppdateringar, och be dina leverantörer om detsamma.

Vanliga misstag

Misstag	Varför det är skadligt	Gör i stället så här
En SBOM per repo	Den säger ingenting om någon specifik release	En per release, kopplad till artefakten
Generera bara inför revision	Den beskriver ett bygge som ingen levererade	Varje release, i CI
Behandla SBOM:en som färdig	Nya säkerhetsmeddelanden kommer efter release	Fortsätt att bevaka den
Jämföra bara antalet komponenter	Fler är inte bättre om posterna är felaktiga	Kontrollera specifika paket som du vet finns där

Så hanterar CRACI det här

CRACI täcker de råd som är beroende av bygget. CRACI är en GitHub Actions-runner som registrerar varje paket som varje jobb hämtar, inklusive dolda beroenden som ingen lockfile listar, i en CycloneDX- eller SPDX-SBOM med en fullständighetsstatus. CRACI behåller varje tidigare bygge och dess SBOM inom din plans lagringstid, omvärderar bevakade SBOM:er när nya sårbarheter dyker upp och visar vilka byggen som innehöll ett sårbart beroende. Säkerhetsteamen triagerar fynd och skickar dem till teamen som äger åtgärden. Se SBOM-hantering för hur hanteringsverktygen står sig mot varandra, eller de bästa SBOM-verktygen.

Bästa praxis för SBOM: vanliga frågor

När bör du generera en SBOM?

Under CI-bygget som producerar releasen, varje gång. En SBOM som tas fram då beskriver vad som levererades, medan en som tas fram senare beskriver ett ombygge eller en skanning.

Hur länge bör du spara SBOM:er?

Minst så länge du stöder releasen, plus vad dina tillsynsmyndigheter eller avtal kräver. Du behöver SBOM:en för en gammal version för att avgöra om dess användare påverkas av en ny sårbarhet.

Bör SBOM:er automatiseras?

Ja. En manuell SBOM är inaktuell vid nästa release. Generera SBOM:er i pipelinen, validera dem där och spara dem tillsammans med bygget.

Bör du dela din SBOM med kunder?

Dela den när en kund eller tillsynsmyndighet frågar, på villkor som du känner dig bekväm med. En SBOM avslöjar vad du använder, så många företag delar den på begäran i stället för att publicera den.

Vad är skillnaden mellan en SBOM och SBOM-hantering?

En SBOM är en fil. SBOM-hantering är det löpande arbetet med att spara SBOM:er per release, bevaka dem för nya sårbarheter och göra dem tillgängliga för de personer som behöver dem.