Cryptographic Bill of Materials (CBOM): sapere che crittografia si usa prima di migrare

Il Cryptographic Bill of Materials (CBOM) risponde a una domanda che quasi ogni organizzazione, di fronte alla migrazione post-quantum, scopre di non saper trasformare in un elenco: dove, e con quali algoritmi, chiavi e certificati, l’azienda usa la crittografia. Sembra una domanda banale, e invece è insidiosa, perché la crittografia non vive in un posto solo. È incorporata nelle applicazioni, nelle librerie di terze parti, nei protocolli negoziati a runtime, nei certificati che scadono in silenzio, nell’hardware. Nessuno l’ha mai censita davvero, perché finora non è servito. Ora serve, e serve in fretta.

La ragione è la transizione verso una crittografia resistente ai computer quantistici, spinta da scadenze ormai fissate e dalla minaccia del “raccogli ora, decifra dopo”, che rende urgente proteggere già oggi i segreti destinati a durare a lungo. Ma prima di sostituire un algoritmo bisogna sapere di averlo. Il CBOM è lo strumento standardizzato che trasforma questa consapevolezza da esercizio manuale a inventario ripetibile, ed è la prima mossa concreta di una migrazione che, senza di esso, procederebbe alla cieca.

Che cos’è un Cryptographic Bill of Materials

Un Cryptographic Bill of Materials è l’inventario strutturato e leggibile dalle macchine degli asset crittografici di un sistema: gli algoritmi, le chiavi, i certificati e i protocolli, insieme alle relazioni che li legano ai componenti software che li usano. È l’estensione, al mondo della crittografia, di un’idea già familiare: quella del Software Bill of Materials. Come l’SBOM elenca le componenti di cui un software è fatto, il CBOM elenca la crittografia che quel software impiega, e dove la impiega. La differenza è che qui le dipendenze non sono librerie ma primitive crittografiche, ed è proprio la loro invisibilità a rendere l’inventario necessario.

Lo standard di riferimento è nato in ambito aperto. Il formato CBOM è stato introdotto in CycloneDX, il progetto di OWASP per le distinte dei materiali, con la versione 1.6 dell’aprile 2024, su un contributo iniziale di IBM Research, ed è stato poi standardizzato come ECMA-424. Non si è fermato lì: la versione 1.7, rilasciata nell’ottobre 2025 e ratificata come ECMA-424 di seconda edizione a dicembre 2025, ne ha ampliato le capacità, aggiungendo un elenco standardizzato delle famiglie di algoritmi e una lista completa delle curve ellittiche, utili anche fuori da CycloneDX per le verifiche di conformità e di prontezza al post-quantum. Non è quindi un formato proprietario legato a un fornitore, ma una grammatica comune con cui descrivere la postura crittografica di un’organizzazione, generarla con strumenti di scoperta automatica e scambiarla come si scambia già un SBOM.

Perché l’inventario viene prima della migrazione

Gli standard post-quantum, almeno i principali, ci sono: nell’agosto 2024 il NIST ha finalizzato i primi tre algoritmi resistenti al calcolo quantistico (FIPS 203, 204 e 205). E “primi” è la parola esatta, perché il quadro non è ancora completo: un ulteriore algoritmo, HQC, è stato selezionato nel marzo 2025, e la firma FN-DSA (FIPS 206) è tuttora in lavorazione. Le agenzie, intanto, hanno iniziato a fissare le date entro cui abbandonare gli algoritmi vulnerabili. Il problema, insomma, non è più quale crittografia adottare, ma dove va applicata, ed è qui che casca l’asino: la maggior parte delle organizzazioni non possiede una mappa di dove e come usa la crittografia. È un sapere sparso tra team diversi, sepolto in codice scritto anni prima, delegato a componenti che nessuno controlla riga per riga.

Non a caso le stesse autorità mettono l’inventario al primo posto. Il documento congiunto di CISA, NSA e NIST, dell’agosto 2023, indica come passo iniziale proprio la costruzione di un inventario crittografico: sapere quali algoritmi sono in uso, in quali sistemi, a protezione di quali dati. È l’applicazione di un principio tanto semplice quanto trascurato, cioè che non si può migrare ciò che non si vede. Senza quella mappa, ogni piano di transizione resta una stima, e ogni scadenza un salto nel buio.

Da allora le autorità hanno alzato la posta, e il CBOM è passato dalle raccomandazioni a un atto di governo. Con l’ordine esecutivo di giugno 2026 sulla sicurezza crittografica (Executive Order 14412), la Casa Bianca ha incaricato il Dipartimento della Sicurezza interna, tramite la CISA e in coordinamento con il NIST, di pubblicare entro 270 giorni, quindi verso il 19 marzo 2027, una guida sugli elementi minimi di un cryptographic bill of materials capace di abilitare la valutazione automatizzata degli asset crittografici di un componente hardware o software. È la prima volta che una direttiva federale nomina il CBOM come artefatto definito: il segnale che l’inventario non è più una buona pratica suggerita, ma la base su cui si costruirà la conformità.

Non solo Stati Uniti: la spinta arriva anche dall’Europa

Il baricentro del dibattito è statunitense, ma la stessa direzione si legge in Europa, ed è la parte che riguarda più da vicino chi lavora in Italia. La Coordinated Implementation Roadmap del Gruppo di Cooperazione NIS, del giugno 2025, chiede agli Stati membri di avviare la transizione entro la fine del 2026, di completare la migrazione delle infrastrutture critiche non oltre il 2030 e di estenderla ai sistemi restanti, per quanto praticabile, entro il 2035. La spinta potrebbe poi irrigidirsi in obbligo: la proposta COM(2026) 13, presentata dalla Commissione nel gennaio 2026 nell’ambito di un pacchetto di semplificazione della direttiva NIS2 e di allineamento al Cybersecurity Act, se approvata da Parlamento e Consiglio scriverebbe la crittografia post-quantum direttamente nel testo della direttiva, trasformando la pianificazione da interpretazione della clausola sullo “stato dell’arte” a requisito esplicito.

Per l’Italia la scadenza di fine 2026 è vicina, e il segnale nazionale è già arrivato: l’11 giugno 2026 l’Agenzia per la Cybersicurezza Nazionale ha pubblicato due nuovi documenti sulle funzioni crittografiche, dedicati ai cifrari a flusso e alle firme digitali, e ha aggiornato alla versione 2.0 la guida sul TLS, integrandovi le soluzioni post-quantum. Il messaggio, su entrambe le sponde dell’Atlantico, converge: la migrazione ha una data, e una data trasforma l’inventario da progetto rimandabile a compito immediato.

Dal CBOM alla crypto-agility

L’inventario, di per sé, non protegge nulla: è il presupposto di ciò che viene dopo. Con una fotografia accurata della crittografia in uso, un’organizzazione può fare ciò che senza quella mappa resta un’ipotesi. Può individuare gli algoritmi vulnerabili al quantum e distinguerli da quelli ancora solidi; può stabilire una priorità, mettendo in cima ciò che protegge segreti destinati a durare anni; può scovare la crittografia debole o scaduta che si annida ovunque, non solo quella da rimpiazzare in vista del post-quantum.

È qui che il CBOM incontra la crypto-agility, cioè la capacità di cambiare algoritmo senza riscrivere l’applicazione da capo. Se la crypto-agility è l’obiettivo, il CBOM è la mappa che lo rende raggiungibile: non si può sostituire in modo ordinato ciò di cui si ignora la collocazione. Un inventario tenuto aggiornato trasforma una migrazione monolitica e rischiosa in una serie di interventi mirati e verificabili, e permette di dimostrare a un revisore, dati alla mano, a che punto sia la transizione. La stessa logica vale per la migrazione post-quantum nel suo complesso, che diventa gestibile solo quando poggia su un inventario reale anziché su una supposizione.

I limiti: un inventario non è una migrazione

Sarebbe però un errore trattare il CBOM come una soluzione anziché come un punto di partenza. La scoperta della crittografia è tecnicamente difficile: gli algoritmi si nascondono nei binari, nell’hardware, nelle componenti di terze parti e nei protocolli decisi solo al momento della connessione, e nessuno strumento li individua tutti con certezza. Un CBOM, inoltre, è una fotografia, e come ogni fotografia invecchia: senza un processo che lo mantenga aggiornato si trasforma in fretta nel ritratto di un sistema che non esiste più. Gli strumenti di generazione stanno maturando, ma non sono ancora chiavi in mano, e la parte più insidiosa resta la crittografia che non lascia tracce facili da leggere.

Proprio per questo l’inventario non va inteso come una precondizione da esaurire prima di muoversi. Commentando l’ordine esecutivo, Cloudflare ha messo in guardia dal trasformare il CBOM esaustivo in un prerequisito paralizzante: catalogare ogni algoritmo in ogni libreria richiede molto tempo, e il rischio è che l’inventario risulti già superato nel momento in cui viene completato. La lezione è pratica: conviene procedere in parallelo, cominciando a migrare i sistemi più esposti mentre l’inventario si affina, invece di attendere una mappa perfetta che forse non arriverà mai.

Va poi ricordato che l’inventario, da solo, non corregge nulla. Elencare gli algoritmi deboli non li sostituisce, e produrre un CBOM solo per spuntare una casella di conformità, senza usarlo per pianificare e verificare, è un costo senza ritorno. La via realistica è duplice: automatizzare la scoperta il più possibile e integrarla nei processi, così che l’inventario si aggiorni da sé, e trattare il CBOM come uno strumento di lavoro continuo, non come un allegato prodotto una volta e poi dimenticato.

Cosa aspettarsi, senza illusioni

La migrazione post-quantum sarà la più grande transizione crittografica degli ultimi decenni, e il Cryptographic Bill of Materials ne è la parte meno vistosa e più decisiva, quella da cui dipende tutto il resto. Il ritorno concreto non è un documento in più, ma la capacità di rispondere con i dati a domande che oggi ricevono solo stime: quali sistemi usano crittografia vulnerabile, dove, e con quale priorità intervenire. L’orologio del “raccogli ora, decifra dopo” ha già iniziato a scorrere per i dati che devono restare riservati a lungo, e partire dall’inventario è il primo passo verso una postura crittografica difendibile. Chi tratta il CBOM come un adempimento otterrà un file inutile; chi lo tratta come la mappa su cui costruire la propria crypto-agility otterrà il controllo di una transizione che, altrimenti, subirà alla scadenza.