Automazione delle SBOM: dai fogli di calcolo alle build

Perché le SBOM manuali smettono di funzionare

Invecchiano alla build successiva. Le dipendenze cambiano a ogni release, e un foglio di calcolo cambia solo quando qualcuno si ricorda di aggiornarlo.
Si fermano a ciò che le persone riescono a vedere. Elencare le dipendenze dirette è facile. Le dipendenze transitive sottostanti no, e nessuno riesce a seguirle a mano.
Si moltiplicano. Più prodotti, ciascuno con più versioni supportate, significano decine di file, ognuno con il proprio responsabile e la propria idea della verità.
Non rispondono alla domanda che conta. Quando emerge una nuova vulnerabilità, deve sapere quali release contengono il pacchetto. Cercare in una cartella di fogli di calcolo è lento, e la risposta non è affidabile.
Non sono ciò che gli altri chiedono. Clienti e strumenti si aspettano un formato leggibile da una macchina, come CycloneDX o SPDX. Veda come rispondere alla richiesta di SBOM di un cliente.

Che cosa fa una buona automazione delle SBOM

Produce una SBOM per ogni build, senza che nessuno debba eseguire o ricordare nulla.
Copre l'intero albero, dipendenze transitive incluse, a ogni profondità.
Lega ogni SBOM a una sola build, così Lei sa quale file descrive quale release.
Dichiara ciò che non ha potuto vedere, invece di presentare un elenco parziale come completo.
Esporta in un formato standard, così la SBOM funziona con il prossimo strumento e il prossimo cliente.
Continua a monitorare ciò che è stato distribuito, perché una release pulita il lunedì può risultare colpita il martedì.

Tre modi di tenere le SBOM a confronto

Domanda	Foglio di calcolo	Scanner in CI	Registrata durante la build
Quando viene aggiornata?	Quando qualcuno se ne ricorda	Quando viene eseguito il passaggio di scansione	A ogni build
Da dove provengono i dati?	Dalle persone	Dai lockfile o dall'output finito	Da ciò che la build ha effettivamente scaricato
Dipendenze transitive?	Raramente	Quelle che riesce a ricavare	A ogni profondità
Dipendenze nascoste, come i download degli script di installazione?	No	Non rilevate	Registrate
Pacchetti ripristinati da una cache CI?	No	Dipende dallo strumento	Registrati e contrassegnati come provenienti dalla cache
Monitoraggio delle vulnerabilità?	Manuale	Di solito uno strumento separato	Integrato in CRACI

Automatizzare con uno scanner è un vero passo avanti rispetto a un foglio di calcolo, ma resta un'ipotesi su ciò che è entrato nella build. Per le motivazioni, veda perché la build è la fonte di verità.

Che fine fanno i Suoi fogli di calcolo

I dati sui componenti escono dal foglio: versioni e pacchetti arrivano dalla build, quindi nessuno deve digitarli. Resta la conoscenza che solo il Suo team possiede, come quali prodotti esistono, chi ne è responsabile e quali versioni sono ancora supportate. È la parte che merita il tempo di una persona.

Come se ne occupa CRACI

CRACI sostituisce i Suoi runner ospitati da GitHub con runner più veloci e meno costosi, e registra la SBOM durante l'esecuzione di ogni build. Lei imposta runs-on: craci e le Sue esecuzioni continuano a comparire in GitHub. Le build standard ottengono una SBOM completa senza configurazione. Quelle con registry di pacchetti propri o configurazioni di container insolite possono richiederne una.

Registrata, non scansionata. CRACI vede il traffico in ingresso in ogni build, comprese le dipendenze nascoste che sfuggono agli strumenti basati sui lockfile. Ogni componente nella SBOM era nella build.
Uno stato di completezza per ogni job, così Lei sa quando una build non ha potuto essere registrata per intero, e perché.
Esportazione in CycloneDX e SPDX, comprese le dipendenze transitive e le vulnerabilità trovate nei componenti.
Un'unica vista su tutti i prodotti. La vista dell'inventario mostra quali versioni del software sono distribuite su quali prodotti, e CRACI continua a rivalutare le SBOM monitorate.

Per estenderlo a team con pipeline diverse, consulti la generazione di SBOM tra i team di sviluppo.

Automazione delle SBOM: domande frequenti

Che cos'è l'automazione delle SBOM?

Produrre una software bill of materials come parte della build, così ogni release ne ha una senza che nessuno debba crearla a mano. Le configurazioni migliori monitorano anche ogni SBOM per individuare nuove vulnerabilità dopo il rilascio.

Possiamo tenere le nostre SBOM in Excel?

Un foglio di calcolo può funzionare come primo inventario, ma è difficile da mantenere aggiornato e non arriva alle dipendenze transitive. Inoltre non è un formato SBOM standard. Clienti e strumenti di sicurezza in genere si aspettano CycloneDX o SPDX, e il Cyber Resilience Act chiede un formato di uso comune e leggibile da una macchina.

L'automazione delle SBOM richiede un nuovo passaggio in ogni pipeline?

Con la maggior parte dei generatori sì: si aggiunge un passaggio a ogni workflow e lo si mantiene aggiornato. CRACI registra la SBOM nel runner, quindi non c'è alcun passaggio da aggiungere ai Suoi job.

Quali ecosistemi registra CRACI?

npm, PyPI, RubyGems, Composer, Cargo, Go, Nix, OCI, pacchetti Debian e Ubuntu (apt), pacchetti Alpine (apk) e sorgenti Git, oltre ai download di Yocto e OpenEmbedded. Maven e Java sono in roadmap.

Quali sistemi CI e piattaforme supporta CRACI?

Oggi GitHub Actions, con altri sistemi CI in roadmap. Oggi i runner sono Linux x86-64 e ARM64, con Windows e macOS in roadmap.

E i componenti acquistati dai fornitori?

Può aggiungere a CRACI le SBOM dei fornitori, così i componenti acquistati vengono monitorati insieme alle Sue build.

Quanto costa?

CRACI addebita solo i minuti di build: $0.002 per vCPU-minuto ($0.004 per un runner predefinito da 2 vCPU), misurati al secondo, senza canone mensile e senza costi per SBOM.