Er en SBOM det samme som en lisensetterlevelsesside?

En SBOM er en maskinlesbar komponentoversikt bygget for sikkerhets- og forsyningskjede-verktøy, ikke en lisensoffentliggjøring. NTIAs minimumselementer definerer den som leverandør, komponentnavn, versjon, unike identifikatorer, avhengighetsforhold og opphavsperson, som er identitetsdata for sårbarhetsmatching, ikke gjennomgått lisenstekst.

Sikkerhetsverktøy matcher CVE-er mot komponentidentiteter. CRAs Annex I-dokumentasjon forventer komponentlister i vanlig brukte formater. Sårbarhetsresponsteam sporer skadeomfanget gjennom dependency graphs.

Lisensfeltene i en SBOM er utgangspunkter, ikke godkjenninger. SPDX-identifikatorer i CycloneDX kommer ofte fra npm-registerets metadata, som ofte er feil, ufullstendig, eller merket NOASSERTION. AppSec-team legger sjelden ved fullstendig GPL- eller proprietær SDK-lisenstekst i en SBOM-eksport.

• Komponentidentitet (navn, versjon, PURL, hash) for sårbarhetsmatching.
• Leverandør- og opphavspersonmetadata for sporbarhet i forsyningskjeden.
• Maskinlesbart format (CycloneDX, SPDX) for verktøy og regulatorisk dokumentasjon.
• Grunnlag for CRAs komponentdokumentasjon og produktsikkerhetsprogrammer.
• Avviksdeteksjon når CI genererer en ny SBOM for hver bygg.
• Ikke: Menneskelesbar offentliggjøring av tredjepartslisenser for juridisk gjennomgang.
• Ikke: Fullstendig lisenstekst, notice eller navngivelsesblokker per komponent.
• Ikke: Publiseringssperrer som bekrefter at et menneske har gjennomgått hver forpliktelse.

Lisensoffentliggjøring gir gjennomgått, menneskelesbar lisenstekst, navngivelse og notice-tekster knyttet til en bestemt levert utgivelse, noe en SBOM ikke gjør. En SBOM svarer på "hvilke komponenter finnes her" for sikkerhetsverktøy; offentliggjøringen svarer på "hva er vi juridisk forpliktet til å gjengi når vi leverer dette" for innkjøp og juridisk.

Offentliggjøring av tredjepartslisenser svarer på innkjøps og juridisks spørsmål: Hvilken open source- og tredjepartsprogramvare finnes i dette produktet, under hvilke lisenser, med hvilken notice og navngivelse, per hvilken gjennomgått utgivelse.

I ingeniørteam med flere personer endrer avhengigheter seg konstant. Én ingeniør merger en patch; en annen legger til en SDK; transitive pakker skifter. En offentliggjøringsoversikt fungerer bare hvis den importeres, gjennomgås og publiseres på nytt når kodebasen endres, uansett om du hoster den på en URL eller legger ved en eksport i et spørreskjema.

• Gjennomgått oversikt per levert produkt, ikke rå registermetadata.
• Fullstendig lisenstekst for hver komponent innenfor omfanget, ikke bare SPDX-ID.
• Navngivelse og opphavsrettsmerknad der MIT, Apache, BSD, GPL krever dem.
• Copyleft- og egendefinert-lisens-rader blokkert til uttrykkelig gjennomgang.
• Tydelig produktomfang: Hvilken SKU eller utgivelse oversikten dekker.
• Publiseringsgodkjenning: Noen med ansvar før ekstern deling.
• Vedlikeholdsprosess: Oppdatering når lockfiler eller SBOM-er endres.

Ha denne tabellen for hånden når et spørreskjema ber om både "SBOM" og "open source-lisensetterlevelse." De overlapper når det gjelder oversikten, men ikke leveransen.

Nei. Du kan generere perfekte CycloneDX-filer ved hver utgivelse og likevel stryke på en innkjøpsgjennomgang som ber om lisensetterlevelse, fordi en SBOM lister komponenter, men ikke gjengir lisensteksten, notice-tekstene og navngivelsen som distribusjonsforpliktelsene krever.

Kjøperen åpner vedlegget ditt, ser komponentnavn og "MIT"-strenger, og spør hvor lisensteksten er.

CRA presser organisasjoner til å dokumentere komponenter, noe som fremskynder innføringen av SBOM. Det erstatter ikke tiår med kjøperforventninger om at leverandører vedlikeholder offentliggjøring av tredjepartslisenser. EUs produktsikkerhetsdokumentasjon og enterprise-RFP-ers lisensdeler er parallelle spor.

Sikkerhetsteam har ansvaret for sårbarhetsalvorlighet, patching og hendelsesrapportering. Lisensforpliktelser (notice, navngivelse, copyleft-betingelser) trenger en eier som gjennomgår før ekstern deling. Den eieren er sjelden den samme personen som merger Dependabot-PR-er.

Den effektive modellen importerer samme SBOM eller lockfile inn i begge pipelinene. Sikkerhet bruker SBOM-en til CVE-er og CRA-dokumentasjon. Etterlevelse importerer den samme filen inn i en gjennomgangskø: Hver komponent trenger gjennomgang, fullstendig tekst, godkjenning, og deretter publisering til en offentliggjøringsoversikt.

Når SBOM-en endres ved neste utgivelse, reagerer begge team. Sikkerhet skanner på nytt for sårbarheter. Etterlevelse gjennomgår nye eller endrede lisensrader på nytt. Én kilde til oversikten, to utdata. Ingen av utdataene erstatter den andre.

• Importer CycloneDX, SPDX eller lockfiler én gang per utgivelseskandidat.
• Sikkerhet: Sårbarhetsskanning, CRA-dokumentasjon, hendelsessporing.
• Etterlevelse: Lisensmatch, vedlegg av fullstendig tekst, copyleft-eskalering, publiseringssperre.
• Publiser offentliggjøringsoversikt fra godkjent øyeblikksbilde (side eller eksport, som kjøperen krever).
• Avvikssjekk: Flagg SBOM-endringer som mangler ny etterlevelsesgodkjenning.

Å laste opp SBOM-JSON til en leverandørportal og kalle det lisensetterlevelse. Å lime SPDX-ID-er inn i et regneark uten tekst. Å anta at en FOSSA- eller Snyk-lisensskanning tilsvarer gjennomgått offentliggjøring, uten publiseringssperrer.

Å generere en PDF fra SBOM-verktøyet én gang og gjenbruke den på tvers av utgivelser mens ingeniørene fortsetter å merge avhengigheter. Det samme problemet med utdaterte øyeblikksbilder som enhver statisk eksport, uansett format.