Non si migra ciò che non si sa enumerare: il Cryptographic Bill of Materials che le banche ancora non hanno

TL;DR. La scadenza di ricognizione NCSC del 2028 precede ogni scadenza di migrazione. Le banche non possono rispettarla: il registro DORA ignora la crittografia.

Punti chiave

La scadenza che nessuno ha messo a budget. Basta leggere con attenzione le tempistiche di migrazione pubblicate perché la sequenza risulti inequivocabile.
Il vostro registro DORA annota tutto tranne la crittografia. Ecco la parte che sorprende.
Che cosa contiene davvero un CBOM. Un Cryptography Bill of Materials è un inventario formale degli asset crittografici di un sistema — algoritmi, chiavi, certificati e protocolli, con le loro relazioni verso i componenti software che li usano.
La ricognizione è quattro problemi, non uno. Trattare la ricognizione come un unico flusso di lavoro è il modo più comune in cui questi programmi falliscono.

Ogni roadmap post-quantistica del settore bancario presuppone un inventario che non esiste. I piani sono scritti, i comitati di indirizzo si riuniscono, le scorecard sono in giallo. Sotto tutto questo si nasconde l'assunto che qualcuno, da qualche parte, sia in grado di produrre l'elenco di ogni punto in cui la banca esegue un'operazione crittografica: quale algoritmo, quale lunghezza della chiave, quale libreria, quale certificato, con quale scadenza. Quasi nessun istituto ci riesce. La prima tappa fissata dall'NCSC non è una tappa di migrazione: è una tappa di ricognizione, con scadenza 2028, ed è quella che nessuno ha messo a budget.

Sintesi per la direzione

La sequenza è ricognizione, poi agilità, poi migrazione. Le linee guida dell'NCSC fissano una tappa di ricognizione definita nel 2028, la migrazione a massima priorità nel 2031 e il completamento entro il 2035. Un istituto che inizia a migrare prima di aver enumerato migrerà i sistemi che per caso conosce.

Il registro che avete non risponde alla domanda che avete davanti. DORA Article 8 impone agli enti finanziari di identificare, classificare e documentare gli asset ICT e di mapparne le interdipendenze. Non richiede una sola proprietà crittografica: un registro conforme ad Article 8 può quindi essere completo e restare inutile per la pianificazione dell'agilità crittografica.

Lo standard esiste già. Gli asset crittografici — algoritmi con dimensione della chiave, modalità e curva; chiavi; certificati; protocolli — sono rappresentabili in CycloneDX, pubblicato come ECMA-424. È una questione di schema, non di procurement.

Il quarto più difficile non è vostro da scansionare. Moduli di sicurezza hardware, appliance di pagamento, librerie incorporate dai fornitori e provider SaaS non si enumerano puntandoci contro uno scanner. Quella parte dell'inventario si costruisce con l'attestazione contrattuale, e la clausola deve esistere prima della roadmap.

La scadenza che nessuno ha messo a budget

Basta leggere con attenzione le tempistiche di migrazione pubblicate perché la sequenza risulti inequivocabile. La roadmap del National Cyber Security Centre colloca la ricognizione — un quadro completo di quali sistemi e servizi dipendono dalla crittografia — al 2028, il lavoro di migrazione a massima priorità al 2031 e il completamento su tutti i sistemi, servizi e prodotti al 2035. Il rapporto di transizione del NIST, IR 8547, procede su un binario compatibile: gli algoritmi a chiave pubblica vulnerabili al quantistico, RSA ed ECC inclusi, sono deprecati dopo il 2030 e vietati dopo il 2035.

La maggior parte dei programmi bancari ha interiorizzato il 2035 come la data. È l'estremo sbagliato del calendario da cui pianificare.

Due date contano molto di più. La prima è il 2028, perché la ricognizione è l'input di tutto ciò che viene dopo: non si può dimensionare, quantificare o sequenziare una migrazione contro un denominatore ignoto. La seconda è il 2030, perché «deprecato» non è una parola morbida in un istituto vigilato: è il momento in cui continuare ad affidarsi a un algoritmo diventa una decisione che qualcuno deve firmare.

Da qui al 2028 mancano meno di trenta mesi. Sono uno, forse due cicli di budget per costruire una capacità che la maggior parte degli istituti non ha ancora avviato.

Il vostro registro DORA annota tutto tranne la crittografia

Ecco la parte che sorprende. La maggior parte delle grandi banche europee mantiene già un inventario dettagliato e rivisto con regolarità degli asset ICT, perché DORA le obbliga a farlo.

Article 8 del Regulation (EU) 2022/2554 impone agli enti finanziari di identificare, classificare e documentare adeguatamente tutte le funzioni aziendali supportate da ICT, le informazioni e gli asset ICT che le sostengono, nonché i rispettivi ruoli e dipendenze rispetto al rischio ICT — e di mappare la configurazione di quegli asset e i collegamenti fra loro, tenendoli sotto revisione.

È un inventario serio. Ed è anche della forma sbagliata per questo problema.

Tabella 1: il registro che avete e il registro che la tappa 2028 richiede

Domanda	Registro degli asset ICT (DORA Article 8)	Inventario crittografico (CBOM)
Che cos'è questo asset e chi ne è il proprietario?	Sì — è il nucleo del registro	Non è il suo scopo
Quanto è critico e da cosa dipende?	Sì — classificazione e mappatura delle interdipendenze	Ereditato dal registro degli asset
Quali algoritmi usa, e dove?	No	Sì — per componente, con dimensione della chiave, modalità e curva
Quale libreria li implementa, in quale versione?	In parte, tramite l'SBOM se esiste	Sì, come relazione esplicita
Quali certificati presenta, con quale scadenza?	Raramente, e di solito in uno strumento PKI separato	Sì
Dove risiedono le chiavi e come sono protette?	No	Sì — inclusa la presenza di un HSM nel percorso
Questo asset è vulnerabile al quantistico?	Non è deducibile	Risposta diretta

L'ultima riga è tutto l'argomento. Un istituto può essere pienamente conforme ad Article 8, superare l'ispezione e restare incapace di rispondere a «quanti dei nostri sistemi si romperanno nel 2030» senza commissionare da zero un progetto di ricognizione.

Non è una critica a DORA. Article 8 è stato scritto per rispondere a domande di resilienza e concentrazione, e vi risponde bene. Semplicemente non è stato scritto per rispondere a una domanda di agilità crittografica, e i due registri vanno uniti anziché gestiti come fogli di calcolo separati in mano a team separati.

Che cosa contiene davvero un CBOM

Un Cryptography Bill of Materials è un inventario formale degli asset crittografici di un sistema — algoritmi, chiavi, certificati e protocolli, con le loro relazioni verso i componenti software che li usano.

Il punto strutturale importante è che non si tratta di un nuovo formato di file. Il supporto agli asset crittografici è stato contribuito a CycloneDX, la specifica di bill of materials sostenuta da OWASP, pubblicata come standard Ecma International, ECMA-424. Un CBOM è quindi un documento CycloneDX con i campi crittografici popolati. Si valida con lo stesso schema, attraversa le stesse pipeline e finisce nello stesso registro di artefatti degli SBOM che un istituto già produce per la supply chain.

Conta più di quanto sembri. La differenza fra uno standard che entra in produzione e uno che si arena sta di solito nel fatto che richieda o meno nuove tubature. Questo non le richiede.

Tabella 2: classi di asset del CBOM e domanda di migrazione a cui rispondono

Classe di asset	Che cosa viene registrato	La domanda a cui risponde
Algoritmo	Primitiva, dimensione della chiave, modalità, curva, padding e funzione svolta	Quali delle nostre operazioni sono vulnerabili al quantistico, e con quale robustezza dei parametri?
Chiave	Tipo, dimensione, formato, stato e luogo in cui risiede il materiale	Quali chiavi sono protette da un HSM e quali stanno nella memoria dell'applicazione?
Certificato	Soggetto, emittente, algoritmo di firma, finestra di validità	Che cosa scade prima della finestra di migrazione e che cosa è firmato con un algoritmo deprecato?
Protocollo	Protocollo e versione, con le suite di cifratura offerte	Che cosa viene realmente negoziato sul filo, rispetto a quanto dichiara il file di configurazione?
Componente correlato	Libreria, versione e posizione nel codice che implementano quanto sopra	Se questa libreria viene sostituita, che cos'altro si muove con essa?

L'ultima riga è quella che trasforma un inventario in un piano. Un elenco di algoritmi vi dice la dimensione del problema. Un elenco di algoritmi unito ai componenti che li implementano vi dice la forma del lavoro — ed è da lì che si costruisce davvero una sequenza di migrazione.

La ricognizione è quattro problemi, non uno

Trattare la ricognizione come un unico flusso di lavoro è il modo più comune in cui questi programmi falliscono. Sono quattro problemi distinti, con quattro strumenti diversi, quattro proprietari diversi e livelli di confidenza molto diversi.

1. Codice sorgente — che cosa chiede il codice. L'analisi statica sui vostri repository individua chiamate crittografiche, parametri cablati nel codice e librerie invocate. Il tooling aperto esiste: il progetto CBOMkit e il suo plugin SonarQube rilevano asset crittografici nel sorgente ed emettono CycloneDX. Confidenza massima, copertura minima — vede solo il codice che avete scritto e che ancora compilate.

2. Binari e container — che cosa arriva davvero in produzione. L'analisi del sorgente non vede nulla di ciò che entra come dipendenza compilata o è cotto dentro un'immagine di base. La scansione di container e filesystem colma parte di quella lacuna. Aspettatevi che le due viste non coincidano; il disaccordo è esso stesso un rilievo.

3. La rete — che cosa viene negoziato realmente. La configurazione è un'intenzione, non un'osservazione. L'osservazione passiva della negoziazione TLS in tempo reale su tutto il parco è l'unico modo per scoprire che un servizio che documenta TLS 1.3 accetta ancora qualcosa di più vecchio con una controparte interna che non si è mai aggiornata. In un parco di pagamento, quella controparte è spesso quella che conta.

4. Il parco fornitori e hardware — ciò che non potete scansionare affatto. Moduli di sicurezza hardware, terminali di pagamento, appliance di rete, sottosistemi mainframe e ogni provider SaaS della catena. Nessuno scanner li raggiunge. Questo quarto si enumera chiedendo, per contratto, ed è dove si concentra l'esposizione autentica del wholesale banking, perché i sistemi che compensano e regolano sono in misura sproporzionata forniti da terzi.

Il quarto è quello da avviare subito, perché ha i tempi di preavviso più lunghi e non è un'attività ingegneristica. È un'attività di procurement: portare una clausola di disclosure crittografica e di agilità crittografica dentro il contratto e dentro il modello di rinnovo, così che entro il 2028 la risposta arrivi come obbligo del fornitore anziché come cortesia. Ogni trimestre in cui quella clausola manca dal modello è un trimestre di rinnovi che andranno riaperti più avanti.

Farne un controllo anziché un progetto

Il modo di fallire su cui scommetterei non è che le banche saltino l'inventario. È che lo commissionino una tantum, consegnino nel 2028 una fotografia difendibile e la lascino decadere — perché è stato finanziato come deliverable di un progetto post-quantistico anziché costruito come controllo mantenuto nel tempo.

Un inventario crittografico decade più in fretta di un registro degli asset. I certificati ruotano. Le librerie vengono aggiornate dall'automazione delle dipendenze. Un'immagine di base cambia e un intero servizio acquisisce in silenzio uno stack TLS diverso. Una fotografia scattata nel 2028 sarà materialmente errata già nel 2029, esattamente quando il lavoro di prioritizzazione del 2031 dipenderà da essa.

Tre impegni lo evitano.

Generatelo nella pipeline, non con un'indagine. Un CBOM va emesso dalla build, accanto all'SBOM, e conservato come artefatto versionato associato alla release. Un inventario assemblato inviando un questionario via e-mail ai responsabili applicativi è già obsoleto all'arrivo e non è confrontabile.

Confrontatelo e allertate sulla differenza. Il segnale di valore non è l'inventario: è la variazione dell'inventario. Un servizio che ha acquisito una nuova dipendenza crittografica, un certificato che si è accorciato, un algoritmo comparso dove prima non c'era — questi sono gli eventi che meritano un controllo. È lo stesso ragionamento per cui confrontare gli SBOM è più utile che archiviarli.

Unitelo al registro che già tenete. Il CBOM risponde a «quale crittografia»; il registro Article 8 risponde a «quanto critico, di chi, e che cosa vi dipende sopra». Nessuno dei due è una prioritizzazione da solo. Uniti, producono l'unica graduatoria che conta: le operazioni vulnerabili al quantistico ordinate per criticità della funzione aziendale che vi poggia sopra. Quell'unione è il vero deliverable di un programma di ricognizione, e vale la pena chiamarla così nel piano.

Il manuale operativo

Riformulate la tappa 2028 come capacità, non come relazione. Il deliverable è un inventario mantenuto e leggibile dalle macchine che si rigenera da solo, non un documento prodotto una volta per un supervisore.
Emettete i CBOM dalla build subito, partendo dai nuovi servizi. Non tentate il parco in un colpo solo. Cablatelo nella pipeline per tutto ciò che viene costruito o modificato in modo sostanziale quest'anno, così la copertura si accumula invece di richiedere una campagna.
Inserite la clausola contrattuale nel modello di rinnovo entro questo trimestre. Disclosure crittografica e impegno di agilità crittografica. Ha i tempi di preavviso più lunghi dell'intero elenco e non dipende da alcuna scelta di tooling.
Avviate l'osservazione di rete prima di tutto sui percorsi di pagamento e regolamento. È lì che lo scarto fra configurazione e realtà fa più danni e dove si concentrano le controparti legacy.
Unite il CBOM al registro Article 8 e stilate la graduatoria sull'unione. Pubblicate l'elenco ordinato. È l'artefatto che converte un inventario ingegneristico in una conversazione di consiglio su sequenza e denaro.
Confrontate ogni rigenerazione e allertate sulle nuove dipendenze vulnerabili al quantistico. Un inventario senza confronto è un archivio.

Gli istituti che arriveranno al 2031 senza affanno non sono quelli con la visione più avanzata di ML-KEM. Sono quelli capaci di rispondere, una mattina qualsiasi e senza commissionare un progetto, alla domanda su dove sia realmente la loro crittografia.

Domande frequenti

Un CBOM è una cosa diversa da un SBOM?
È lo stesso tipo di documento con campi diversi popolati. Il supporto agli asset crittografici è confluito in CycloneDX, pubblicato come ECMA-424: un CBOM si valida quindi contro lo stesso schema e attraversa lo stesso tooling di un SBOM. Gli istituti che già generano SBOM sono più vicini al traguardo di quanto di solito immaginino.

DORA richiede un inventario crittografico?
Non in questi termini. Article 8 del Regulation (EU) 2022/2554 richiede identificazione, classificazione e documentazione degli asset ICT e la mappatura della loro configurazione e interdipendenze. Le proprietà crittografiche non rientrano fra gli attributi che vi obbliga a registrare, ed è per questo che un registro conforme ad Article 8 non può rispondere a una domanda di vulnerabilità al quantistico senza essere esteso.

Perché la ricognizione deve chiudersi così in anticipo rispetto alla migrazione?
Perché è l'input della prioritizzazione. Le linee guida NCSC fissano la ricognizione al 2028 e la migrazione a massima priorità al 2031 proprio per lasciare un intervallo definito in cui ordinare il parco e sequenziare il lavoro. Comprimere le due fasi significa migrare ciò che si conosce meglio anziché ciò che conta di più.

Come inventariamo la crittografia dentro l'hardware dei fornitori e il SaaS?
Non la si scansiona: se ne pretende la disclosure. Moduli di sicurezza hardware, appliance di pagamento e fornitori di servizi devono essere coperti da un obbligo contrattuale di disclosure crittografica e agilità crittografica. Poiché dipende dai cicli di rinnovo anziché dallo sforzo ingegneristico, ha i tempi di preavviso più lunghi dell'intero programma e va avviato per primo.

Conviene aspettare che il tooling maturi prima di iniziare?
No, e l'argomento del tooling è di solito un surrogato dell'argomento del budget. Implementazioni aperte emettono già inventari crittografici CycloneDX dal sorgente e dalle immagini container, e la specifica è uno standard ratificato. Il vincolo sulla tappa 2028 è la copertura e la portata contrattuale, non la disponibilità di strumenti.

Riferimenti

European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Bruxelles: Gazzetta ufficiale dell'Unione europea. Disponibile su: European Parliament and Council of the European Union, 2022..
National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. Londra: NCSC. Disponibile su: National Cyber Security Centre, 2025..
National Institute of Standards and Technology, 2024. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. Gaithersburg: U.S. Department of Commerce. Disponibile su: National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Gaithersburg: U.S. Department of Commerce. Disponibile su: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Disponibile su: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Disponibile su: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Disponibile su: IBM Research, 2026..

Ultima revisione 2026-08-05.

Ripubblica questo articolo

Non si migra ciò che non si sa enumerare: il Cryptographic Bill of Materials che le banche ancora non hanno — Sebastien Rousseau

La scadenza di ricognizione NCSC del 2028 precede ogni scadenza di migrazione. Le banche non possono rispettarla: il registro DORA ignora la crittografia.

Questo articolo è pubblicato con licenza Creative Commons Attribution 4.0 International. La ripubblicazione richiede l'attribuzione all'URL canonico.

Non si migra ciò che non si sa enumerare: il Cryptographic Bill of Materials che le banche ancora non hanno — Sebastien Rousseau

La scadenza di ricognizione NCSC del 2028 precede ogni scadenza di migrazione. Le banche non possono rispettarla: il registro DORA ignora la crittografia.

Originally published at https://sebastienrousseau.com/it/2026-07-28-cryptographic-bill-of-materials-cbom-discovery-banks-2026/ by Sebastien Rousseau.
Licensed under CC-BY-4.0.

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER