Er en SBOM det samme som en licensside?

En SBOM er en maskinlæsbar komponentoversigt bygget til sikkerheds- og forsyningskædeværktøjer, ikke en licensoplysning. NTIA's minimumselementer definerer den som leverandør, komponentnavn, version, unikke id'er, afhængighedsforhold og forfatter, hvilket er identitetsdata til sårbarhedsmatching frem for gennemgået licenstekst.

Sikkerhedsværktøjer matcher CVE'er til komponentidentiteter. CRA's Bilag I-dokumentation forventer komponentlister i almindeligt anvendte formater. Teams, der håndterer sårbarheder, sporer skadesomfanget gennem afhængighedsgrafer.

SBOM'ens licensfelter er udgangspunkter, ikke godkendelser. SPDX-id'er i CycloneDX stammer ofte fra npm-registrets metadata, som ofte er forkert, ufuldstændigt eller markeret NOASSERTION. AppSec-teams vedhæfter sjældent fuld GPL- eller proprietær SDK-licenstekst til en SBOM-eksport.

• Komponentidentitet (navn, version, PURL, hash) til sårbarhedsmatching.
• Leverandør- og forfattermetadata til sporbarhed i forsyningskæden.
• Maskinlæsbart format (CycloneDX, SPDX) til værktøjer og regulatorisk dokumentation.
• Input til CRA-komponentdokumentation og produktsikkerhedsprogrammer.
• Afvigelsesdetektion, når CI genererer en ny SBOM ved hver build.
• Ikke: Menneskelæsbar oplysning om tredjepartslicenser til juridisk gennemgang.
• Ikke: Fuld licenstekst, licensmeddelelser eller blokke med kildeangivelse pr. komponent.
• Ikke: Udgivelseskontrol, der bekræfter, at et menneske har gennemgået hver forpligtelse.

Licensoplysning giver gennemgået, menneskelæsbar licenstekst, kildeangivelse og licensmeddelelser knyttet til en bestemt udgivelse i produktion, hvilket en SBOM ikke gør. En SBOM besvarer “hvilke komponenter er her” til sikkerhedsværktøjer. Oplysning besvarer “hvad er vi juridisk forpligtet til at gengive, når vi sender dette i produktion” til indkøb og jura.

Oplysning om tredjepartslicenser besvarer indkøbs og juras spørgsmål: Hvilken open source- og tredjepartssoftware er der i dette produkt, under hvilke licenser, med hvilke licensmeddelelser og hvilken kildeangivelse, og for hvilken gennemgået udgivelse.

I udviklingsteams med flere personer ændrer afhængigheder sig konstant. Én udvikler fletter en rettelse ind, en anden tilføjer et SDK, og transitive pakker skifter. En oplysningsregistrering virker kun, hvis den genimporteres, gennemgås igen og genudgives, når kodebasen ændrer sig, uanset om I hoster den på en URL eller vedhæfter en eksport til et spørgeskema.

• Gennemgået oversigt pr. produkt i produktion, ikke rå registermetadata.
• Fuld licenstekst for hver omfattet komponent, ikke kun SPDX-id.
• Kildeangivelse og ophavsretsmeddelelse, hvor MIT, Apache, BSD eller GPL kræver det.
• Rækker med copyleft og specialtilpassede licenser spærret indtil udtrykkelig gennemgang.
• Klart produktomfang: Hvilket SKU eller hvilken udgivelse registreringen dækker.
• Godkendelse af udgivelse: Nogen med ansvar, før ekstern deling.
• Vedligeholdelsesproces: Opdatering, når lockfiles eller SBOM'er ændrer sig.

Hav denne tabel ved hånden, når et spørgeskema beder om både en SBOM og dokumentation for licensoverholdelse. De overlapper på oversigten, men ikke på leverancen.

Nej. I kan generere perfekte CycloneDX-filer ved hver udgivelse og stadig fejle en indkøbsgennemgang, der kræver licensoverholdelse, fordi en SBOM lister komponenter, men ikke gengiver licensteksten, licensmeddelelserne og den kildeangivelse, som distributionsforpligtelserne kræver.

Køberen åbner jeres vedhæftning, ser komponentnavne og “MIT”-strenge, og spørger, hvor licensteksten er.

CRA skubber organisationer til at dokumentere komponenter og øger dermed udbredelsen af SBOM'er. Det erstatter ikke årtiers forventning fra købere om, at leverandører vedligeholder oplysning om tredjepartslicenser. EU's produktsikkerhedsdokumentation og licensafsnit i store virksomheders udbud er parallelle spor.

Sikkerhedsteams ejer sårbarhedsalvorlighed, rettelser og hændelsesrapportering. Licensforpligtelser (licensmeddelelser, kildeangivelse og copyleft-betingelser) har brug for en ejer, der gennemgår dem før ekstern deling. Det er sjældent den samme person, der fletter Dependabot-PR'er ind.

Den effektive model importerer den samme SBOM eller lockfile i begge arbejdsgange. Sikkerhed bruger SBOM'en til CVE'er og CRA-dokumentation. Licensteamet importerer den samme fil til en gennemgangskø: Hver komponent skal gennemgås, have fuld tekst, godkendes og derefter udgives i en oplysningsregistrering.

Når SBOM'en ændrer sig ved næste udgivelse, reagerer begge teams. Sikkerhed scanner igen for sårbarheder. Licensteamet gennemgår nye eller ændrede licensrækker igen. Én oversigtskilde, to resultater. Resultaterne erstatter ikke hinanden.

• Importér CycloneDX, SPDX eller lockfiles én gang pr. udgivelseskandidat.
• Sikkerhed: Sårbarhedsscan, CRA-dokumentation, hændelsessporbarhed.
• Compliance: Match licenser, vedhæft fuld tekst, eskalér copyleft og kontrollér før udgivelse.
• Udgiv oplysningsregistreringen fra den godkendte udgivelse (side eller eksport, som køberen kræver).
• Afvigelsestjek: Flag SBOM-ændringer, der mangler compliance-gengodkendelse.

At uploade SBOM-JSON til en leverandørportal og kalde det licensoverholdelse. At indsætte SPDX-id'er i et regneark uden tekst. At gå ud fra, at et FOSSA- eller Snyk-licensscan svarer til gennemgået oplysning uden kontrol før udgivelse.

At generere en PDF fra SBOM-værktøjer én gang og genbruge den på tværs af udgivelser, mens udviklere bliver ved med at flette ændringer i afhængigheder ind. Det giver samme problem med forældede snapshots som enhver anden statisk eksport, uanset format.