Lei scansiona già le Sue dipendenze. Ecco che cosa uno scanner non può vedere.

Che cosa fa bene il Suo stack attuale

Se ha configurato SCA e generazione di SBOM, ha già svolto il lavoro organizzativo più difficile: le dipendenze sono tracciate, gli advisory raggiungono gli sviluppatori e c'è un file da consegnare quando qualcuno lo chiede. Lo mantenga.

• Il dependency graph di GitHub e Dependabot sono attivi per impostazione predefinita per molti team. GitHub descrive il dependency graph come un riepilogo dei file manifest e lock archiviati in un repository e di tutte le dipendenze inviate per il repository tramite la dependency submission API. Gli avvisi di Dependabot si basano su di esso e La avvisano quando viene pubblicato un nuovo advisory o quando il Suo dependency graph cambia.
• La SCA commerciale, come Snyk, genera anche SBOM. Il suo comando snyk sbom legge i file manifest e i relativi lockfile, ed emette CycloneDX o SPDX. A settembre 2026, Snyk lo documenta come disponibile solo per i clienti con piani Snyk Enterprise.
• I generatori open source come Syft, Trivy e cdxgen sono gratuiti, veloci e facili da aggiungere alla CI. Syft si descrive come uno strumento per generare una Software Bill of Materials (SBOM) da immagini container e filesystem.

Questi strumenti danno il meglio nel feedback rapido su una pull request, nell'ampia copertura degli ecosistemi e in un flusso di remediation che gli sviluppatori conoscono già. Oggi CRACI non sostituisce tutto questo. Il suo tracciamento delle vulnerabilità aggrega i risultati tra build e repository e rivaluta le SBOM monitorate quando compaiono nuove vulnerabilità. I team di sicurezza possono esaminare i risultati e inviarli al team giusto. I policy gate possono bloccare una build; i webhook per le vulnerabilità sono in roadmap.

Scanner e registratore

Tutti gli strumenti qui sopra sono scanner. Lei li punta su un albero di sorgenti, un lockfile o un'immagine container, e loro ricavano che cosa è entrato. Funziona quando i file raccontano tutta la storia. Diventa più difficile quando non lo fanno:

• Il repository non ha un lockfile, quindi le versioni vengono decise al momento dell'installazione.
• La build ripristina pacchetti da una cache CI che nessun manifest menziona.
• Uno step di build scarica direttamente uno strumento, un pacchetto del sistema operativo o un binario.
• Un hook di installazione npm o uno script di build Rust scarica altro codice durante l'installazione, la via usata dal worm Shai-Hulud.
• Una build di container scarica un'immagine base e i suoi layer di sistema operativo, che nessun lockfile di linguaggio elenca.
• Ciò che Lei distribuisce è un binario compilato, e il manifest accanto a esso non elenca quasi nulla.

CRACI è un registratore: vede il traffico, gli scanner no. Esegue la build sul proprio runner compatibile con GitHub Actions, e un proxy che riconosce i pacchetti osserva il traffico verso le sorgenti dei pacchetti durante l'esecuzione del job, così queste dipendenze nascoste finiscono nella SBOM. I pacchetti ripristinati da una cache portano con sé le proprie evidenze. Non esiste un comando craci scan ./dir, perché scansionare una directory a posteriori è proprio il passaggio che CRACI è nato per evitare.

Da che cosa dipende una scansione

L'output di uno scanner dipende dallo strumento e da ciò su cui viene puntato. Syft, Trivy, cdxgen, il Microsoft SBOM Tool, l'esportazione del dependency graph di GitHub e la Socket CLI ricavano ciascuno l'elenco da ciò che riescono a leggere. Gli schemi qui sotto derivano dal funzionamento di questi strumenti così come è documentato.

Nessun componente viene trovato da tutti gli strumenti

Ogni generatore decide autonomamente che cosa conta come componente e di quali file fidarsi, quindi lo stesso checkout dà a ciascuno un elenco diverso. L'esportazione del dependency graph di GitHub funziona ancora in un altro modo: è costruita a partire da ciò che GitHub sa del repository invece che dai file letti da uno scanner, e legge il branch predefinito invece di un commit fissato.

Niente lockfile, niente dipendenze

Express 5.2.1 non include alcun lockfile nel repository. Puntato su un checkout pulito, un generatore che risolve le dipendenze da lockfile o da un albero installato non ha davanti a sé né gli uni né l'altro, quindi nessuna delle dipendenze npm dichiarate in package.json arriva nel documento. Nessuno strumento qui è difettoso. La variabile che decide se la SBOM contiene o meno delle dipendenze non è lo strumento. È se qualcuno ha eseguito prima un'installazione.

Un flag cambia la risposta

La scansione predefinita delle directory di Syft riporta ciò che un progetto dichiara, non ciò che è installato su disco. Su un checkout installato della stessa release di express, un solo flag del cataloger decide se i pacchetti npm installati compaiono o meno nell'elenco. Stesso strumento, stessa versione, stesso albero.

Il prodotto è un binario

Il repository anthropics/claude-code alla v2.1.259 non ha alcun manifest di dipendenze né lockfile di alcun tipo. Il suo pacchetto npm pubblicato dichiara zero dipendenze di runtime e incapsula un binario nativo precompilato tramite otto pacchetti di piattaforma. @openai/codex 0.149.1 ha la stessa struttura. Un lettore di manifest non ha quasi nulla da descrivere, mentre il programma che viene eseguito è un binario compilato, quindi ciò che ogni strumento restituisce dice di più sullo strumento che sul progetto.

Stesso pacchetto, versioni diverse

Quando due strumenti trovano la stessa cosa, non sempre concordano su che cosa sia. Uno può fissare una GitHub Action a uno SHA di commit, mentre un altro riporta un tag di release. Una ricerca di vulnerabilità basata sulla versione sbagliata restituisce con sicurezza una risposta sbagliata.

Dove si colloca CRACI accanto alla Sua SCA

Mantenga la Sua SCA sulle pull request. È il posto giusto per intercettare una versione vulnerabile prima del merge. Aggiunga CRACI dove la domanda riguarda la build e non il diff:

• Che cosa conteneva davvero questa release? La SBOM registrata copre npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download, comprese le dipendenze transitive. Funzionano anche i mirror JFrog Artifactory per npm e PyPI.
• Possiamo fidarci dell'elenco? Ogni job e cache ha uno stato di completezza, quindi una registrazione incompleta è visibile invece di restare silenziosamente scarna.
• Un nuovo advisory ci riguarda? Le SBOM monitorate vengono rivalutate quando vengono pubblicate nuove vulnerabilità, e i risultati sono aggregati tra build e repository.

La SBOM si scarica in CycloneDX tramite la REST API pubblica, insieme alla traccia di rete e alla provenance del job, quindi può alimentare qualsiasi strumento che legga CycloneDX, compresa la SCA che già utilizza. La configurazione è una riga nel workflow: cambi runs-on in craci. Oggi la CI supportata è GitHub Actions; GitLab CI, Jenkins e altri sistemi CI sono in roadmap.

Un inventario di ciò che è distribuito e dove

La vista inventario di CRACI mostra esattamente quali versioni del software sono distribuite in quali prodotti, a livello globale. Quando arriva una nuova vulnerabilità, può vedere quali prodotti eseguono la versione interessata invece di ricostruirlo da note di rilascio e fogli di calcolo.

Scopra di più sulla generazione di SBOM in fase di build e sul tracciamento delle vulnerabilità.