CRACI vs Syft e Grype

La risposta breve

Syft è un diffuso generatore di SBOM open source, e Grype è il suo scanner di vulnerabilità complementare. Insieme coprono generazione e confronto gratuitamente, in qualsiasi pipeline. CRACI è un runner GitHub Actions che registra ciò che ogni build ha scaricato, dichiara se quel record è completo, controlla dove la build può connettersi e continua a monitorare ciò che è stato distribuito. La differenza in una riga: Syft ricostruisce la SBOM dai file, e quanto trova dipende dalla sua configurazione e da ciò che si trova su disco al momento dell'esecuzione. CRACI la osserva e traccia le vulnerabilità in ciò che ha registrato, quindi un solo prodotto svolge il lavoro di entrambi.

Che cosa fanno bene Syft e Grype

Syft è "a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems." Riconosce decine di sistemi di packaging, da Alpine, Debian e RPM a Go, Python, Java, JavaScript, Ruby, Rust, PHP e .NET. Scrive CycloneDX, SPDX e il proprio Syft JSON, converte tra i formati e può creare attestazioni SBOM firmate usando la specifica in-toto.

Grype scansiona immagini container, filesystem e SBOM alla ricerca di vulnerabilità note. Prioritizza i risultati con EPSS, KEV e punteggio di rischio, supporta OpenVEX per filtrare i risultati, e il suo flag --fail-on fa fallire una pipeline quando trova vulnerabilità pari o superiori a una gravità scelta da Lei. Anchore osserva che Grype "runs entirely locally and doesn't send any data to external services", a parte il download del suo database.

Entrambi hanno licenza Apache-2.0 e sono sponsorizzati da Anchore, la cui piattaforma commerciale, Anchore Enterprise, "builds on open source Syft and Grype." Questa pagina riguarda gli strumenti open source.

Syft è forte quando ha davanti i file giusti. Se viene puntato su un albero di sorgenti che include le proprie dipendenze, come ollama/ollama, la sua scansione predefinita le risolve con versioni, package URL e relazioni tra le dipendenze.

Un flag cambia la risposta

Syft sceglie i propri cataloger in base al tipo di scansione, e la sua documentazione spiega perché: "files that hint at the intent to install software do not have enough information in them to determine the exact version." I cataloger hanno tag come declared, installed, image e directory, e flag come --select-catalogers e --override-default-catalogers modificano l'insieme.

In syft cataloger list alla v1.51.1, il cataloger JavaScript che legge node_modules ha i tag per le scansioni di immagini e di software installato e non fa parte dell'insieme predefinito per la scansione di una directory. Quindi, su un checkout con le dipendenze installate, un solo flag decide se i pacchetti npm in node_modules vengono letti oppure no. Stesso strumento, stessa versione, stesso albero.

Il rovescio della medaglia conta altrettanto. Nessuna singola configurazione va bene ovunque:

• Su un checkout pulito di express 5.2.1, che non ha lockfile, la scansione predefinita non ha dipendenze npm da risolvere e restituisce qualsiasi altra cosa riconosca, come GitHub Actions e file di workflow.
• Se attiva i cataloger per il software installato e li punta su alberi di sorgenti così come sono stati committati, dove non è ancora stato installato nulla, non hanno quasi nulla da leggere.
• Un repository senza alcun manifest di dipendenze non offre alla scansione alcun file di dipendenze da leggere, qualunque sia la configurazione.

Niente di tutto questo è un bug. Syft riporta ciò che i file davanti a lui consentono, come previsto. La conseguenza pratica è che la SBOM dipende da due decisioni che qualcuno deve prendere correttamente in ogni pipeline: quali cataloger eseguire e se le dipendenze sono state installate prima della scansione. E Grype può confrontare solo ciò che Syft ha elencato. Un componente che manca nella SBOM non arriva mai alla ricerca delle vulnerabilità, quindi per quel componente la scansione risulta pulita.

In che cosa CRACI è diverso

CRACI non ha cataloger da scegliere, perché non legge l'albero a posteriori. Lei cambia runs-on in craci, e un proxy che riconosce i pacchetti registra ciò che il job scarica da npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e sorgenti Git, oltre ai preset di download. I pacchetti ripristinati da una cache CI portano con sé le proprie evidenze. Il risultato, in CycloneDX o SPDX, comprende le dipendenze transitive effettivamente usate dalla build.

• La completezza è esplicita. Ogni job e ogni cache è contrassegnato come Complete, Complete with connections, Incomplete, Unavailable o Not recorded.
• La build è controllata. Una policy di egress (negazione o autorizzazione predefinita, 24 preset integrati di sorgenti software) viene convalidata prima dell'avvio del job e opera in modalità fail closed.
• Dati di provenance. L'API restituisce SBOM, tracce di rete e provenance. CRACI non firma la provenance; un'attestazione Syft firma la SBOM.
• Monitoraggio. Le SBOM monitorate vengono rivalutate di continuo, e i risultati vengono aggregati tra build e repository.

Grype fa comunque cose che CRACI non fa. Il filtraggio VEX e la scansione di immagini che Lei non ha compilato sono territorio di Grype. I policy gate di CRACI possono far fallire la build; i suoi avvisi a soglia sono in roadmap.

Un inventario di che cosa è 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.

Passare da Syft e Grype

Su CRACI non c'è alcuna SBOM da generare né alcuno step di scansione da mantenere. Il runner registra la SBOM durante la build, e CRACI continua a controllarla per individuare nuove vulnerabilità dopo la fine della build. Syft e Grype restano gli strumenti per le immagini e il software di terze parti che non ha compilato, e per le pipeline al di fuori di GitHub Actions.

Per il Cyber Resilience Act

Il CRA chiede ai fabbricanti di documentare i componenti di ogni prodotto, compresa una SBOM, e di gestirne le vulnerabilità. Syft e Grype possono produrre e controllare quella SBOM, mentre la catena di evidenze da ogni release alla sua SBOM deve costruirla Lei. CRACI registra la SBOM per ogni build e la esporta in CycloneDX o SPDX. Automatizza una parte significativa della visibilità e delle evidenze sulla software supply chain di cui le aziende hanno bisogno nel loro più ampio processo di conformità al CRA. Veda che cos'è il CRA e la generazione di SBOM in fase di build.