SBOM-generering på tvers av utviklingsteam: én policy, hver pipeline

Hvorfor skannere per team ikke blir et SBOM-program

Rett fem verktøy mot det samme produktet, og du får fem SBOM-er. Forskjellene er strukturelle, ikke feil:

• Ulike inndata, lest på ulike tidspunkter. Ett verktøy leser lockfilen, et annet det installerte avhengighetstreet, et tredje container-imaget, et fjerde binærfilen. Hvert av dem ser et ulikt utsnitt av produktet.
• Ulike navn på det samme. Ett identifiserer komponenter med package URL, et annet med CPE, et tredje bare med filnavn. To SBOM-er som beskriver det samme biblioteket, kan ikke kobles på en felles nøkkel.
• Ulik dybde. Noen lister bare direkte avhengigheter, noen hele det transitive treet, og noen lister også byggeverktøy. Hvorfor generatorer er uenige om det samme repositoriet, vises i SBOM-generatorer med åpen kildekode.
• Noen verktøy svarer på et annet spørsmål. Sårbarhetsskannere for infrastruktur rapporterer hva som er installert på kjørende verter. Det er nyttig for driften, og det er ikke en beskrivelse av produktet du leverer.

Konsekvensen: Du kan ikke slå sammen, fjerne duplikater i eller sammenligne SBOM-er på tvers av produkter, og du kan ikke vise en revisor én prosess, fordi det ikke finnes noen.

Metode	Inndata den leser	Når	Hva den går glipp av	Typisk identifikator
Skanner for lockfiler eller manifester	Lockfiler og manifester i checkouten	Før eller etter bygget	Alt som ingen lockfil viser: installasjonshooks, nedlastinger fra byggeskript, base-images	Package URL
Skanner for container-images	Pakkedatabaser og filer i imaget	Etter bygget	Verktøy som bare brukes i bygget, innkompilert kode, alt uten en pakkeoppføring	Package URL for OS- og språkpakker
Skanner for binærfiler eller fastvare	Strenger og signaturer i binærfilen	Etter bygget	Sikkerhet: versjoner og komponenter utledes	CPE eller utledet navn
Sårbarhetsskanner for verter	Installert programvare på kjørende servere	I drift	Produktet slik det leveres til kunder	CPE eller leverandørens produktnavn
Registrering under bygget	Det release-bygget hentet	Under bygget	Programvare du ikke bygde; det den ikke kunne se, merkes som ufullstendig	Package URL

SBOM-policyen: hva som skal standardiseres

Standardiser SBOM-en, ikke skanneren. Policyen fastsetter resultatet og prosessen; hver pipeline oppfyller den med den beste generatoren den kan kjøre. Hver rad nedenfor er noe du kan kontrollere.

Krav	Regelen	Hvorfor	Slik kontrollerer du det
Omfang	Hver produktrelease som leveres til en kunde, inkludert fastvare og container-images. Interne verktøy valgfritt.	Kunder og myndigheter spør om det du leverer.	Hver release i release-registeret har en SBOM.
Format og versjon	Ett primærformat, CycloneDX eller SPDX, med en minimumsversjon. Godta det andre på forespørsel.	Ett format betyr én parser, én validator og ett lager. BSI TR-03183-2 krever CycloneDX 1.6 eller nyere eller SPDX 3.0.1 eller nyere, et fornuftig minimum for kunder i EU.	Skjemavalideringen rapporterer format og versjon.
Minimumsfelt	En package URL på hver komponent som har en, en CPE bare der ingen finnes, leverandør, versjon, deklarert lisens, avhengighetsrelasjoner, verktøynavn og -versjon, tidsstempel og genereringskontekst.	Det er disse som brukes til matching, lisensgjennomgang og revisjoner. Samordne dem med minimumselementene i hva er en SBOM.	En feltkontroll i pipelinen teller manglende verdier.
Når den genereres	I CI-bygget som produserer releasen, hver gang. Ikke ved revisjonstidspunktet, ikke på en bærbar PC.	Et nytt bygg er ikke det samme bygget; se SBOM-er fra byggetidspunktet.	Bygg-ID-en i SBOM-en samsvarer med bygg-ID-en til releasen.
Dybde	Hele det transitive treet, ikke bare øverste nivå.	CRAs minimum er avhengighetene på øverste nivå; sårbarheter og kunder går dypere.	Det finnes avhengighetsrelasjoner under første nivå.
Hvor den lagres	Sammen med release-artefakten, mulig å hente etter produkt og versjon.	En SBOM som ingen finner når et sikkerhetsvarsel kommer, er ikke dokumentasjon.	Hent SBOM-en for en tilfeldig release etter produkt og versjon.
Oppbevaring	Minst produktets støtteperiode pluss den oppbevaringen av dokumentasjon som regelverket ditt krever.	CRA fastsetter en oppbevaringsperiode for teknisk dokumentasjon, og SBOM-en er en del av den.	Sammenlign policyens periode med hvert verktøys oppbevaring.
Validering	Hver SBOM skjemavalideres i pipelinen; en ugyldig SBOM får bygget eller release-porten til å feile.	Ugyldige SBOM-er feiler stille i kundens verktøy.	Loggen fra release-porten viser et valideringssteg.
Eierskap	Produktteamet eier genereringen; produktsikkerhet eier policyen, valideringsreglene og dekningsrapporteringen.	Genereringen trenger pipelinens eier; konsistens trenger én eier av reglene.	Hver pipeline har en navngitt eier.
Unntak	Et navngitt, tidsbegrenset unntaksregister: team, begrunnelse, sluttdato.	Policyen overlever team som ikke kan følge den ennå.	Ingen unntak har passert sluttdatoen.

Sjekklisten i beste praksis for SBOM dekker reglene for én enkelt SBOM; denne policyen er laget over dem. Hvert team erklærer hvordan pipelinen deres oppfyller policyen, i en fil ved siden av 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

Generer i bygget, ikke per team i etterkant

Generering under bygget er standarden å sikte mot. Den beskriver bygget som ble levert, den inkluderer skjulte avhengigheter som ingen lockfil viser, og én mekanisme produserer SBOM-er med samme form for hvert team på den pipelinen. Forskjellen er lettest å forklare med et kjøkken: En skanner smaker på suppen og gjetter oppskriften; en registrator ser hva som går inn i kjøkkenet.

En skanner er fortsatt det riktige verktøyet for images du ikke bygde, for binærfiler fra tredjeparter og for eldre produkter uten CI. Skriv det i policyen, og registrer genereringskonteksten, slik at leseren vet hva hver SBOM så.

Situasjon	Genereringsmetode	Genereringskontekst som skal registreres
Release bygget i CI du kontrollerer	Registrer bygget, eller kjør en generator inne i release-jobben	"Registrert under bygget" eller "etter installasjon, fra filer"
Container-image bygget i CI	Registrer bygget av imaget; skann resultatet for OS-pakkene hvis registratoren ikke dekker dem	Bygg-ID og image-digest
Image eller appliance fra tredjepart	Image-skanner, pluss leverandørens SBOM hvis det finnes en	"Skannet resultat, ikke bygget av oss"
Binærfil fra leverandør	Be om leverandørens bygg-SBOM; binæranalyse som kontroll	Leverandør, versjon, hvordan den ble skaffet
Eldre produkt uten pipeline	Skann den leverte artefakten; planlegg en pipeline	"Skannet resultat" og et unntak med sluttdato

Blandet CI: GitHub Actions, GitLab og Jenkins i én organisasjon

Policyen er CI-uavhengig med vilje: Den definerer resultatet, så en GitLab- eller Jenkins-pipeline kan oppfylle den med et generatorsteg, og en GitHub Actions-pipeline kan bruke registrering under bygget. Regler for et generatorsteg:

• Kjør det i release-jobben, etter installasjonssteget, ikke i en egen jobb som installerer på nytt.
• Lås generatorens versjon, og lås CI-actions til en commit, ikke en tag. Hvorfor det betyr noe for skannere spesielt, dekkes i SBOM-generatorer med åpen kildekode.
• Registrer genereringskonteksten som "etter installasjon, fra filer", slik at leserne vet hva den så.
• Valider resultatet mot det samme skjemaet som alle andre pipelines.

Generatorer med åpen kildekode som Syft, Trivy og cdxgen kan alle skrive CycloneDX og SPDX, så formatregelen tvinger ikke frem et verktøyvalg. For å sammenligne dem, se SBOM-verktøy sammenlignet.

CRACI støtter i dag GitHub Actions; GitLab CI og Jenkins står på veikartet, uten dato. Konsekvensen for utrullingen: Start registrering under bygget der GitHub Actions brukes, behold generatorsteg ellers, og følg begge i den samme dekningsrapporten.

Når en kunde vil ha en bestemt formatversjon

En kunde ber om CycloneDX 1.6, og verktøyene dine skriver 1.7. Det skjer fordi kundens innlesingsverktøy eller egen policy er låst til en versjon; BSIs minimum er 1.6, så kunder i EU nevner den ofte. Alternativene dine:

1. Spør om den nyere versjonen godtas. Ofte gjør den det.
2. Konverter med CycloneDX CLI, valider deretter mot målversjonen, og sjekk hva som gikk tapt: Felt som bare finnes i den nyere spesifikasjonen, forsvinner.
3. For en SPDX-forespørsel konverterer den samme CLI-en til og fra SPDX JSON 2.3. Dokumentasjonen advarer om at konvertering mellom SPDX og CycloneDX "kan føre til tap av noe informasjon".

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

Validatoren kontrollerer mot CycloneDX 1.7 med mindre du oppgir --input-version. Policyregel: Behold den opprinnelige SBOM-en som registreringen. En konvertert kopi er en avledet leveranse; lagre avledningen (verktøy, versjon, dato) sammen med den. Mer om å svare på slike forespørsler i SBOM-forespørsler fra kunder, og om de to formatene i CycloneDX vs SPDX.

Lisensdata til juridisk avdeling

Den samme SBOM-en kan betjene juristene, hvis policyen ber om de riktige feltene. Juridisk trenger lisensen til hver komponent, forskjellen mellom en deklarert lisens (det pakken oppgir) og en fastslått lisens (det noen har verifisert), copyleft-forpliktelser og en liste over komponenter uten lisens. CycloneDX 1.6 merker lisenser som deklarert eller fastslått, og SPDX har egne felt for begge.

• Krev SPDX-lisensidentifikatorer eller -uttrykk, som MIT eller Apache-2.0 OR MIT.
• Flagg NOASSERTION og manglende lisenser for gjennomgang. I SPDX betyr NOASSERTION at ingen vurdering ble gjort eller at ingen informasjon ble oppgitt; det er ikke en lisens.
• Send copyleft-lisenser til juridisk før release, ikke etter.

En SBOM inneholder deklarerte lisenser. En gjennomgang av lisenssamsvar, med fastslåtte lisenser, merknader og forpliktelser, er juridisk arbeid eller en jobb for et spesialverktøy; se lisenssamsvar for åpen kildekode.

Rull det ut team for team

Fase	Eier	Avslutningskriterium	Typisk hindring
1. Kartlegging: produkter, pipelines, CI-systemer og nåværende generatorer, én rad per release-pipeline	Produktsikkerhet	Hvert levert produkt har en rad	Ingen vet hvilken pipeline som bygger en release
2. Publiser policyen med unntaksregisteret	Produktsikkerhet	Policyen er godkjent og publisert	Debatt om hvilket verktøy som skal påbys (policyen påbyr ikke noe)
3. Pilot med ett eller to team som har en grunn: en kundeforespørsel, en frist, et produkt det nåværende verktøyet ikke håndterer	Pilotteam	Pilotreleaser leveres med SBOM-er som oppfyller policyen	Team uten en presserende grunn nedprioriterer det
4. Legg til valideringsporter i pilotpipelinene	Pilotteam	En ugyldig SBOM får releasen til å feile	Frykt for å blokkere releaser; start med en advarsel
5. Utvid per CI-system; fjern en skanner per team først når erstatningen oppfyller policyen	Produktteam	Dekningsmålet er nådd per CI-system	Pipelines ingen eier
6. Rapporter dekning hver måned	Produktsikkerhet	Rapporten går til ledelsen hver måned	Målinger beregnet for hånd

Kartleggingsregnearket i fase 1 bør være det siste; overgangen bort fra regneark dekkes i SBOM-automatisering. Et Yocto-basert produkt er en vanlig pilot, fordi generelle skannere sliter med det; se hvorfor SBOM-skannere bommer på Yocto-bygg.

Måling av dekning

Tallene ledelsen og revisorer ber om, hvert definert som en brøk:

• Release-dekning: releaser levert med en SBOM som oppfyller policyen ÷ leverte releaser.
• Produktdekning: produkter med minst én SBOM som oppfyller policyen i gjeldende støtteperiode ÷ produkter med støtte.
• Andel bestått validering: SBOM-er som består valideringen ÷ genererte SBOM-er.
• Identifikatordekning: komponenter med en package URL (eller en CPE) ÷ komponenter.
• Lisensdekning: komponenter med en deklarert lisens ÷ komponenter.
• Fullstendighet: SBOM-er der generatoren oppgir at de er fullstendige ÷ SBOM-er. Bare mulig der verktøyet rapporterer det.
• Tid til SBOM: tiden fra release til SBOM-en er tilgjengelig.

Et eksempel på en månedsrapport (illustrerende tall):

Måling	GitHub Actions-pipelines	GitLab- og Jenkins-pipelines	Alle
Release-dekning	46 / 48	19 / 27	65 / 75
Andel bestått validering	100%	92%	97%
Identifikatordekning	99%	88%	95%
Åpne unntak	1	4	5

Som dokumentasjon for en myndighet eller en revisor består settet av policyen, unntaksregisteret, dekningsrapporten og noen få eksempel-SBOM-er. Det viser én prosess, anvendt og målt. For CRA-siden, se CRA-veiledningen.

Hvor CRACI passer inn

For GitHub Actions-pipelines er CRACI runneren: Du setter runs-on: craci, og hver jobb får en registrert SBOM uten et generatorsteg. Hver SBOM har en fullstendighetsstatus, de transitive avhengighetene, en package URL per pakke og hver komponents deklarerte lisens, og eksporteres som CycloneDX eller SPDX. Regler for lisenspolicy kan blokkere et bygg, overvåkede SBOM-er vurderes kontinuerlig på nytt, og bygghistorikken viser hvilke bygg som inneholdt en sårbar avhengighet. Det gir disse teamene policyens rader "generert i release-bygget", "identifikator" og "lisens" som standard. SBOM-er fra tredjeparter kan legges til, slik at innkjøpte komponenter overvåkes side om side med byggene dine.

Se SBOM-generering med CRACI og SBOM-er i GitHub Actions.

Når CRACI ikke er svaret

• Team på GitLab CI eller Jenkins: ikke i dag, det står på veikartet. Bruk et generatorsteg som oppfyller policyen.
• GitHub Enterprise Server: støttes ikke i dag.
• Skanning av infrastruktur og verter, altså hva som er installert på servere og feilkonfigurasjoner: en annen jobb; behold de verktøyene.
• Binær- eller fastvareanalyse av leverandørimages du ikke bygger: CRACI registrerer bygg og skanner ikke binærfiler.
• Lang oppbevaring: CRACI oppbevarer byggdata i 180 dager som standard, med tilpasset oppbevaring på Enterprise. Hvis policyen din krever SBOM-er lenger, eksporter dem til ditt eget lager.

SBOM-generering på tvers av team: ofte stilte spørsmål

Hvordan standardiserer vi SBOM-generering på tvers av team som bruker ulike verktøy?

Standardiser resultatet, ikke verktøyet. Skriv én policy som fastsetter format og versjon, minimumsfelt, når SBOM-en genereres, hvor den lagres, hvor lenge den oppbevares og hvem som validerer den. La hver pipeline oppfylle den med den beste generatoren den kan kjøre, og mål dekningen mot policyen.

Hva bør en SBOM-policy inneholde?

Omfang, format og minimumsversjon, minimumsfelt (package URL, leverandør, versjon, deklarert lisens, avhengigheter, verktøy, tidsstempel, genereringskontekst), generering i release-bygget, full transitiv dybde, lagring sammen med releasen, oppbevaring, validering i pipelinen, eierskap og et tidsbegrenset unntaksregister.

Bør hvert team kjøre sin egen skanner, eller bør SBOM-ene komme fra bygget?

Fra bygget, der det er mulig. En SBOM fra byggetidspunktet beskriver bygget som ble levert, og gir hvert team på den pipelinen SBOM-er med samme form. Behold skannere for det du ikke bygde: images fra tredjeparter, binærfiler fra leverandører og eldre produkter uten pipeline.

En kunde vil ha SBOM-en vår i en eldre CycloneDX-versjon. Hva gjør vi?

Spør først om den nyere versjonen godtas. Hvis ikke, konverter en kopi med CycloneDX CLI (cyclonedx convert med --output-version v1_6), valider den mot den versjonen, og sjekk hvilke felt som forsvant. Behold originalen som registreringen, og lagre hvordan kopien ble avledet.

Hvordan får vi lisensdata fra SBOM-ene våre til juridisk avdeling?

Krev SPDX-lisensidentifikatorer eller -uttrykk i policyen, flagg NOASSERTION og manglende lisenser for gjennomgang, og send copyleft-lisenser til juridisk før release. SBOM-en inneholder deklarerte lisenser; fastslåtte lisenser, merknader og forpliktelser krever en lisensgjennomgang.

Hvordan måler vi SBOM-dekning på tvers av produkter?

Som brøker: releaser levert med en SBOM som oppfyller policyen, produkter med støtte som har en slik SBOM, andel bestått validering, komponenter med en package URL, komponenter med en deklarert lisens, fullstendige SBOM-er der verktøyet rapporterer det, og tiden fra release til SBOM. Rapporter dem hver måned per CI-system.

Hvilken dokumentasjon trenger vi for å vise en revisor at SBOM-genereringen er konsistent?

Policyen, unntaksregisteret, den månedlige dekningsrapporten og noen få eksempel-SBOM-er med genereringskonteksten deres. Sammen viser de én prosess, anvendt på hver release og målt, og det er det en revisor eller en kunde kontrollerer.