SBOM eller licenssida

Är en SBOM samma sak som en licenssida?

Nej. En SBOM är en maskinläsbar komponentlista för säkerhetsteam. Inköps- och juridikgranskare behöver granskad redovisning med fullständig licenstext. En annan artefakt.

Senast uppdaterad: 2 juli 2026

Säkerhetsteam, CRA-program och initiativ för leveranskedjan tar i allt högre grad fram materialförteckningar för programvara: CycloneDX, SPDX, Syft-exporter, GitHub dependency graphs. En SBOM listar komponenter (namn, versioner, hashvärden, leverantörer) och ofta ett licensfält kopierat från paketmetadata.

Inköps-, juridik- och licensefterlevnadsgranskningar efterfrågar något annat: Granskad redovisning av tredjepartslicenser med fullständig licenstext, attribuering där det krävs, och en redovisning kopplad till det du faktiskt levererar. Inte enbart en maskinläsbar fil.

Att blanda ihop de två är vanligt efter CRA-utbildning eller SOC 2-förberedelser. Team blir klara med SBOM-arbetet och antar att licensefterlevnaden är avklarad. Köpare och revisorer frågar sedan om open source-licensskyldigheter, och gapet blir synligt.

Den här sidan är den begreppsmässiga jämförelsen. Den praktiska genomgången för att omvandla en SBOM till en licenssida finns i guideavsnittet som “Från SBOM till licenssida”.

Vad används en SBOM till?

En SBOM är en maskinläsbar komponentförteckning byggd för säkerhets- och leveranskedjeverktyg, inte en licensredovisning. NTIA:s minimikrav definierar den som leverantör, komponentnamn, version, unika identifierare, beroenderelationer och upphovsman, vilket är identitetsdata för sårbarhetsmatchning snarare än granskad licenstext.

Säkerhetsverktyg matchar CVE:er mot komponentidentiteter. Dokumentation enligt CRA:s bilaga I förväntar sig komponentlistor i vanliga format. Team som hanterar sårbarheter spårar spridningsradien genom beroendegrafer.

SBOM:ens licensfält är utgångspunkter, inte godkännanden. SPDX-identifierare i CycloneDX kommer ofta från npm-registrets metadata, som ofta är felaktig, ofullständig eller märkt NOASSERTION. AppSec-team bifogar sällan fullständig licenstext för GPL eller proprietära SDK:er till en SBOM-export.

Komponentidentitet (namn, version, PURL, hash) för sårbarhetsmatchning.
Metadata om leverantör och upphovsman för spårbarhet i leveranskedjan.
Maskinläsbart format (CycloneDX, SPDX) för verktyg och regulatorisk dokumentation.
Underlag till CRA:s komponentdokumentation och produktsäkerhetsprogram.
Avvikelsedetektering när CI genererar en ny SBOM för varje bygge.
Inte: Människoläsbar redovisning av tredjepartslicenser för juridisk granskning.
Inte: Fullständig licenstext, meddelande eller attribueringsblock per komponent.
Inte: Publiceringsgrindar som bekräftar att en människa granskat varje skyldighet.

Vad ger redovisning av tredjepartslicenser som en SBOM inte gör?

Licensredovisning ger granskad, människoläsbar licenstext, attribuering och meddelanden kopplade till en specifik levererad release, vilket en SBOM inte gör. En SBOM besvarar “vilka komponenter finns här” för säkerhetsverktyg. Redovisningen besvarar “vad är vi juridiskt skyldiga att återge när vi levererar det här” för inköp och juridik.

Redovisning av tredjepartslicenser besvarar inköps- och juridikfrågor: Vilken open source- och tredjepartsmjukvara som finns i produkten, under vilka licenser, med vilket meddelande och vilken attribuering, från och med vilken granskad release.

I utvecklingsteam med flera personer ändras beroenden ständigt. En utvecklare mergar en patch, en annan lägger till en SDK, transitiva paket förskjuts. En redovisning fungerar bara om den importeras, granskas och publiceras på nytt när kodbasen ändras, oavsett om du hostar den på en URL eller bifogar en export till ett frågeformulär.

Granskad förteckning per levererad produkt, inte rå registermetadata.
Fullständig licenstext för varje komponent inom omfånget, inte enbart SPDX-ID.
Attribuering och upphovsrättsmeddelande där MIT, Apache, BSD eller GPL kräver dem.
Rader med copyleft och egna licenser blockeras tills uttrycklig granskning skett.
Tydligt produktomfång: Vilket SKU eller vilken release redovisningen omfattar.
Publiceringsgodkännande: Någon ansvarig innan extern delning.
Underhållsprocess: Uppdatera när lockfiles eller SBOM:er ändras.

Sida vid sida: SBOM jämfört med licensefterlevnadsredovisning

Ha den här tabellen till hands när ett frågeformulär efterfrågar både “SBOM” och “open source-licensefterlevnad”. De överlappar i förteckningen men inte i leveransen.

	SBOM	Granskad licensredovisning
Primär målgrupp	Säkerhetsteam och CRA-program	Inköps- och juridikgranskare
Format	Maskinläsbar JSON eller XML	Läsbar sida eller granskad export
Licensfält	En identifierarledtråd från registrets metadata	Fullständig licenstext efter mänsklig granskning
Granskning	Ofta helt automatiserad	En mänsklig grind innan något publiceras
CRA-sammanhang	Komponentdokumentation enligt bilaga I	En separat, långvarig förväntning från köpare
Uppdateringar	Genereras på nytt per bygge	Omgranskade skyldigheter, inte bara en diff

Uppfyller ett avslutat SBOM-program licensefterlevnad?

Nej. Du kan generera perfekta CycloneDX-filer vid varje release och ändå underkännas i en inköpsgranskning som efterfrågar licensefterlevnad, eftersom en SBOM listar komponenter men inte återger den licenstext, de meddelanden och den attribuering som distributionsskyldigheter kräver.

Köparen öppnar din bilaga, ser komponentnamn och strängar som “MIT”, och frågar var licenstexten är.

CRA driver organisationer att dokumentera komponenter, vilket påskyndar SBOM-adoptionen. Det ersätter inte decennier av köparförväntningar på att leverantörer underhåller redovisning av tredjepartslicenser. EU:s produktsäkerhetsdokumentation och licensavsnitt i enterprise-RFP:er är parallella spår.

Säkerhetsteam äger frågor om sårbarheters allvarlighetsgrad, patchning och incidentrapportering. Licensskyldigheter (meddelande, attribuering, copyleft-villkor) behöver en ägare som granskar innan extern delning. Den ägaren är sällan samma person som mergar Dependabot-PR:ar.

Hur SBOM- och licensarbetsflöden hänger ihop

Den effektiva modellen importerar samma SBOM eller lockfile till båda flödena. Säkerhet använder SBOM:en för CVE:er och CRA-dokumentation. Efterlevnad importerar samma fil till en granskningskö: Varje komponent behöver granskas, förses med fullständig text, godkännas, och sedan publiceras till en redovisning.

När SBOM:en ändras vid nästa release reagerar båda teamen. Säkerhet omskannar efter sårbarheter. Efterlevnad granskar nya eller ändrade licensrader på nytt. En förteckningskälla, två utdata. Inget av utdatan ersätter det andra.

Importera CycloneDX, SPDX eller lockfiles en gång per releasekandidat.
Säkerhet: Sårbarhetsskanning, CRA-dokumentation, spårbarhet vid incidenter.
Efterlevnad: Licensmatchning, bifogande av fullständig text, eskalering av copyleft, publiceringsgrind.
Publicera redovisningen från en godkänd ögonblicksbild (sida eller export enligt köparens krav).
Avvikelsekontroll: Flagga SBOM-ändringar som saknar förnyat godkännande för efterlevnad.

Vanliga misstag

Att ladda upp SBOM-JSON till en leverantörsportal och kalla det licensefterlevnad. Att klistra in SPDX-ID:n i ett kalkylblad utan text. Att anta att en licensskanning i FOSSA eller Snyk motsvarar granskad redovisning, utan publiceringsgrindar.

Att generera en PDF från SBOM-verktyg en gång och återanvända den över flera releaser medan utvecklare fortsätter merga beroenden. Samma problem med inaktuella ögonblicksbilder som vilken statisk export som helst, oavsett format.