Nuovi obblighi per gli SBOM: CISA impone firma digitale e copertura senza limiti delle dipendenze

La CISA aggiorna le linee guida SBOM: obbligatori la firma digitale e la copertura totale delle dipendenze transitive per i fornitori software.

Nuovi obblighi per gli SBOM: CISA impone firma digitale e copertura senza limiti delle dipendenze
Vulnerabilità

Immagine illustrativa generata con AI

Il 31 luglio 2026 la CISA, insieme a 16 enti governativi di quattro continenti, ha pubblicato la versione aggiornata della guida sugli elementi minimi per il Software Bill of Materials. Il documento sostituisce le linee guida NTIA del 2021 e porta con sé dieci nuovi campi obbligatori, il passaggio dal concetto di “profondità” a quello di “copertura” e l’introduzione della firma digitale per attestare integrità e autenticità. Il giorno successivo, l’agenzia ha diffuso anche una guida separata sulla sicurezza dell’open source.

I dieci campi che ridisegnano l’inventario software

La nuova guida aggiunge dieci elementi finora assenti. Tra questi, il più impattante è la firma digitale dello SBOM, pensata per garantirne l’integrità e l’autenticità lungo tutta la supply chain. A fianco compare l’obbligo di indicare nome e versione dello strumento usato per generare l’inventario, insieme ad altri dati che rendono tracciabile l’origine di ogni componente.

La bozza iniziale, risalente al 2025, è stata affinata dopo aver ricevuto commenti da oltre 90 organizzazioni, tra cui Google, Microsoft e AWS. Il risultato è un insieme di requisiti che, pur formalizzando pratiche già diffuse—come nota Jeff Williams di OWASP e Contrast Security—rende più stringente la trasparenza richiesta a chi fornisce software al governo federale.

Dalla profondità alla copertura: addio ai limiti sulle dipendenze indirette

La modifica strutturale più rilevante riguarda la gestione delle dipendenze. Fino a ieri il campo “depth” fissava un livello massimo di annidamento da dichiarare. La nuova guida lo elimina e introduce il campo “coverage”: da ora in poi lo SBOM deve includere tutte le dipendenze transitive, cioè le dipendenze delle dipendenze, senza alcun tetto di profondità.

Questo cambio costringe i fornitori a un’analisi ricorsiva completa dei componenti di terze parti, riducendo i punti ciechi in cui una vulnerabilità poteva nascondersi in un pacchetto nidificato oltre il limite precedente. La copertura diventa un requisito assoluto, non più parametrabile.

Cosa significa per chi fornisce software al governo USA

Le organizzazioni che operano in regime di conformità federale dovranno adeguare i propri processi di generazione SBOM per rispettare tre vincoli immediati:

  • includere la firma digitale;
  • registrare lo strumento e la versione usati per produrre l’inventario;
  • estendere l’analisi a tutti i livelli di dipendenza, senza eccezioni.

Non sono obblighi rivoluzionari, perché gli strumenti basati su SPDX e CycloneDX già offrono buona parte di queste funzionalità. Tuttavia, l’irrigidimento formale alza la posta per la gestione del rischio supply chain e per la conformità ai framework derivati dalle indicazioni CISA.

Le critiche: senza VEX e verifica l’SBOM resta uno strumento parziale

Secondo Williams, la guida non coglie due nodi essenziali. Manca innanzitutto il VEX (Vulnerability Exploitability eXchange), ossia un formato per contestualizzare l’effettiva sfruttabilità delle vulnerabilità in uno specifico contesto di deployment. In sua assenza, lo SBOM continua a produrre elenchi di CVE senza aiutare a stabilire priorità di patching.

Il secondo punto dolente è la verifica di accuratezza e copertura. La guida non richiede che l’inventario dichiarato corrisponda a quanto effettivamente distribuito o deployato, né prevede controlli automatici di coerenza. Questo limita l’utilità pratica del documento nelle decisioni di sicurezza quotidiane. In attesa di evoluzioni, l’esperto consiglia verifiche interne di completezza e corrispondenza tra SBOM e artefatti reali.

Il giorno dopo: una guida sulla sicurezza dell’open source

Il 1° agosto CISA ha pubblicato una seconda guida, dedicata alle best practice per la sicurezza del software open source. Non è un’integrazione diretta del nuovo SBOM, ma si affianca al quadro complessivo con cui l’agenzia sta ridisegnando i requisiti di trasparenza e rigore nella catena del software, estendendo le indicazioni anche all’ecosistema dei componenti aperti.

Leggi anche

Fonti

Questo articolo è una rielaborazione originale basata sulle fonti seguenti.

Torna alla home

Ultime notizie di cybersecurity

Tutte le notizie di cybersecurity →