Un SBOM (Software Bill of Materials) è l’«elenco degli ingredienti» del tuo software: la lista completa di pacchetti, librerie, versioni e dipendenze che contiene un’immagine. Come un’etichetta nutrizionale, ti dice esattamente cosa c’è dentro.
Il suo valore si vede il giorno di una vulnerabilità critica: invece di rincorrere a mano decine di immagini, consulti l’SBOM e sai in pochi secondi quali immagini contengono il componente colpito e in che versione.
Perché conta per le tue immagini
- Risposta rapida ai CVE: capisci all’istante se una nuova vulnerabilità ti riguarda.
- Sicurezza della catena di fornitura: sai da dove viene ogni componente.
- Conformità: sempre più framework e clienti lo chiedono come evidenza.
- Trasparenza: se pubblichi immagini, un SBOM genera fiducia in chi le usa.
Formati standard
| Formato | Origine | Note |
|---|---|---|
| SPDX | Linux Foundation / ISO | Standard ISO, molto usato in conformità |
| CycloneDX | OWASP | Orientato alla sicurezza, ricco per l’analisi delle vulnerabilità |
I due formati SBOM dominanti; molti strumenti esportano verso entrambi.
Come generare l’SBOM di un’immagine, passo dopo passo
- Scegli lo strumento: Syft, di Anchore, è uno standard di fatto per generare SBOM di immagini e filesystem; esistono anche opzioni native del cloud.
- Generalo nella pipeline: durante il build della AMI, scansiona il filesystem e produci l’SBOM, per esempio in CycloneDX e SPDX.
- Analizza le vulnerabilità: passa l’SBOM in Grype o Trivy per incrociarlo con i database di CVE.
- Firma e archivia: firma l’SBOM —per esempio con cosign— e conservalo come artefatto associato alla versione dell’immagine.
- Consultalo quando serve: davanti a un nuovo CVE, esamina gli SBOM archiviati per conoscere la portata.
Il contesto normativo del 2026
L’SBOM guadagna peso da anni come buona pratica di sicurezza della catena di fornitura. Il quadro normativo, però, è sfumato: negli Stati Uniti l’amministrazione ha rivisto nel 2026 i mandati ereditati di attestazione del software verso un approccio più basato sul rischio, mentre nell’Unione europea norme come il Cyber Resilience Act spingono la trasparenza del software e l’inventario dei componenti. Conclusione pratica: al di là delle oscillazioni normative, disporre di SBOM è un vantaggio difensivo e commerciale che conviene adottare.
Buone pratiche
- Genera l’SBOM automaticamente a ogni build, non a mano.
- Conservalo versionato insieme all’immagine a cui corrisponde.
- Combinalo con la scansione delle vulnerabilità perché sia azionabile.
- Firmalo per garantirne integrità e provenienza.
Domande frequenti
Un SBOM è la stessa cosa di una scansione di vulnerabilità?
No. L’SBOM è l’inventario dei componenti; la scansione incrocia quell’inventario con i database CVE per rilevare vulnerabilità. Si completano: prima sai cosa hai, poi se è vulnerabile.
SPDX o CycloneDX?
SPDX è uno standard ISO molto usato in conformità; CycloneDX è più orientato alla sicurezza. Molti strumenti esportano verso entrambi, quindi non devi sceglierne uno solo.
Mi serve un SBOM se consumo solo immagini di terzi?
Sì. Chiedere o generare l’SBOM delle immagini che usi ti permette di valutarne il rischio e rispondere in fretta alle vulnerabilità, anche se non le hai costruite tu.
In imaxe.cloud puntiamo sulla tracciabilità: inventariare e documentare il software delle nostre immagini fa parte del costruirle bene.
