TL;DR. Termenul NCSC de identificare și inventariere din 2028 cade înaintea oricărei migrări. Băncile nu îl pot respecta: registrul DORA nu consemnează criptografia.

Concluzii cheie

Termenul pe care nu l-a bugetat nimeni. Citiți cu atenție calendarele de migrare publicate și ordinea este fără echivoc.
Registrul vostru DORA consemnează totul, mai puțin criptografia. Aici se află partea care surprinde.
Ce conține de fapt un CBOM. Un Cryptography Bill of Materials este un inventar formal al activelor criptografice dintr-un sistem — algoritmii, cheile, certificatele și protocoalele, împreună cu relațiile lor cu componentele software care le…
Identificarea și inventarierea sunt patru probleme, nu una. Tratarea identificării și inventarierii ca un singur flux de lucru este modul cel mai frecvent în care aceste programe eșuează.

Nu poți migra ceea ce nu poți enumera: inventarul criptografic (CBOM) pe care băncile tot nu îl au

Orice foaie de parcurs post-cuantică din sectorul bancar presupune un inventar care nu există. Planurile sunt scrise, comitetele de coordonare se întrunesc, tablourile de bord stau pe galben. Sub toate acestea stă presupunerea că cineva, undeva, poate scoate lista tuturor locurilor în care banca execută o operațiune criptografică — ce algoritm, ce lungime a cheii, ce bibliotecă, ce certificat și când expiră. Aproape nicio instituție nu poate. Primul jalon al NCSC nu este un jalon de migrare: este un jalon de identificare și inventariere, cu termen 2028, și este singurul pe care nu l-a bugetat nimeni.

Rezumat executiv

Ordinea este: identificare, apoi agilitate, apoi migrare. Ghidul NCSC fixează un jalon clar de identificare și inventariere în 2028, migrarea cu prioritate maximă în 2031 și finalizarea până în 2035. O instituție care începe să migreze înainte de a fi enumerat va migra sistemele pe care se întâmplă să le cunoască.

Registrul pe care îl aveți nu răspunde la întrebarea cu care vă confruntați acum. Articolul 8 din DORA cere entităților financiare să identifice, să clasifice și să documenteze activele TIC și să cartografieze interdependențele dintre ele. Nu cere nicio proprietate criptografică, așa că un registru conform cu Articolul 8 poate fi complet și, în același timp, inutil pentru planificarea agilității criptografice.

Standardul există deja. Activele criptografice — algoritmi cu dimensiunea cheii, mod și curbă; chei; certificate; protocoale — sunt reprezentabile în CycloneDX, publicat ca ECMA-424. Este o chestiune de schemă, nu una de achiziții.

Sfertul cel mai greu nu este al vostru, ca să îl scanați. Modulele hardware de securitate, echipamentele de plăți, bibliotecile integrate de furnizori și providerii SaaS nu pot fi enumerate îndreptând un scaner spre ele. Acea parte a inventarului se construiește din atestări contractuale, iar clauza trebuie să existe înainte să poată exista foaia de parcurs.

Termenul pe care nu l-a bugetat nimeni

Citiți cu atenție calendarele de migrare publicate și ordinea este fără echivoc. Foaia de parcurs a National Cyber Security Centre așază identificarea și inventarierea — imaginea completă a sistemelor și serviciilor care depind de criptografie — în 2028, lucrările de migrare cu prioritate maximă în 2031, iar finalizarea pe toate sistemele, serviciile și produsele în 2035. Raportul de tranziție al NIST, IR 8547, merge pe un traseu compatibil: algoritmii cu cheie publică vulnerabili la atacuri cuantice, între care RSA și ECC, sunt depreciați după 2030 și interziși după 2035.

Majoritatea programelor bancare au interiorizat 2035 ca fiind data. Este capătul greșit al calendarului din care să planifici.

Alte două date contează mult mai mult. Prima este 2028, pentru că identificarea și inventarierea sunt intrarea pentru tot ce urmează — nu poți dimensiona, costa sau secvenția o migrare raportându-te la un numitor necunoscut. A doua este 2030, pentru că „depreciat” nu este un cuvânt blând într-o instituție reglementată: este momentul în care continuarea dependenței de un algoritm devine o decizie pe care cineva trebuie să o semneze.

De acum până în 2028 sunt mai puțin de treizeci de luni. Adică un ciclu bugetar, poate două, pentru a construi o capabilitate pe care majoritatea instituțiilor nici măcar nu au început-o.

Registrul vostru DORA consemnează totul, mai puțin criptografia

Aici se află partea care surprinde. Majoritatea băncilor europene mari țin deja un inventar detaliat și revizuit periodic al activelor TIC, pentru că DORA le obligă.

Articolul 8 din Regulation (EU) 2022/2554 cere entităților financiare să identifice, să clasifice și să documenteze adecvat toate funcțiile de business susținute de TIC, informațiile și activele TIC care le susțin, precum și rolurile și dependențele acestora în raport cu riscul TIC — și să cartografieze configurația acelor active și legăturile dintre ele, ținute sub revizuire.

Este un inventar serios. Și are forma greșită pentru problema de față.

Tabelul 1: registrul pe care îl aveți și registrul de care are nevoie jalonul din 2028

Întrebare	Registrul activelor TIC (DORA, Articolul 8)	Inventar criptografic (CBOM)
Ce este acest activ și cine îl deține?	Da — acesta este miezul registrului	Nu este scopul lui
Cât de critic este și de ce depinde?	Da — clasificare și cartografierea interdependențelor	Preluat din registrul activelor
Ce algoritmi folosește și unde?	Nu	Da — pe componentă, cu dimensiunea cheii, modul și curba
Ce bibliotecă îi implementează și în ce versiune?	Parțial, prin SBOM, dacă există unul	Da, ca relație explicită
Ce certificate prezintă și când expiră?	Rar, și de regulă într-un instrument PKI separat	Da
Unde stau cheile și cum sunt protejate?	Nu	Da — inclusiv dacă un HSM se află pe traseu
Este acest activ vulnerabil la atacuri cuantice?	Nu poate fi dedus	Se poate răspunde direct

Ultimul rând este întregul argument. O instituție poate fi pe deplin conformă cu Articolul 8, poate trece de inspecție și tot nu poate răspunde la întrebarea „câte dintre sistemele noastre se rup în 2030” fără să comande un proiect de identificare și inventariere de la zero.

Nu este o critică la adresa DORA. Articolul 8 a fost scris ca să răspundă unor întrebări de reziliență și de concentrare și le răspunde bine. Pur și simplu nu a fost scris ca să răspundă unei întrebări de agilitate criptografică, iar cele două registre trebuie unite, nu ținute ca fișiere separate, deținute de echipe separate.

Ce conține de fapt un CBOM

Un Cryptography Bill of Materials este un inventar formal al activelor criptografice dintr-un sistem — algoritmii, cheile, certificatele și protocoalele, împreună cu relațiile lor cu componentele software care le folosesc.

Punctul structural important este că nu vorbim despre un format de fișier nou. Suportul pentru active criptografice a fost contribuit în CycloneDX, specificația de bill of materials susținută de OWASP, publicată ca standard Ecma International, ECMA-424. Un CBOM este, prin urmare, un document CycloneDX cu câmpurile de criptografie populate. Se validează cu aceeași schemă, circulă prin aceleași pipeline-uri și ajunge în același registru de artefacte ca SBOM-urile pe care o instituție le produce deja pentru lanțul de aprovizionare.

Asta contează mai mult decât pare. Diferența dintre un standard care se livrează și unul care se împotmolește ține de regulă de faptul că cere sau nu instalații noi. Acesta nu cere.

Tabelul 2: clasele de active CBOM și întrebarea de migrare la care răspunde fiecare

Clasă de active	Ce se consemnează	Întrebarea la care răspunde
Algoritm	Primitiva, dimensiunea cheii, modul, curba, padding-ul și funcția pe care o îndeplinește	Care dintre operațiunile noastre sunt vulnerabile la atacuri cuantice și la ce tărie a parametrilor?
Cheie	Tipul, dimensiunea, formatul, starea și locul unde se află materialul	Ce chei sunt protejate de un HSM și care stau în memoria aplicației?
Certificat	Subiectul, emitentul, algoritmul de semnătură, fereastra de valabilitate	Ce expiră înainte de fereastra de migrare și ce este semnat cu un algoritm depreciat?
Protocol	Protocolul și versiunea, cu suitele de cifruri oferite	Ce se negociază efectiv pe fir, spre deosebire de ce pretinde fișierul de configurare?
Componentă asociată	Biblioteca, versiunea și locul din cod care le implementează	Dacă această bibliotecă este înlocuită, ce altceva se mută odată cu ea?

Ultimul rând este cel care transformă un inventar într-un plan. O listă de algoritmi vă spune dimensiunea problemei. O listă de algoritmi legată de componentele care îi implementează vă spune forma muncii — și exact de acolo se construiește o secvență de migrare.

Identificarea și inventarierea sunt patru probleme, nu una

Tratarea identificării și inventarierii ca un singur flux de lucru este modul cel mai frecvent în care aceste programe eșuează. Sunt patru probleme distincte, cu patru instrumente diferite, patru proprietari diferiți și niveluri de încredere foarte diferite.

1. Codul sursă — ce cere codul. Analiza statică peste propriile repozitorii găsește apelurile criptografice, parametrii hard-codați și bibliotecile invocate. Instrumentarul deschis există: proiectul CBOMkit și pluginul său pentru SonarQube detectează active criptografice în sursă și emit CycloneDX. Cea mai mare încredere, cea mai îngustă acoperire — vede doar codul pe care l-ați scris și pe care încă îl construiți.

2. Binare și containere — ce se livrează efectiv. Analiza sursei ratează tot ce intră ca dependență compilată sau ce este copt într-o imagine de bază. Scanarea containerelor și a sistemului de fișiere închide o parte din această lacună. Așteptați-vă ca cele două perspective să se contrazică; contradicția este ea însăși o constatare.

3. Rețeaua — ce se negociază cu adevărat. Configurația este o intenție, nu o observație. Observarea pasivă a negocierii TLS reale din tot parcul este singura cale prin care aflați că un serviciu care documentează TLS 1.3 acceptă în continuare ceva mai vechi cu o contraparte internă care nu a făcut niciodată upgrade. Într-un parc de plăți, acea contraparte este adesea exact cea care contează.

4. Parcul de furnizori și de echipamente — ce nu puteți scana deloc. Module hardware de securitate, terminale de plată, echipamente de rețea, subsisteme de mainframe și fiecare provider SaaS din lanț. Niciun scaner nu ajunge acolo. Acest sfert se enumeră întrebând, sub contract, și acolo se concentrează expunerea reală a băncilor de investiții și corporate, pentru că sistemele care compensează și decontează sunt disproporționat furnizate din exterior.

A patra este cea cu care se începe acum, pentru că are cel mai lung timp de execuție și nu este o sarcină de inginerie. Este o sarcină de achiziții: introducerea unei clauze de divulgare criptografică și de agilitate criptografică în contract și în șablonul de reînnoire, astfel încât până în 2028 răspunsul să vină ca obligație a furnizorului, nu ca favoare. Fiecare trimestru în care clauza nu este în șablon este un trimestru de reînnoiri care vor trebui redeschise mai târziu.

Un control permanent, nu un proiect

Modul de eșec pe care aș paria nu este că băncile sar peste inventar. Este că îl comandă o singură dată, livrează un instantaneu defendabil în 2028 și îl lasă să se degradeze — pentru că a fost finanțat ca livrabil al unui proiect post-cuantic, nu construit ca un control menținut permanent.

Un inventar criptografic se degradează mai repede decât registrul activelor. Certificatele se rotesc. Bibliotecile sunt urcate de versiune de automatizarea dependențelor. O imagine de bază se schimbă și un serviciu întreg capătă în tăcere un alt stack TLS. Un instantaneu luat în 2028 va fi semnificativ greșit până în 2029, exact atunci când munca de prioritizare pentru 2031 depinde de el.

Trei angajamente previn asta.

Generați-l în pipeline, nu într-un chestionar. Un CBOM trebuie emis de build, alături de SBOM, și stocat ca artefact versionat, legat de release. Un inventar strâns prin trimiterea unui chestionar către proprietarii de aplicații este depășit din momentul sosirii și nu se poate compara între versiuni.

Comparați versiunile și alertați pe diferență. Semnalul valoros nu este inventarul; este schimbarea din inventar. Un serviciu care a căpătat o dependență criptografică nouă, un certificat a cărui valabilitate s-a scurtat, un algoritm apărut acolo unde nu era înainte — acestea sunt evenimentele care merită un control. Este același raționament care face compararea SBOM-urilor mai utilă decât arhivarea lor.

Legați-l de registrul pe care îl țineți deja. CBOM-ul răspunde la „ce criptografie”; registrul de la Articolul 8 răspunde la „cât de critic, al cui și ce depinde de el”. Niciunul nu este, singur, o prioritizare. Unite, produc singura ierarhie care contează: operațiunile vulnerabile la atacuri cuantice, sortate după criticitatea funcției de business care stă deasupra lor. Acea îmbinare este livrabilul real al unui program de identificare și inventariere și merită numită ca atare în plan.

Manualul operațional

Reformulați jalonul din 2028 ca pe o capabilitate, nu ca pe un raport. Livrabilul este un inventar menținut, citibil automat, care se regenerează singur, nu un document produs o dată pentru un supraveghetor.
Emiteți CBOM-uri din build de acum, întâi pe serviciile noi. Nu încercați tot parcul dintr-o singură trecere. Cablați-l în pipeline pentru orice se construiește sau se modifică semnificativ anul acesta, ca acoperirea să se acumuleze în loc să ceară o campanie.
Puneți clauza contractuală în șablonul de reînnoire în acest trimestru. Divulgare criptografică și angajament de agilitate criptografică. Are cel mai lung timp de execuție dintre toate elementele listei și nu depinde de nicio decizie privind instrumentarul.
Rulați observarea rețelei mai întâi pe traseele de plată și de decontare. Acolo face cel mai mult rău decalajul dintre configurație și realitate și acolo se concentrează contrapărțile legacy.
Legați CBOM-ul de registrul de la Articolul 8 și ierarhizați pe îmbinare. Publicați lista ierarhizată. Este artefactul care transformă un inventar de inginerie într-o discuție de consiliu despre secvențiere și bani.
Comparați fiecare regenerare și alertați pe dependențele noi vulnerabile la atacuri cuantice. Un inventar fără comparație între versiuni este o arhivă.

Instituțiile care vor ajunge confortabil la 2031 nu sunt cele cu cea mai avansată perspectivă asupra ML-KEM. Sunt cele care pot răspunde, în orice dimineață și fără să comande un proiect, la întrebarea unde se află de fapt criptografia lor.

Întrebări frecvente

Un CBOM este altceva decât un SBOM?
Este același tip de document, cu alte câmpuri populate. Suportul pentru active criptografice a fost integrat în CycloneDX, publicat ca ECMA-424, așa că un CBOM se validează cu aceeași schemă și circulă prin același instrumentar ca un SBOM. Instituțiile care generează deja SBOM-uri sunt mai aproape de asta decât presupun de obicei.

DORA cere un inventar criptografic?
Nu în acești termeni. Articolul 8 din Regulation (EU) 2022/2554 cere identificarea, clasificarea și documentarea activelor TIC, precum și cartografierea configurației și a interdependențelor lor. Proprietățile criptografice nu se numără printre atributele pe care vă obligă să le consemnați, motiv pentru care un registru conform cu Articolul 8 nu poate răspunde unei întrebări de vulnerabilitate cuantică fără a fi extins.

De ce trebuie ca identificarea și inventarierea să se încheie cu atât timp înaintea migrării?
Pentru că este intrarea prioritizării. Ghidul NCSC așază identificarea și inventarierea în 2028, iar migrarea cu prioritate maximă în 2031 tocmai pentru a exista un interval definit în care parcul să fie ierarhizat și munca secvențiată. Comprimarea celor două înseamnă să migrați ce este cel mai bine înțeles, nu ce contează cel mai mult.

Cum inventariem criptografia din hardware-ul furnizorilor și din SaaS?
Nu o scanați; cereți divulgarea ei. Modulele hardware de securitate, echipamentele de plăți și furnizorii de servicii trebuie acoperiți de o obligație contractuală de divulgare criptografică și de agilitate criptografică. Pentru că depinde de ciclurile de reînnoire, nu de efortul de inginerie, are cel mai lung timp de execuție din întregul program și trebuie începută prima.

Ar trebui să așteptăm maturizarea instrumentarului înainte de a începe?
Nu, iar argumentul instrumentarului este de regulă o mască pentru argumentul bugetar. Implementări deschise emit deja inventare criptografice CycloneDX din sursă și din imagini de container, iar specificația este un standard ratificat. Constrângerea pentru jalonul din 2028 este acoperirea și forța contractuală, nu disponibilitatea instrumentelor.

Referințe

European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Bruxelles: Jurnalul Oficial al Uniunii Europene. Disponibil la: European Parliament and Council of the European Union, 2022..
National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. Londra: NCSC. Disponibil la: 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: Departamentul de Comerț al SUA. Disponibil la: National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Gaithersburg: Departamentul de Comerț al SUA. Disponibil la: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Disponibil la: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Disponibil la: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Disponibil la: IBM Research, 2026..

Ultima revizuire 2026-08-05.

Republică acest articol

Nu poți migra ce nu poți enumera: CBOM-ul pe care băncile nu îl au — Sebastien Rousseau

Termenul NCSC de identificare și inventariere din 2028 cade înaintea oricărei migrări. Băncile nu îl pot respecta: registrul DORA nu consemnează criptografia.

Acest articol este licențiat sub Creative Commons Attribution 4.0 International. Republicarea necesită atribuirea la URL-ul canonic.

Nu poți migra ce nu poți enumera: CBOM-ul pe care băncile nu îl au — Sebastien Rousseau

Termenul NCSC de identificare și inventariere din 2028 cade înaintea oricărei migrări. Băncile nu îl pot respecta: registrul DORA nu consemnează criptografia.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER