SBOM-import

Fra SBOM eller lockfile til en etterlevelsesside

Hvis du allerede genererer CycloneDX, npm-lockfiler eller lignende data, her er hvordan du gjør dem om til en gjennomgått offentliggjøringsoversikt.

Sist oppdatert: 2. juli 2026

Hvis dere allerede genererer CycloneDX SBOM-er, SPDX-filer, eller eksporter fra FOSSA, Snyk, Mend eller Syft, har dere råmaterialet for lisensetterlevelse. En komponentoversikt (SBOM) lister komponenter: Navn, versjoner, leverandører, hasher. En lisensetterlevelsesside legger til gjennomgåtte lisensidentifikatorer, fullstendig lisenstekst, navngivelse, og en stabil URL for offentliggjøring av tredjepartslisenser.

SBOM-arbeid støtter sikkerhets- og regelverksprogrammer (inkludert CRA-komponentdokumentasjon). Lisensetterlevelsessider svarer på innkjøps og juridisks spørsmål om open source-lisensforpliktelser. Veien fra SBOM til etterlevelsesside er import, berikelse, gjennomgang, publisering. Ikke eksporter-og-last-opp-uendret.

Hva er forskjellen mellom en SBOM og en lisensetterlevelsesside?

En SBOM er en maskinlesbar oversikt optimalisert for sårbarhetsmatching og forsyningskjede-verktøy; en lisensetterlevelsesside er en menneskelesbar offentliggjøring av tredjepartslisenser, optimalisert for innkjøpsansvarlige som åpner en nettleserfane under leverandør-due-diligence. De svarer på ulike spørsmål og kan sjelden erstatte hverandre.

Kjøpere ber om begge deler i ulike deler av spørreskjemaet. Å kun levere en SBOM når de ber om en open source-lisensside, tvinger dem til å jage etter fullstendig lisenstekst manuelt, eller til å underkjenne deg for ufullstendig offentliggjøring.

	SBOM	Etterlevelsesside
Innhold	Komponentidentitet, versjoner, hasher, leverandører	Gjennomgåtte lisenser, fullstendig lisenstekst, navngivelse, produktomfang
Format	JSON eller XML, oppdatert av CI	Offentlig URL med publiseringssperrer, pluss eksporter per utgivelse
Målgruppe	Sikkerhetsverktøy og CRA-programmer	Innkjøps- og juridisk-ansvarlige

Steg 1: Importer SBOM eller lockfile

Ta med CycloneDX, SPDX eller pakke-lockfiler inn i offentliggjøringsarbeidsflyten deres. Koble SBOM-komponenter til rader i gjennomgangskøen deres. Hver rad starter som trenger gjennomgang. Lisensfeltene i SBOM-en er hint, ikke godkjenninger.

Én SBOM per produkt per utgivelse. Ikke slå sammen ubeslektede produkter i én lisensetterlevelsesside, med mindre offentliggjøringsmodellen deres uttrykkelig avgrenser seksjoner. Innkjøp forventer klarhet.

Importer fra CI-artefakt, utgivelses-tag, eller eksport fra SBOM-verktøy.
Behold komponentnavn, versjon og PURL eller tilsvarende identifikator.
Bruk lisensfeltet i SBOM-en som utgangspunkt, ikke som endelig svar.
Flagg komponenter med manglende, motstridende eller NOASSERTION-lisensdata.
Importer på nytt ved hver utgivelse. Ikke lapp sammen utdatert JSON manuelt på ubestemt tid.

Steg 2: Berik og gjennomgå

SBOM-er inkluderer ofte SPDX-lisensidentifikatorer uten fullstendig lisenstekst. Offentliggjøring av tredjepartslisenser krever tekst innkjøp kan lese. Berik hver godkjent komponent med fullstendig lisensinnhold, navngivelsestekst og copyleft-flagg fra gjennomgangsrutinene deres.

Avklar konflikter mellom register- og repo-lisenser. Eskaler egendefinerte lisenser og copyleft-lisenser. Etterlevelsen svikter når SBOM-metadata kopieres til en offentlig side uten menneskelig verifisering.

Legg ved fullstendig lisenstekst for hver godkjent komponent.
Bekreft lisensen mot LICENSE-filen i repoet, leverandørens PDF, eller juridisk veiledning.
Bruk regler for gjennomgang av copyleft og distribusjon før godkjenning.
Legg til notice- og navngivelsesblokker der det kreves.
Dokumenter utelatelser: Dev-avhengigheter som ikke leveres, pakker som kun brukes til testing, osv.
Blokker publisering til null ikke-gjennomgåtte rader innenfor omfanget gjenstår.

Steg 3: Publiser lisensetterlevelsesside og eksporter

Fra den samme godkjente oversikten, publiser vedlikeholdt offentliggjøring og utgivelseseksporter. Del det formatet due diligence ber om, URL, PDF eller pakke. Eksportene kan legges ved saker, utgivelsesnotater eller leverandørportaler.

Når SBOM-en endres ved neste utgivelse (nye pakker, versjonsoppdateringer, lisensendringer), re-importer, gjennomgå på nytt, publiser på nytt. Avvikssjekker automatiserer sammenligningen, slik at dere ikke blir overrasket ved en kunderevisjon.

Publiser delbar dokumentasjon per produkt (hostet side og/eller eksporter).
Verifiser at offentliggjøringen laster, at fullstendig tekst vises, og at produktomfanget er tydelig.
Eksporter JSON, navngivelsesfiler og offentliggjøringspakker fra samme øyeblikksbilde.
Sett opp CI til å flagge når SBOM-en avviker fra den sist godkjente publiseringen.
Del gjennomgått offentliggjøring med innkjøp, ikke en rå SBOM, når de ber om dokumentasjon på lisensetterlevelse.

Verktøy dere allerede bruker

FOSSA, Snyk, Mend, Syft, GitHub dependency graph, og interne CI-pipelines produserer SBOM-er og lisensindikasjoner. SourceTrust og lignende arbeidsflyter for offentliggjøring ligger lenger nede i kjeden: Gjennomgått publiseringsoversikt, URL til etterlevelsesside, eksporter på linje med det som faktisk leveres.

Dere erstatter ikke SBOM-verktøyet deres. Dere gjør resultatet om til offentliggjøring av tredjepartslisenser som kundene og revisorene deres kan bruke. Lisensetterlevelse som en vedlikeholdt produktartefakt, ikke en engangs filutlevering.