Completezza della SBOM

Una SBOM è completa quando elenca ogni componente entrato nel software che descrive, a ogni livello dell'albero delle dipendenze, compresi i componenti che nessun lockfile o manifest elenca. La completezza della SBOM è questa proprietà. I 2026 Minimum Elements della CISA chiedono agli autori di SBOM di indicare esplicitamente quando un'informazione è sconosciuta, e osservano che i destinatari possono considerare incompleta una SBOM se vengono trattenuti dati essenziali sui componenti.

Completezza, validità e qualità sono cose diverse

Domanda	Che cosa significa	Che cosa la verifica	Che cosa non può dire
Valida	Il file è conforme allo schema CycloneDX o SPDX	Un validatore di schema	Se mancano componenti
Qualità dei campi	Ogni componente ha nome, versione, fornitore, identificatore, licenza e hash	Uno strumento di valutazione della qualità	Se mancano componenti
Completa	Non manca nulla di ciò che è entrato nel software	Un confronto con ciò che la build ha davvero ricevuto	Gli input che il confronto non ha visto

L'identificatore della seconda riga è di solito un package URL o un CPE. Un file può superare perfettamente i primi due controlli e lasciare comunque fuori metà del software.

Perché la completezza è difficile da misurare a posteriori

Uno scanner lavora su lockfile, manifest o sull'output finito. Non può sapere nulla di un pacchetto scaricato da uno script post-install, di un crate compilato dentro un binario o di un layer dell'immagine base che non gli è mai stato mostrato. Ognuno di questi è una dipendenza nascosta.

Prenda un servizio Node.js il cui lockfile elenca 400 pacchetti. Uno di essi ha uno script postinstall che scarica un binario precompilato durante npm ci. Una SBOM generata da package-lock.json è valida, ogni componente ha una versione e un package URL, e il binario non c'è. Nessun punteggio di qualità lo segnalerà, perché nulla nel file indica ciò che manca.

Ricompilare in seguito non risolve la questione: a meno che la build non sia una build riproducibile, una seconda build può ricevere qualcosa di diverso dalla prima.

Come dichiarare la completezza in modo onesto

• Indichi il contesto di generazione: se la SBOM è stata creata dal codice sorgente prima della build, registrata durante la build o prodotta analizzando l'output dopo.
• Elenchi le lacune note: parti del software che lo strumento non ha potuto vedere, come codice incorporato, binari precompilati o componenti installati al di fuori di un gestore di pacchetti.
• Preferisca uno stato motivato a un punteggio. Una percentuale di completezza richiede un totale, ed è proprio il totale che nessuno conosce. Un'indicazione come «incompleta: il job ha consentito traffico non monitorato» permette di agire.

Le best practice SBOM trattano più in generale la pratica di dichiarare ciò che una SBOM non ha potuto vedere.

Gli stati di completezza in CRACI

CRACI assegna uno stato di completezza alla SBOM di ogni job, e anche le cache ne ricevono uno. Gli stati, come li definisce la documentazione di CRACI:

• Complete: «CRACI ha osservato evidenze complete per il job, e ogni cache ripristinata era completa».
• Complete with connections: «I requisiti sono stati soddisfatti, ma il job ha usato una o più connessioni di rete personalizzate».
• Incomplete: «CRACI ha individuato una condizione che potrebbe lasciare dipendenze fuori dalla SBOM».
• Unavailable: «CRACI non è riuscito a completare la valutazione delle evidenze».
• Not recorded: «Il job è precedente all'introduzione degli stati di completezza».

CRACI può dichiararlo perché vede il traffico di ogni job verso le sorgenti dei pacchetti e sa quindi quando qualcosa potrebbe essergli sfuggito: traffico che non ha monitorato, o una cache ripristinata la cui SBOM era incompleta. Quando un job è incompleto, ne mostra il motivo, ad esempio «Unmonitored traffic was allowed». Veda generazione di SBOM.

Questi stati si applicano alle build eseguite su runner CRACI. Per una SBOM di un fornitore, o di una pipeline che non gira su CRACI, usi i confronti e le regole descritti sopra.