Software Bill of Materials (SBOM)

Una distinta base del software (Software Bill of Materials, SBOM) è un inventario formale e leggibile dalle macchine di ogni componente contenuto in un software: librerie, relative versioni, licenze e informazioni sul fornitore.

Proprio come un'etichetta alimentare elenca gli ingredienti, un SBOM consente di rispondere in pochi secondi alla domanda: questo prodotto contiene la versione vulnerabile di X? Senza un SBOM, la risposta può richiedere giorni di analisi manuale.

Quando viene scoperta una vulnerabilità critica, la prima domanda operativa riguarda l'esposizione: quali dei nostri prodotti distribuiscono il componente interessato?

Durante l'incidente Log4Shell, le organizzazioni dotate di SBOM hanno interrogato il proprio inventario e definito le priorità nel giro di poche ore. Quelle che ne erano prive hanno trascorso settimane a cercare nelle directory di build con grep. Le autorità di regolamentazione e i principali acquirenti richiedono sempre più spesso gli SBOM come condizione per l'approvvigionamento.

• Analisi rapida dell'impatto delle vulnerabilità
• Conformità alle licenze e tracciamento degli obblighi
• Trasparenza della catena di approvvigionamento per clienti e auditor

Dominano due standard aperti. Gli strumenti sono generalmente in grado di convertirli da uno all'altro.

• SPDX — uno standard della Linux Foundation, particolarmente efficace nella gestione delle licenze e ampiamente accettato dalle autorità di regolamentazione
• CycloneDX — uno standard OWASP orientato alla sicurezza, che supporta i dati sulle vulnerabilità e sulle relazioni tra dipendenze

Eviti di inventare un formato personalizzato: chi utilizza questi dati e gli scanner si aspettano questi standard.

Ogni voce del componente deve contenere informazioni identificative sufficienti per il confronto con i feed delle vulnerabilità. I campi principali sono:

• nome e versione — esatti, non un intervallo
• PURL (package URL) — un identificatore universale come pkg:npm/lodash@4.17.21
• hash — per verificare l'integrità
• licenza — identificatore di licenza SPDX
• fornitore — chi lo ha prodotto

Generi gli SBOM automaticamente dal codice sorgente o da un artefatto compilato. Syft è un generatore comune per diversi ecosistemi, in grado di produrre entrambi gli standard.

Un SBOM generato in fasi diverse rappresenta aspetti diversi della realtà.

• SBOM del codice sorgente — ciò che dichiara il manifest; può non includere codice aggregato o incluso direttamente nel progetto
• SBOM della build — ciò che la build ha effettivamente acquisito; è il più accurato per la release
• SBOM di runtime / distribuito — ciò che è effettivamente presente nell'immagine in esecuzione, inclusi i pacchetti del sistema operativo

Per garantire la sicurezza della catena di approvvigionamento, generi l'SBOM durante la build a partire dall'artefatto reale e analizzi anche il container finale alla ricerca dei pacchetti a livello di sistema operativo.

Un SBOM diventa potente quando viene fornito a un motore di matching che associa i componenti alle CVE note. In questo modo la generazione è separata dall'analisi: può scansionare un SBOM precedente il giorno in cui viene pubblicata una nuova CVE.

Un SBOM può mostrare un componente vulnerabile che non è effettivamente sfruttabile nel Suo prodotto (la funzione vulnerabile non viene mai chiamata). Un documento VEX (Vulnerability Exploitability eXchange) registra questa valutazione.

VEX riduce il rumore: invece di lasciare che ogni cliente si allarmi per una CVE elencata, può pubblicare una dichiarazione not_affected con la relativa motivazione, oppure affected con le misure correttive. Trasforma un inventario grezzo in un triage operativo.

Un SBOM è affidabile solo se è autentico e associato all'artefatto esatto che descrive. Lo firmi e lo alleghi come attestazione, anziché conservarlo come file separato.

Gli SBOM generati manualmente diventano immediatamente obsoleti. Integri la generazione nella pipeline, così ogni release ne produce e ne archivia uno come artefatto di build, idealmente firmandolo e analizzandolo nello stesso job.

• Generi l'SBOM dall'artefatto compilato, non solo dal repository
• Conservi gli SBOM in un registry interrogabile, indicizzato per versione
• Ripeta periodicamente la scansione degli SBOM archiviati utilizzando feed CVE aggiornati
• Blocchi le release in base al risultato della scansione delle vulnerabilità

Gli SBOM falliscono silenziosamente quando vengono trattati come una semplice casella da spuntare.

• Obsoleto — generato una volta e mai più rigenerato
• Incompleto — non include pacchetti del sistema operativo, codice collegato staticamente o incluso direttamente nel progetto
• Non verificato — non contiene un hash che lo colleghi all'artefatto distribuito
• Inutilizzato — prodotto, ma mai analizzato o interrogato

L'obiettivo è un SBOM accurato, rigenerato, firmato e sottoposto continuamente a scansione, non un file JSON creato una tantum.

Ora è in grado di inventariare il contenuto del Suo software e di agire di conseguenza.

• Un SBOM è un elenco leggibile dalle macchine di ogni componente, in formato SPDX o CycloneDX
• Identifichi i componenti tramite PURL, versione, hash e licenza
• Generi l'SBOM durante la build, quindi lo fornisca a un motore di matching (grype, osv-scanner) per individuare le CVE
• Utilizzi VEX per dichiarare la reale sfruttabilità e ridurre i falsi allarmi
• Firmi e automatizzi nella CI; ripeta la scansione degli SBOM archiviati utilizzando nuovi feed

Successivamente dimostrerà da dove provengono gli artefatti tramite la firma.