Che cosa sfugge ai generatori di SBOM open source

Come generare una SBOM con ciascuno strumento

Con ogni strumento basta un comando per una directory di sorgenti o un'immagine container, con output CycloneDX o SPDX:

# Syft: a source directory or a container image
syft ./my-project -o cyclonedx-json=sbom.cdx.json
syft my-image:latest -o spdx-json=sbom.spdx.json

# Trivy: a filesystem or a container image
trivy fs --format cyclonedx --output sbom.cdx.json .
trivy image --format spdx-json --output sbom.spdx.json my-image:latest

# cdxgen: the current directory, optionally with a project type
cdxgen -o bom.json .
cdxgen -t js -o bom.json .

I comandi sono la parte facile. Ciò che finisce nel file dipende da ciò che ogni strumento legge, e non leggono le stesse cose.

Che cosa legge ciascuno strumento

Strumento	Directory di sorgenti	Immagine container	Da sapere
Syft	Un insieme predefinito di cataloger per directory, che legge le dipendenze dichiarate	Un insieme predefinito di cataloger per immagini, che legge i pacchetti installati	I cataloger vengono scelti in base al tipo di scansione. syft cataloger list mostra quali vengono eseguiti e --select-catalogers li aggiunge o li rimuove.
Trivy	Lockfile, per Node.js package-lock.json, yarn.lock, pnpm-lock.yaml e bun.lock	Per Node.js, i file package.json sotto node_modules	Esclude le dipendenze di sviluppo, a meno che non si passi --include-dev-deps.
cdxgen	Prima i lock file, che includono le dipendenze di sviluppo; per Node.js analizza anche il codice alla ricerca di import	Supportata	Imposti il tipo di progetto con -t per limitare ciò che cerca.

Perché divergono sullo stesso repository

Se li punta tutti e tre sullo stesso commit, ottiene tre elenchi diversi. Nessuno di loro è difettoso. Ciascuno segue le proprie regole documentate:

• Nessun lockfile, nessuna dipendenza. Express 5.2.1 non include alcun lockfile nel repository. In un checkout pulito, uno strumento che risolve le dipendenze da lockfile o pacchetti installati non trova né gli uni né gli altri, quindi le dipendenze npm dichiarate in package.json non arrivano mai nella SBOM. Scrive comunque un documento valido con tutto il resto che ha riconosciuto.
• Installate o dichiarate. L'aver eseguito o meno un'installazione prima della scansione può contare più dello strumento usato. Su una copia installata dello stesso repository, una singola impostazione dei cataloger di Syft decide se i pacchetti npm installati compaiono o meno.
• Dipendenze di sviluppo. Trivy le esclude per impostazione predefinita e cdxgen le include, quindi lo stesso lockfile dà due risposte alla domanda "che cosa c'è in questo progetto".
• Nomi e versioni. Gli strumenti identificano alcuni componenti con tipi di package URL diversi, oppure uno fissa una GitHub Action a un commit SHA dove un altro riporta un tag. Una ricerca di vulnerabilità basata sull'identificatore sbagliato dà una risposta sicura e sbagliata.
• Nessun manifest. Il repository anthropics/claude-code non ha alcun manifest delle dipendenze, e il suo pacchetto npm incapsula un binario precompilato. Ciò che ogni strumento restituisce dice più sullo strumento che sul progetto.

Che cosa sfugge a tutti: le dipendenze nascoste

Il limite più profondo è comune a tutti. Uno scanner legge il lockfile o l'output della build e ne deduce a posteriori che cosa vi è entrato. Tutto ciò che la build ha scaricato al di fuori di quei file non arriva mai nella SBOM. Queste sono le dipendenze nascoste:

• Hook di installazione. Gli script npm preinstall e postinstall vengono eseguiti durante l'installazione e possono scaricare altro codice. È così che ha operato il worm Shai-Hulud.
• Script di build, come gli script di build di Rust che scaricano ciò che serve loro in fase di build.
• Immagini base e i relativi layer del sistema operativo in una build di container, che nessun lockfile di linguaggio elenca.
• Pacchetti ripristinati dalle cache CI, che potrebbero non corrispondere al lockfile attuale. Veda che cosa nasconde la cache di GitHub Actions.
• Strumenti di build installati dai passaggi di setup, con i propri alberi di dipendenze.
• Versioni transitive risolte in fase di build quando il lockfile manca, non è aggiornato o non viene usato da un'installazione frozen. Veda le dipendenze transitive.

Scansionare l'output in seguito non colma la lacuna. Un binario finito, soprattutto codice compilato come Rust, lascia lo scanner a indovinare che cosa vi sia entrato. Gli scanner SCA commerciali lavorano sugli stessi tipi di file e condividono gli stessi punti ciechi. CRACI ha trovato pacchetti vulnerabili che Snyk e Aikido non avevano segnalato, perché quei componenti non erano mai stati in ciò che avevano scansionato.

Anche gli strumenti fanno parte della Sua supply chain

Uno scanner viene eseguito nella Sua CI con accesso al Suo codice e spesso ai Suoi secret. Nel marzo 2026 l'advisory di Aqua Security (CVE-2026-33634) ha descritto una release malevola di Trivy v0.69.4 e tag avvelenati di trivy-action e setup-trivy che rubavano credenziali dai runner CI. Fissi le action degli scanner a commit SHA completi e consulti l'advisory per le versioni che usa.

Come verificare la Sua SBOM

1. Esegua due generatori sullo stesso commit e confronti i package URL che riportano.
2. Verifichi se il repository include un lockfile e se la CI installa da quel lockfile con un'installazione frozen.
3. Esegua la scansione sia dopo sia prima dello step di installazione, e confronti.
4. Confronti l'elenco con ciò che il log di build mostra come scaricato, compresi i passaggi di setup e i ripristini delle cache.

Se gli elenchi differiscono, la SBOM che pubblica dipende dallo strumento che Le è capitato di eseguire, non da ciò che ha distribuito.

Registri invece la build

CRACI vede il traffico; gli scanner no. È un runner GitHub Actions che vede il traffico di rete in ingresso in ogni build, quindi la sua SBOM registra ogni pacchetto introdotto dal job, a ogni profondità dell'albero, comprese le dipendenze nascoste e i pacchetti ripristinati dalle cache CI. Non c'è alcuna directory a cui puntare né alcun cataloger da scegliere. Quando una registrazione non ha potuto vedere tutto, ad esempio perché un job ha consentito traffico non monitorato, la SBOM lo dichiara con il suo stato di completezza.

La registrazione conta anche perché le build sono raramente riproducibili. Compili lo stesso commit due volte, una dopo l'altra, e il package manager può risolvere e installare in un ordine diverso, quindi la seconda build può contenere pacchetti diversi. Solo la SBOM registrata durante la build che ha prodotto una release dimostra che cosa contiene quella release.

Mantenga Syft o Trivy per le immagini e i binari di terze parti che non ha compilato Lei. Per le Sue release, veda le SBOM in fase di build oppure prenoti una demo per confrontare una SBOM registrata con quella del Suo strumento attuale su uno dei Suoi repository.

Generatori di SBOM open source: domande frequenti

Per le SBOM è meglio Syft o Trivy?

Sono pensati per compiti diversi. Syft è un generatore di SBOM dedicato, con molti cataloger e attestazioni firmate; Trivy è uno scanner di sicurezza che scrive SBOM come uno dei suoi output. Entrambi leggono i file che hanno davanti, quindi sullo stesso repository la differenza maggiore di solito è se il lockfile è incluso nel repository e se le dipendenze sono state installate prima della scansione.

Perché la mia SBOM non mostra dipendenze?

Il più delle volte perché il repository non include un lockfile e prima della scansione non è stato installato nulla. Un generatore che legge lockfile o pacchetti installati non ha allora nulla da leggere, e scrive comunque una SBOM valida. Esegua il commit del lockfile oppure scansioni dopo lo step di installazione.

Trivy include le dipendenze di sviluppo nella SBOM?

Non per impostazione predefinita. La documentazione di Trivy per Node.js afferma che non segnala le dipendenze di sviluppo a meno che non si passi --include-dev-deps. cdxgen, invece, analizza i lock file e include le dipendenze di sviluppo. Due strumenti possono divergere sullo stesso progetto anche solo per questo motivo.

Posso fidarmi di una SBOM di un generatore open source?

Per ciò che ha letto, sì. La domanda è ciò che non ha letto: cache, strumenti di build, download, script di installazione e binari senza metadati di pacchetto. Tratti una SBOM da scansione come una descrizione dei file a cui ha puntato lo strumento, non della build che ha prodotto la Sua release.

Qual è il miglior strumento SBOM?

Per il software che compila Lei, la SBOM più completa si ottiene registrando la build invece di scansionare i file. CRACI registra ogni pacchetto scaricato da ciascun job GitHub Actions, anche dalle cache, e ha trovato pacchetti vulnerabili che Snyk e Aikido non avevano segnalato. Per le immagini e i binari di terze parti che non ha compilato Lei, uno scanner come Syft o Trivy resta la scelta pratica.