Best practice per le SBOM

Generare le SBOM

1. Generi in CI, per ogni release

Una SBOM creata a mano diventa obsoleta prima che qualcuno la legga. Ne faccia un passaggio della pipeline che compila la release, oppure usi un runner che la produce senza alcun passaggio, così nessuna release viene distribuita senza. Per GitHub Actions, veda come generare una SBOM in GitHub Actions.

2. Descriva la build che è stata distribuita

Le build non sono riproducibili per impostazione predefinita. Compilare due volte lo stesso commit non garantisce le stesse dipendenze, perché le versioni vengono risolte al momento della build e i passaggi possono variare. Una SBOM creata su un portatile o da una scansione successiva descrive una build simile, non quella che Lei ha distribuito. Solo una SBOM della build CI che ha prodotto la release dimostra che cosa contiene. Veda le SBOM in fase di build.

3. Copra più del lockfile

Un lockfile non è un registro di ciò che è stato distribuito. Gli script di installazione scaricano codice, gli script di build di Rust recuperano file e le build dei container introducono un'immagine base con i propri pacchetti del sistema operativo. Decida che cosa deve coprire la SBOM, poi lo verifichi: cerchi nella Sua SBOM un pacchetto della Sua immagine base e uno strumento di build.

4. Includa dipendenze transitive e relazioni

Le vulnerabilità di solito si trovano sotto le dipendenze dirette. Un elenco piatto mostra che un componente è presente, ma non che cosa aggiornare. Mantenga il grafo delle dipendenze nella SBOM, così un risultato arriva insieme al pacchetto che lo introduce.

5. Dichiari ciò che non ha potuto vedere

I 2026 Minimum Elements chiedono agli autori delle SBOM di indicare esplicitamente le informazioni sconosciute. Una SBOM parziale che lo dichiara vale più di una SBOM parziale che sembra finita. Registri anche lo strumento, la sua versione e il contesto di generazione, così chi legge può giudicare che cosa copre il file.

Conservare le SBOM

6. Conservi una SBOM per release, collegata all'artefatto

Quando un cliente su una vecchia versione chiede se è esposto, Le serve la SBOM di quella versione, non l'ultima. Archivi ogni SBOM con la build e l'artefatto che descrive, e decida per quanto tempo conservarla in base alla durata del supporto della release. Gli hash nella SBOM aiutano a collegarla all'artefatto esatto.

7. Scelga un formato e un identificatore, e li mantenga

Si standardizzi su CycloneDX o SPDX, su una versione del formato e sui package URL come identificatori. Gran parte delle difficoltà nel confrontare le SBOM nasce da strumenti che chiamano la stessa cosa in modi diversi. Convalidi ogni file nella pipeline e chieda lo stesso formato ai fornitori.

Usare le SBOM

8. Monitori ciò che ha distribuito, non solo ciò che sta compilando

Il momento in cui una SBOM vale di più è il giorno dopo la pubblicazione di un advisory per un software rilasciato l'anno scorso. Una scansione in una pull request non può aiutare. Rivaluti le SBOM archiviate delle release supportate rispetto ai nuovi dati sulle vulnerabilità, così un nuovo advisory si trasforma in un elenco di release colpite.

9. Assegni i risultati a un responsabile e registri la decisione

Una SBOM con mille vulnerabilità associate è un elenco, non un piano. Ordini i risultati con un metodo di prioritizzazione, invii ciascuno al team responsabile della correzione e registri perché non è intervenuto sugli altri, ad esempio in una dichiarazione VEX.

10. Usi la stessa SBOM per clienti e auditor

Clienti, auditor e autorità di regolamentazione pongono domande simili. Risponda con la SBOM usata dai Suoi team, invece di produrre un documento separato che finisce per divergere. Se condivide le SBOM, decida chi può vederle e come ricevono gli aggiornamenti, e chieda lo stesso ai Suoi fornitori.

Errori comuni

Errore	Perché è un problema	Che cosa fare invece
Una SBOM per repository	Non dice nulla di una release specifica	Una per release, collegata all'artefatto
Generarla solo al momento dell'audit	Descrive una build che nessuno ha distribuito	A ogni release, in CI
Considerare la SBOM conclusa	I nuovi advisory arrivano dopo il rilascio	Continuare a monitorarla
Confrontare solo il numero di componenti	Di più non è meglio se le voci sono sbagliate	Controllare pacchetti specifici che si sa essere presenti

Come se ne occupa CRACI

CRACI copre le pratiche che dipendono dalla build. È un runner GitHub Actions che registra ogni pacchetto scaricato da ciascun job, comprese le dipendenze nascoste che nessun lockfile elenca, in una SBOM CycloneDX o SPDX con uno stato di completezza. Conserva ogni build passata e la sua SBOM entro la retention del Suo piano, rivaluta le SBOM monitorate man mano che emergono nuove vulnerabilità e mostra quali build contenevano una dipendenza vulnerabile. I team di sicurezza eseguono il triage dei risultati e li inviano ai team responsabili della correzione. Veda gestione delle SBOM per il confronto tra i manager, oppure i migliori strumenti SBOM.

Best practice per le SBOM: domande frequenti

Quando va generata una SBOM?

Durante la build CI che produce la release, ogni volta. Una SBOM creata in quel momento descrive ciò che è stato distribuito, mentre una creata in seguito descrive una nuova build o una scansione.

Per quanto tempo vanno conservate le SBOM?

Almeno per tutto il periodo di supporto della release, più quanto richiesto da autorità di regolamentazione o contratti. La SBOM di una vecchia versione serve per stabilire se i suoi utenti sono colpiti da una nuova vulnerabilità.

Le SBOM vanno automatizzate?

Sì. Una SBOM manuale è già superata alla release successiva. Generi le SBOM nella pipeline, le convalidi lì e le archivi con la build.

La SBOM va condivisa con i clienti?

La condivida quando un cliente o un'autorità di regolamentazione la chiede, a condizioni per Lei accettabili. Una SBOM rivela ciò che Lei usa, per questo molte aziende la condividono su richiesta invece di pubblicarla.

Qual è la differenza tra una SBOM e la gestione delle SBOM?

Una SBOM è un singolo file. La gestione delle SBOM è il lavoro continuo di archiviarle per release, monitorarle per individuare nuove vulnerabilità e renderle disponibili a chi ne ha bisogno.