SBOM-generering över utvecklingsteam: en policy, varje pipeline

Varför skannrar per team inte blir ett SBOM-program

Rikta fem verktyg mot samma produkt så får du fem SBOM:er. Skillnaderna är strukturella, inte buggar:

• Olika indata, lästa vid olika tidpunkter. Ett verktyg läser lockfilen, ett annat det installerade beroendeträdet, ett tredje containeravbildningen, ett fjärde binären. Vart och ett ser en annan del av produkten.
• Olika namn på samma sak. Ett verktyg identifierar komponenter med package URL, ett annat med CPE, ett tredje bara med filnamn. Två SBOM:er som beskriver samma bibliotek kan inte kopplas ihop på en gemensam nyckel.
• Olika djup. Vissa listar bara direkta beroenden, vissa hela det transitiva trädet, och vissa listar också byggverktyg. Varför generatorer inte är överens om samma repository visas i SBOM-generatorer med öppen källkod.
• Vissa verktyg besvarar en annan fråga. Sårbarhetsskannrar för infrastruktur rapporterar vad som är installerat på körande värdar. Det är användbart för drift, och det är ingen beskrivning av produkten du levererar.

Följden: du kan inte slå ihop, deduplicera eller jämföra SBOM:er mellan produkter, och du kan inte visa en revisor en enda process, eftersom det inte finns någon.

Metod	Indata som läses	När	Vad som missas	Typisk identifierare
Skanner för lockfiler eller manifest	Lockfiler och manifest i utcheckningen	Före eller efter bygget	Allt som ingen lockfil listar: installationskrokar, nedladdningar från byggskript, basavbildningar	Package URL
Skanner för containeravbildningar	Paketdatabaser och filer i avbildningen	Efter bygget	Verktyg som bara används vid bygget, inkompilerad kod, allt utan paketpost	Package URL för OS- och språkpaket
Skanner för binärer eller firmware	Strängar och signaturer i binären	Efter bygget	Säkerhet: versioner och komponenter härleds	CPE eller härlett namn
Sårbarhetsskanner för värdar	Installerad programvara på körande servrar	I drift	Produkten så som den levereras till kunder	CPE eller leverantörens produktnamn
Registrering under bygget	Vad release-bygget hämtade	Under bygget	Programvara du inte har byggt; det som inte syntes flaggas som ofullständigt	Package URL

SBOM-policyn: vad som ska standardiseras

Standardisera SBOM:en, inte skannern. Policyn fastställer resultatet och processen; varje pipeline uppfyller den med den bästa generator den kan köra. Varje rad nedan går att kontrollera.

Krav	Regeln	Varför	Hur du kontrollerar det
Omfattning	Varje produktrelease som levereras till en kund, inklusive firmware och containeravbildningar. Interna verktyg valfritt.	Kunder och tillsynsmyndigheter frågar om det du levererar.	Varje release i releaseregistret har en SBOM.
Format och version	Ett primärt format, CycloneDX eller SPDX, med en lägsta version. Acceptera det andra på begäran.	Ett format innebär en parser, en validator och en lagringsplats. BSI TR-03183-2 kräver CycloneDX 1.6 eller senare eller SPDX 3.0.1 eller senare, en rimlig lägstanivå för kunder i EU.	Schemavalideringen rapporterar format och version.
Minsta fält	En package URL på varje komponent som har en, en CPE bara där ingen finns, leverantör, version, deklarerad licens, beroenderelationer, verktygets namn och version, tidsstämpel och genereringskontext.	Det är dessa som matchning, licensgranskning och revisioner använder. Anpassa dem efter de minsta elementen på vad är en SBOM.	En fältkontroll i pipelinen räknar saknade värden.
När den genereras	I det CI-bygge som producerar releasen, varje gång. Inte vid revisionen, inte på en laptop.	Ett nytt bygge är inte samma bygge; se SBOM:er från bygget.	SBOM:ens bygg-ID stämmer med releasens bygg-ID.
Djup	Hela det transitiva trädet, inte bara toppnivån.	CRA:s minimum är beroendena på toppnivå; sårbarheter och kunder går djupare.	Det finns beroenderelationer under första nivån.
Var den lagras	Tillsammans med releaseartefakten, hämtbar per produkt och version.	En SBOM som ingen hittar när en säkerhetsbulletin kommer är inget bevis.	Hämta SBOM:en för en slumpvis vald release per produkt och version.
Lagringstid	Minst produktens supportperiod plus den lagringstid för dokumentation som dina regelverk kräver.	CRA fastställer en lagringstid för teknisk dokumentation, och SBOM:en ingår i den.	Jämför policyns period med varje verktygs lagringstid.
Validering	Varje SBOM schemavalideras i pipelinen; en ogiltig får bygget eller release-grinden att fallera.	Ogiltiga SBOM:er fallerar tyst i kundens verktyg.	Release-grindens logg visar ett valideringssteg.
Ägarskap	Produktteamet äger genereringen; produktsäkerhet äger policyn, valideringsreglerna och rapporteringen av täckning.	Genereringen behöver pipelinens ägare; konsekvens behöver en enda ägare av reglerna.	Varje pipeline anger en ägare.
Undantag	Ett register över namngivna, tidsbegränsade undantag: team, skäl, slutdatum.	Policyn överlever team som ännu inte kan uppfylla den.	Inget undantag har passerat sitt slutdatum.

Checklistan i SBOM best practices täcker reglerna för en enskild SBOM; den här policyn är lagret ovanför. Varje team anger hur dess pipeline uppfyller policyn, i en fil bredvid pipelinen:

# sbom-policy.yaml, one per release pipeline
product: gateway-firmware
owner: team-gateway
format: cyclonedx
spec_version: "1.6"
generated_in: release-build
generator: build-time-recording
store: artifact-registry
validation: schema, fail-on-errors
exception: none

Generera i bygget, inte i efterhand per team

Generering under bygget är standarden att sikta på. Den beskriver det bygge som levererades, den tar med dolda beroenden som ingen lockfil listar, och en enda mekanism ger SBOM:er med samma form för varje team på den pipelinen. Skillnaden är enklast att förklara med ett kök: en skanner smakar på soppan och gissar receptet; en registrator ser vad som kommer in i köket.

En skanner är fortfarande rätt verktyg för avbildningar du inte har byggt, för binärer från tredje part och för äldre produkter utan CI. Skriv det i policyn och registrera genereringskontexten, så att läsaren vet vad varje SBOM såg.

Situation	Genereringsmetod	Genereringskontext att registrera
Release byggd i en CI du kontrollerar	Registrera bygget, eller kör en generator i release-jobbet	”Registrerad under bygget” eller ”efter installation, från filer”
Containeravbildning byggd i CI	Registrera bygget av avbildningen; skanna resultatet efter OS-paket om registratorn inte täcker dem	Bygg-ID och avbildningens digest
Avbildning eller appliance från tredje part	Avbildningsskanner, plus leverantörens SBOM om det finns en	”Skannat resultat, inte byggt av oss”
Binär från en leverantör	Be om leverantörens bygg-SBOM; binäranalys som kontroll	Leverantör, version, hur den erhölls
Äldre produkt utan pipeline	Skanna den levererade artefakten; planera en pipeline	”Skannat resultat” och ett undantag med slutdatum

Blandad CI: GitHub Actions, GitLab och Jenkins i en organisation

Policyn är CI-oberoende med avsikt: den definierar resultatet, så en GitLab- eller Jenkins-pipeline kan uppfylla den med ett generatorsteg, och en GitHub Actions-pipeline kan använda registrering under bygget. Regler för ett generatorsteg:

• Kör det i release-jobbet, efter installationssteget, inte i ett separat jobb som installerar igen.
• Lås generatorns version, och lås CI-actions till en commit, inte en tagg. Varför det spelar roll just för skannrar tas upp i SBOM-generatorer med öppen källkod.
• Registrera genereringskontexten som ”efter installation, från filer”, så att läsarna vet vad steget såg.
• Validera resultatet mot samma schema som alla andra pipelines.

Generatorer med öppen källkod som Syft, Trivy och cdxgen kan alla skriva CycloneDX och SPDX, så formatregeln tvingar inte fram något verktygsval. För en jämförelse, se SBOM-verktyg i jämförelse.

CRACI stöder i dag GitHub Actions; GitLab CI och Jenkins finns på roadmapen, utan datum. Följden för utrullningen: börja med registrering under bygget där GitHub Actions används, behåll generatorsteg på andra ställen, och följ båda i samma täckningsrapport.

När en kund vill ha en viss formatversion

En kund ber om CycloneDX 1.6, och dina verktyg skriver 1.7. Det händer eftersom kundens importverktyg eller egen policy är låst till en version; BSI:s lägstanivå är 1.6, så kunder i EU nämner den ofta. Dina alternativ:

1. Fråga om den nyare versionen accepteras. Ofta gör den det.
2. Konvertera med CycloneDX CLI, validera sedan mot målversionen, och kontrollera vad som gick förlorat: fält som bara finns i den nyare specifikationen tas bort.
3. Vid en SPDX-begäran konverterar samma CLI till och från SPDX JSON 2.3. Dess dokumentation varnar för att konvertering mellan SPDX och CycloneDX ”kan leda till att viss information går förlorad”.

cyclonedx convert --input-file bom.cdx.json --input-format json \
  --output-file bom-1.6.cdx.json --output-format json --output-version v1_6

cyclonedx validate --input-file bom-1.6.cdx.json --input-format json \
  --input-version v1_6 --fail-on-errors

Validatorn kontrollerar mot CycloneDX 1.7 om du inte anger --input-version. Policyregel: behåll den ursprungliga SBOM:en som det officiella underlaget. En konverterad kopia är en härledd leverans; lagra härledningen (verktyg, version, datum) tillsammans med den. Mer om hur du besvarar sådana förfrågningar i SBOM-förfrågningar från kunder, och om de två formaten i CycloneDX vs SPDX.

Licensdata till juristerna

Samma SBOM kan tjäna juristerna, om policyn kräver rätt fält. Juristerna behöver licensen för varje komponent, skillnaden mellan en deklarerad licens (vad paketet anger) och en fastställd (vad någon har verifierat), copyleft-skyldigheter och en lista över komponenter utan licens. CycloneDX 1.6 markerar licenser som deklarerade eller fastställda, och SPDX har separata fält för båda.

• Kräv SPDX-licensidentifierare eller -uttryck, som MIT eller Apache-2.0 OR MIT.
• Flagga NOASSERTION och saknade licenser för granskning. I SPDX betyder NOASSERTION att ingen bedömning gjordes eller att ingen information lämnades; det är ingen licens.
• Skicka copyleft-licenser till juristerna före releasen, inte efter.

En SBOM innehåller deklarerade licenser. En granskning av licensefterlevnad, med fastställda licenser, meddelanden och skyldigheter, är juridiskt arbete eller en uppgift för ett specialiserat verktyg; se licensefterlevnad för öppen källkod.

Rulla ut det team för team

Fas	Ägare	Klar när	Typiskt hinder
1. Inventering: produkter, pipelines, CI-system och nuvarande generatorer, en rad per release-pipeline	Produktsäkerhet	Varje levererad produkt har en rad	Ingen vet vilken pipeline som bygger en release
2. Publicera policyn med undantagsregistret	Produktsäkerhet	Policyn godkänd och publicerad	Debatt om vilket verktyg som ska krävas (policyn kräver inget)
3. Pilot med ett eller två team som har ett skäl: en kundförfrågan, en deadline, en produkt som det nuvarande verktyget inte klarar	Pilotteam	Pilotreleaser levereras med SBOM:er som följer policyn	Team utan ett brännande skäl prioriterar ned det
4. Lägg till valideringsgrindar i pilotpipelines	Pilotteam	En ogiltig SBOM får releasen att fallera	Rädsla för att blockera releaser; börja med en varning
5. Bredda per CI-system; avveckla en skanner per team först när ersättaren uppfyller policyn	Produktteam	Täckningsmålet nått per CI-system	Pipelines som ingen äger
6. Rapportera täckningen varje månad	Produktsäkerhet	Rapporten går till ledningen varje månad	Mätetal som räknas fram för hand

Inventeringskalkylarket i fas 1 bör vara det sista; att lämna kalkylark bakom sig tas upp i SBOM-automatisering. En Yocto-baserad produkt är en vanlig pilot, eftersom allmänna skannrar har svårt med den; se varför SBOM-skannrar missar Yocto-byggen.

Mäta täckning

Siffrorna som ledning och revisorer frågar efter, var och en definierad som en kvot:

• Releasetäckning: releaser levererade med en SBOM som följer policyn ÷ levererade releaser.
• Produkttäckning: produkter med minst en SBOM som följer policyn under den aktuella supportperioden ÷ produkter med support.
• Andel godkända valideringar: SBOM:er som klarar valideringen ÷ genererade SBOM:er.
• Identifierartäckning: komponenter med en package URL (eller en CPE) ÷ komponenter.
• Licenstäckning: komponenter med en deklarerad licens ÷ komponenter.
• Fullständighet: SBOM:er vars generator anger att de är fullständiga ÷ SBOM:er. Bara möjligt där verktyget rapporterar det.
• Tid till SBOM: tiden från release till tillgänglig SBOM.

En exempelrapport för en månad (illustrativa siffror):

Mätetal	GitHub Actions-pipelines	GitLab- och Jenkins-pipelines	Alla
Releasetäckning	46 / 48	19 / 27	65 / 75
Andel godkända valideringar	100%	92%	97%
Identifierartäckning	99%	88%	95%
Öppna undantag	1	4	5

Som bevis för en tillsynsmyndighet eller en revisor består underlaget av policyn, undantagsregistret, täckningsrapporten och några exempel-SBOM:er. Det visar en process, tillämpad och mätt. För CRA-sidan, se CRA-guiden.

Var CRACI passar in

För GitHub Actions-pipelines är CRACI runnern: du anger runs-on: craci, och varje jobb får en registrerad SBOM utan generatorsteg. Varje SBOM har en fullständighetsstatus, de transitiva beroendena, en package URL per paket och varje komponents deklarerade licens, och kan exporteras som CycloneDX eller SPDX. Regler i licenspolicyn kan stoppa ett bygge, bevakade SBOM:er omvärderas kontinuerligt, och bygghistoriken visar vilka byggen som innehöll ett sårbart beroende. Det ger de teamen policyns rader ”genererad i release-bygget”, ”identifierare” och ”licens” som standard. SBOM:er från tredje part kan läggas till, så att inköpta komponenter bevakas tillsammans med dina byggen.

Se SBOM-generering med CRACI och SBOM:er i GitHub Actions.

När CRACI inte är svaret

• Team på GitLab CI eller Jenkins: inte i dag, det finns på roadmapen. Använd ett generatorsteg som uppfyller policyn.
• GitHub Enterprise Server: stöds inte i dag.
• Skanning av infrastruktur och värdar, alltså vad som är installerat på servrar och felkonfigurationer: en annan uppgift; behåll de verktygen.
• Binär- eller firmwareanalys av leverantörsavbildningar som du inte bygger: CRACI registrerar byggen och skannar inte binärer.
• Lång lagringstid: CRACI sparar byggdata i 180 dagar som standard, med anpassad lagringstid på Enterprise. Om din policy kräver SBOM:er längre än så, exportera dem till din egen lagring.

SBOM-generering över team: vanliga frågor

Hur standardiserar vi SBOM-generering mellan team som använder olika verktyg?

Standardisera resultatet, inte verktyget. Skriv en policy som fastställer format och version, minsta fält, när SBOM:en genereras, var den lagras, hur länge den sparas och vem som validerar den. Låt varje pipeline uppfylla den med den bästa generator den kan köra, och mät täckningen mot policyn.

Vad ska en SBOM-policy innehålla?

Omfattning, format och lägsta version, minsta fält (package URL, leverantör, version, deklarerad licens, beroenden, verktyg, tidsstämpel, genereringskontext), generering i release-bygget, fullt transitivt djup, lagring tillsammans med releasen, lagringstid, validering i pipelinen, ägarskap och ett register över tidsbegränsade undantag.

Ska varje team köra en egen skanner, eller ska SBOM:er komma från bygget?

Från bygget, där det går. En SBOM från bygget beskriver det bygge som levererades och ger varje team på den pipelinen SBOM:er med samma form. Behåll skannrar för det du inte har byggt: avbildningar från tredje part, binärer från leverantörer och äldre produkter utan pipeline.

En kund vill ha vår SBOM i en äldre CycloneDX-version. Vad gör vi?

Fråga först om den nyare versionen accepteras. Om inte, konvertera en kopia med CycloneDX CLI (cyclonedx convert med --output-version v1_6), validera den mot den versionen och kontrollera vilka fält som togs bort. Behåll originalet som det officiella underlaget och lagra hur kopian härleddes.

Hur får vi licensdata från våra SBOM:er till juristerna?

Kräv SPDX-licensidentifierare eller -uttryck i policyn, flagga NOASSERTION och saknade licenser för granskning, och skicka copyleft-licenser till juristerna före releasen. SBOM:en innehåller deklarerade licenser; fastställda licenser, meddelanden och skyldigheter kräver en licensgranskning.

Hur mäter vi SBOM-täckning över produkter?

Som kvoter: releaser levererade med en SBOM som följer policyn, produkter med support som har en sådan SBOM, andel godkända valideringar, komponenter med en package URL, komponenter med en deklarerad licens, fullständiga SBOM:er där verktyget rapporterar det, och tiden från release till SBOM. Rapportera dem varje månad per CI-system.

Vilka bevis behöver vi för att visa en revisor att SBOM-genereringen är konsekvent?

Policyn, undantagsregistret, den månatliga täckningsrapporten och några exempel-SBOM:er med sin genereringskontext. Tillsammans visar de en process, tillämpad på varje release och mätt, vilket är vad en revisor eller en kund kontrollerar.