SBOM: informazioni sui componenti, formati e manutenzione
Sytance · Aggiornato
Una distinta base software (SBOM) descrive i componenti software che costituiscono un’applicazione o un sistema e le relazioni tra loro. Offre al team un punto di partenza per l’inventario dei componenti, la revisione delle licenze e l’analisi delle vulnerabilità. Il suo valore dipende dalla precisione con cui descrive il software effettivamente consegnato.
Il prodotto descritto da una SBOM
Una SBOM descrive una specifica versione del prodotto, build o artefatto, come un’immagine firmware o un pacchetto d’installazione. Le voci dei componenti identificano le librerie e gli altri software compresi in tale ambito. Versioni, produttori, identificativi e relazioni aiutano a spiegare cosa è stato incluso.
Nell’esempio fittizio di un gateway industriale, il prodotto di destinazione è la release firmware. L’applicazione di gestione e le librerie incorporate sono componenti. Un servizio di telemetria remoto è una dipendenza esterna; descriverlo non significa che i suoi pacchetti lato server siano contenuti nel firmware.
L’esempio pubblico usa componenti inventati per rendere leggibile la struttura. Non è un inventario dei componenti di Sytance né di un gateway rilasciato.
Identificativi dei componenti
Due pacchetti con nomi simili possono appartenere a ecosistemi di pacchetti diversi. Package URL (purl) identifica un pacchetto usando campi quali tipo, namespace, nome e versione. Un hash di file aiuta a identificare un file esatto se si conoscono l’algoritmo di hash e il file sottoposto ad hashing.
Usare i metadati del pacchetto o le informazioni del fornitore per determinare gli identificativi. Un purl composto sulla base di un fornitore presunto può puntare al pacchetto sbagliato. Conservare la stringa di versione originale, poiché una build successiva può includere una propria revisione della patch.
SPDX e CycloneDX rappresentano entrambi informazioni sui componenti software e sulle relative relazioni. I campi disponibili e il loro significato esatto dipendono dalla versione del formato. Scegliere una versione elaborabile dagli strumenti di produzione e ricezione.
Precisione e copertura dell’inventario
Un file può essere JSON valido e descrivere comunque la release sbagliata. Confrontare la SBOM con gli input di build e l’artefatto distribuito, quindi indagare le discrepanze. Un elenco delle dipendenze del codice sorgente può contenere strumenti di sviluppo mai distribuiti e omettere librerie copiate nell’immagine.
- Destinazione: prodotto, versione e artefatto corrispondono alla release.
- Identità: versioni e identificativi dei componenti sono riconducibili a evidenze.
- Relazioni: i percorsi di dipendenza sono presenti e significativi.
- Copertura: sono visibili i dati mancanti dei fornitori e le parti non analizzate.
- Scambio: lo strumento ricevente conserva i campi necessari all’uso previsto.
Elementi minimi della SBOM 2026
La guida intitolata 2026 SBOM Minimum Elements, pubblicata congiuntamente da CISA e dalle agenzie partner, aggiorna le indicazioni NTIA del 2021. Affronta i metadati del documento, i dati dei componenti e le pratiche per mantenere e condividere le SBOM. È una guida e dichiara di non introdurre nuovi requisiti.
Per una consegna, indicare la specifica, la versione del formato e gli ulteriori requisiti concordati con il cliente. Il solo esito della convalida dello schema non dimostra che le informazioni richieste dal cliente siano complete.
Corrispondenze delle vulnerabilità e impatto sul prodotto
Una corrispondenza di vulnerabilità collega un problema segnalato all’identità o alla versione di un componente. La domanda successiva è se il codice interessato sia presente e sfruttabile in questo prodotto. Verificare opzioni di build, modifiche, percorsi di esecuzione e condizioni indicate nell’avviso.
Vulnerability Exploitability eXchange (VEX) comunica la valutazione di una specifica vulnerabilità per i prodotti identificati. Mantenere tale valutazione collegata alla release e all’analisi di supporto. L’assenza di corrispondenze può dipendere da copertura limitata o identificativi incompleti.
Documenti per le release supportate
Archiviare l’inventario originale con la release. Se nuove informazioni correggono la SBOM senza modificare il software, emettere una revisione documentale tracciabile. Se cambia il software, creare un record per la nuova release.
Quando un nuovo avviso identifica una vulnerabilità di un componente, cercare negli inventari di tutte le release supportate. I clienti potrebbero ancora usare una release precedente con componenti diversi da quelli del prodotto corrente.