Er en SBOM det samme som en licens-compliance-side?

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 dependency graphs.

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, notice eller kildeangivelsesblokke pr. komponent.
• Ikke: Publish-gates, der bekræfter, at et menneske har gennemgået hver forpligtelse.

Licensoplysning giver gennemgået, menneskelæsbar licenstekst, kildeangivelse og notices knyttet til en specifik 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 hvilken notice og kildeangivelse, pr. hvilken gennemgået udgivelse.

I engineering-teams med flere personer ændrer afhængigheder sig konstant. Én udvikler merger en patch, en anden tilføjer en SDK, transitive pakker skifter. En oplysningsregistrering fungerer 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 copyright-notice, hvor MIT, Apache, BSD, 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 “SBOM” og “open source-licens-compliance.” 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 beder om licens-compliance, fordi en SBOM lister komponenter, men ikke gengiver den licenstekst, de notices og den kildeangivelse, distributionsforpligtelser 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, hvilket accelererer udbredelsen af SBOM'er. Det erstatter ikke årtiers forventning fra købere om, at leverandører vedligeholder oplysning om tredjepartslicenser. EU's produktsikkerhedsdokumentation og enterprise-RFP'ers licensafsnit er parallelle spor.

Sikkerhedsteams ejer sårbarhedsalvorlighed, patching, hændelsesrapportering. Licensforpligtelser (notice, kildeangivelse, copyleft-betingelser) har brug for en ejer, der gennemgår før ekstern deling. Den ejer er sjældent den samme person, der merger Dependabot-PR'er.

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

Når SBOM'en ændrer sig ved den næste udgivelse, reagerer begge teams. Sikkerhed genscanner for sårbarheder. Compliance gennemgår nye eller ændrede licensrækker igen. Én oversigtskilde, to output. Ingen af outputtene erstatter det andet.

• Importér CycloneDX, SPDX eller lockfiles én gang pr. release-kandidat.
• Sikkerhed: Sårbarhedsscan, CRA-dokumentation, hændelsessporbarhed.
• Compliance: Licensmatch, vedhæftning af fuld tekst, eskalering af copyleft, publish-gate.
• Udgiv oplysningsregistreringen fra det godkendte snapshot (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 licens-compliance. 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 publish-gates.

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 merge afhængigheder. Det samme problem med forældede øjebliksbilleder som enhver statisk eksport, uanset format.