Uno SBOM è la stessa cosa di una pagina di conformità delle licenze?

Uno SBOM è un inventario di componenti leggibile dalle macchine, costruito per gli strumenti di sicurezza e supply chain, non per la divulgazione delle licenze. Gli elementi minimi NTIA lo definiscono come fornitore, nome del componente, versione, identificatori univoci, relazioni di dipendenza e autore, che è un dato di identità per il confronto con le vulnerabilità, non testo di licenza rivisto.

Gli strumenti di sicurezza abbinano i CVE alle identità dei componenti. La documentazione dell'Allegato I del CRA si aspetta elenchi di componenti in formati comunemente usati. I team di risposta alle vulnerabilità tracciano il raggio d'impatto attraverso i dependency graph.

I campi di licenza dello SBOM sono punti di partenza, non approvazioni. Gli identificatori SPDX in CycloneDX provengono spesso dai metadati del registro npm, che sono frequentemente errati, incompleti o contrassegnati come NOASSERTION. I team AppSec allegano raramente il testo completo delle licenze GPL o SDK proprietarie a un'esportazione SBOM.

• Identità del componente (nome, versione, PURL, hash) per il confronto con le vulnerabilità.
• Metadati di fornitore e autore per la tracciabilità della supply chain.
• Formato leggibile dalle macchine (CycloneDX, SPDX) per strumenti e documentazione normativa.
• Input per la documentazione dei componenti del CRA e i programmi di sicurezza di prodotto.
• Rilevamento della deriva quando la CI genera un nuovo SBOM a ogni build.
• Non: divulgazione delle licenze di terze parti leggibile dagli esseri umani per la revisione legale.
• Non: testo completo delle licenze, avviso o blocchi di attribuzione per ogni componente.
• Non: barriere di pubblicazione che confermano che un essere umano ha rivisto ogni obbligo.

La divulgazione delle licenze fornisce testo di licenza rivisto e leggibile dagli esseri umani, attribuzione e avvisi legati a una release rilasciata specifica, cosa che uno SBOM non fa. Uno SBOM risponde a "quali componenti ci sono qui" per gli strumenti di sicurezza; la divulgazione risponde a "a cosa siamo legalmente obbligati a riprodurre quando lo rilasciamo" per acquisti e legale.

La divulgazione delle licenze di terze parti risponde alle domande di acquisti e legale: quale software open source e di terze parti c'è in questo prodotto, sotto quali licenze, con quale avviso e attribuzione, a partire da quale release rivista.

Nei team di ingegneria con più persone, le dipendenze cambiano continuamente. Un ingegnere fa il merge di una patch; un altro aggiunge un SDK; i pacchetti transitivi cambiano. Un registro di divulgazione funziona solo se viene reimportato, rivisto e ripubblicato quando la codebase cambia, che tu lo ospiti su un URL o alleghi un'esportazione a un questionario.

• Inventario rivisto per ogni prodotto rilasciato, non metadati grezzi del registro.
• Testo completo della licenza per ogni componente in ambito, non solo l'ID SPDX.
• Attribuzione e avviso di copyright dove MIT, Apache, BSD, GPL li richiedono.
• Righe con copyleft e licenze personalizzate bloccate finché non c'è una revisione esplicita.
• Ambito del prodotto chiaro: quale SKU o release copre il registro.
• Approvazione della pubblicazione: qualcuno responsabile prima della condivisione esterna.
• Processo di manutenzione: aggiornamento quando lockfile o SBOM cambiano.

Tieni a portata di mano questa tabella quando un questionario chiede sia "SBOM" sia "conformità delle licenze open source". Si sovrappongono sull'inventario ma non sul deliverable.

No. Puoi generare file CycloneDX perfetti a ogni release e comunque fallire una revisione degli acquisti che chiede la conformità delle licenze, perché uno SBOM elenca i componenti ma non riproduce il testo delle licenze, gli avvisi e l'attribuzione richiesti dagli obblighi di distribuzione.

L'acquirente apre il tuo allegato, vede i nomi dei componenti e le stringhe "MIT", e chiede dov'è il testo della licenza.

Il CRA spinge le organizzazioni a documentare i componenti, il che accelera l'adozione degli SBOM. Non sostituisce decenni di aspettative degli acquirenti che i fornitori mantengano la divulgazione delle licenze di terze parti. La documentazione di sicurezza di prodotto dell'UE e le sezioni sulle licenze delle RFP enterprise sono binari paralleli.

I team di sicurezza sono responsabili della gravità delle vulnerabilità, delle patch, della segnalazione degli incidenti. Gli obblighi di licenza (avviso, attribuzione, condizioni di copyleft) hanno bisogno di un responsabile che li rivede prima della condivisione esterna. Quel responsabile è raramente la stessa persona che fa il merge delle PR di Dependabot.

Il modello efficiente importa lo stesso SBOM o lockfile in entrambe le pipeline. La sicurezza consuma lo SBOM per i CVE e la documentazione CRA. La conformità importa lo stesso file in una coda di revisione: ogni componente ha bisogno di revisione, testo completo, approvazione, poi pubblicazione in un registro di divulgazione.

Quando lo SBOM cambia nella release successiva, entrambi i team reagiscono. La sicurezza riesegue la scansione delle vulnerabilità. La conformità rivede le righe di licenza nuove o cambiate. Un'unica fonte di inventario, due output. Nessuno dei due output sostituisce l'altro.

• Importa CycloneDX, SPDX o lockfile una volta per ogni release candidate.
• Sicurezza: scansione delle vulnerabilità, documentazione CRA, tracciabilità degli incidenti.
• Conformità: corrispondenza della licenza, allegato del testo completo, escalation del copyleft, barriera di pubblicazione.
• Pubblica il registro di divulgazione dall'istantanea approvata (pagina o esportazione secondo quanto richiesto dall'acquirente).
• Controllo di deriva: segnala i cambiamenti dello SBOM privi di una nuova approvazione di conformità.

Caricare il JSON dello SBOM su un portale fornitori e chiamarlo conformità delle licenze. Incollare gli ID SPDX in un foglio di calcolo senza il testo. Dare per scontato che una scansione delle licenze di FOSSA o Snyk equivalga a una divulgazione rivista senza barriere di pubblicazione.

Generare un PDF dagli strumenti SBOM una volta e riutilizzarlo tra le release mentre gli ingegneri continuano a fare il merge delle dipendenze. Lo stesso problema dell'istantanea obsoleta di qualsiasi esportazione statica, indipendentemente dal formato.