CISA e la nuova maturita degli SBOM: guida pratica

Negli ultimi due anni CISA ha ridefinito completamente l’approccio agli SBOM (Software Bill of Materials), passando da una semplice lista di campi minimi a un vero e proprio ecosistema di requisiti pensati per l’automazione e l’uso operativo. Chi lavora nella sicurezza informatica, nel procurement o nel DevSecOps deve conoscere questa evoluzione, perché cambia radicalmente il modo in cui aziende e pubbliche amministrazioni gestiscono la trasparenza della supply chain software. Vediamo insieme cosa è cambiato e come adeguarsi.

Dal modello minimo alla maturità dello SBOM

Fino a poco tempo fa, uno SBOM doveva contenere solo alcuni campi essenziali. Oggi non basta più. CISA ha introdotto un modello di maturità che distingue tra elementi minimi, raccomandati e aspirazionali.

Il documento “Framing Software Component Transparency” del 2024 ha segnato questo cambio di paradigma. Lo SBOM non è più visto come un semplice elenco statico, ma come un artefatto vivo, che porta con sé informazioni sul contesto di generazione e sulla fase del ciclo di vita del software in cui è stato creato.

Questo significa che un’azienda non può più limitarsi a produrre uno SBOM una tantum. Deve integrarlo nel proprio processo di sviluppo, aggiornarlo costantemente e tracciarne l’evoluzione nel tempo.

I nuovi requisiti tecnici: cosa cambia davvero

Il draft 2025, con aggiornamento previsto nel 2026, introduce elementi molto più stringenti rispetto al passato. Ecco i principali:

• Firma digitale dell’autore dello SBOM, per garantirne autenticità
• Versionamento esplicito del documento SBOM
• Tool di generazione utilizzato, per tracciabilità
• Contesto e fase del lifecycle in cui lo SBOM è stato prodotto
• Identificatori dei componenti più precisi, come i PURL
• Hash crittografici e relativo algoritmo utilizzato
• Informazioni sulla licenza di ogni componente
• Copertura estesa, incluse le dipendenze transitive senza limiti di profondità
• Distinzione chiara tra “unknown” e informazioni semplicemente non fornite

L’obiettivo è chiaro: rendere lo SBOM verificabile, completo e soprattutto machine-processable, ovvero utilizzabile direttamente dagli strumenti automatizzati di gestione del rischio.

Cosa cambia in pratica per aziende e governi

Questi nuovi requisiti non sono solo teoria. Comportano cambiamenti operativi concreti che ogni organizzazione dovrebbe iniziare a pianificare fin da ora.

Integrazione nelle pipeline CI/CD

Lo SBOM deve essere generato automaticamente all’interno delle pipeline di sviluppo, con versioning e aggiornamenti continui. Non è più accettabile produrlo manualmente a fine progetto.

Metadati da raccogliere

Ogni organizzazione dovrà predisporre processi per raccogliere e conservare:

• Autore e versione dello SBOM
• Firma digitale e timestamp di generazione
• Identificatori canonici dei componenti (nome, versione, purl)
• Hash e algoritmo di hashing
• Informazioni su licenze e distribuzione

Formati e procurement

Sul fronte dei formati, la convergenza pratica è verso SPDX e CycloneDX, entrambi machine-readable e ampiamente supportati dagli strumenti di mercato. Questi formati permettono anche il mapping verso VEX e CSAF, fondamentali per l’orchestrazione della gestione delle vulnerabilità.

Anche i contratti di procurement dovranno evolversi: sarà necessario richiedere SBOM versionate, firmate e costantemente aggiornate, con SLA precisi per gli aggiornamenti post-patch.

Impatti su vulnerability management e supply chain

Questi nuovi requisiti non sono burocrazia fine a se stessa. Hanno un impatto diretto sulla capacità di gestire le vulnerabilità in modo efficace.

Con identificatori più precisi e copertura completa delle dipendenze transitive, il mapping tra vulnerabilità e componenti reali diventa molto più accurato. Questo si traduce in un triage più rapido e in una prioritizzazione migliore degli interventi di remediation.

Inoltre, la presenza di hash, firme e tracciabilità del tool di generazione aumenta la fiducia nei dati, riducendo falsi positivi e falsi negativi nelle correlazioni automatiche. Anche l’attribuzione di responsabilità nella supply chain migliora, distinguendo chiaramente tra chi produce il software e chi genera lo SBOM.

Le criticità da non sottovalutare

Non tutto è semplice in questo nuovo scenario. Ci sono sfide concrete che aziende e organizzazioni dovranno affrontare.

• Costi operativi: più metadati significano più investimenti in tooling, personale e automazione
• Qualità dei dati: molte supply chain hanno componenti con provenance sconosciuta o build ibride difficili da tracciare
• Obsolescenza rapida: senza automazione, gli SBOM diventano obsoleti in fretta in contesti con release frequenti
• Interoperabilità: l’adozione disomogenea di formati tra vendor diversi può creare frizioni
• Ambiti complessi: servizi SaaS, cloud e componenti basati su intelligenza artificiale restano difficili da rappresentare con gli SBOM tradizionali
• Privacy e proprietà intellettuale: un livello di dettaglio troppo elevato può sollevare questioni di segretezza commerciale

Raccomandazioni pratiche per iniziare subito

Per chi si occupa di procurement, DevSecOps o gestione degli incidenti, ecco alcune azioni concrete da mettere in pratica:

1. Trattare lo SBOM come un artefatto di processo, integrato nel CI/CD con versioning e firma
2. Richiedere contrattualmente SBOM firmate, aggiornate e in formato machine-readable
3. Automatizzare la verifica di hash e firme, integrandola con feed di vulnerabilità basati su VEX e CSAF
4. Definire policy chiare per la gestione degli elementi “unknown”
5. Costruire un inventario SBOM centralizzato per mappare e prioritizzare la remediation
6. Valutare con attenzione gli impatti su privacy e proprietà intellettuale, prevedendo eventualmente clausole NDA

Conclusione

L’evoluzione degli SBOM promossa da CISA rappresenta un cambio di paradigma importante nella sicurezza della supply chain software. Si passa da documenti statici e minimali a strumenti dinamici, verificabili e pienamente integrati nei processi di sviluppo e gestione del rischio.

Le organizzazioni che vogliono restare competitive e conformi dovranno investire in automazione, formati standardizzati come SPDX e CycloneDX, e processi solidi per la gestione dei metadati. Le sfide non mancano, dalla qualità dei dati ai costi operativi, ma i benefici in termini di sicurezza e capacità di risposta alle vulnerabilità giustificano ampiamente lo sforzo.

Chi inizia oggi a strutturare questi processi sarà pronto per affrontare i requisiti sempre più stringenti che arriveranno nei prossimi aggiornamenti normativi.