TL;DR. A 2028-as NCSC feltárási határidő megelőz minden migrációs határidőt. A bankok nem tudják teljesíteni: a DORA eszköznyilvántartás nem rögzíti a kriptográfiát.

Legfontosabb tanulságok

A határidő, amit senki nem árazott be. Olvassa el figyelmesen a publikált migrációs ütemezéseket, és a sorrend egyértelmű.
A DORA-nyilvántartása mindent rögzít, csak a kriptográfiát nem. Itt jön az a rész, amely meglepi az embereket.
Mit tartalmaz valójában egy CBOM. A kriptográfiai anyagjegyzék (CBOM) egy rendszer kriptográfiai eszközeinek formális leltára — az algoritmusok, kulcsok, tanúsítványok és protokollok, valamint az őket használó szoftverkomponensekhez fűződő kapcsolataik.
A feltárás négy probléma, nem egy. A programok bukásának leggyakoribb módja, hogy a feltárást egyetlen munkafolyamként kezelik.

Nem migrálható, ami nincs leltárban: a kriptográfiai anyagjegyzék, amellyel a bankok máig nem rendelkeznek

A bankszektor minden posztkvantum ütemterve olyan leltárt feltételez, amely nem létezik. A tervek megvannak, az irányítóbizottságok üléseznek, a mutatók sárgán állnak. Az egész alatt ott lapul a feltevés, hogy valaki, valahol elő tud állítani egy listát arról, hol végez a bank kriptográfiai műveletet — melyik algoritmussal, milyen kulcshosszal, melyik könyvtárral, melyik tanúsítvánnyal, milyen lejárattal. Szinte egyetlen intézmény sem tudja. Az NCSC első mérföldköve nem migrációs mérföldkő: feltárási és leltározási mérföldkő, 2028-as határidővel — és éppen ezt nem árazta be senki.

Vezetői összefoglaló

A sorrend: feltárás, majd agilitás, majd migráció. Az NCSC iránymutatása 2028-ra tűz ki meghatározott feltárási mérföldkövet, 2031-re a legmagasabb prioritású migrációt, 2035-re a befejezést. Az az intézmény, amely a leltározás előtt kezd migrálni, azokat a rendszereket fogja migrálni, amelyekről történetesen tud.

A meglévő nyilvántartás nem válaszol a mostani kérdésre. A DORA Article 8 előírja, hogy a pénzügyi szervezetek azonosítsák, osztályozzák és dokumentálják IKT-eszközeiket, és térképezzék fel a köztük lévő függőségeket. Egyetlen kriptográfiai tulajdonságot sem követel meg, így egy Article 8-nak megfelelő nyilvántartás lehet hiánytalan, és a kriptográfiai agilitás tervezéséhez mégis használhatatlan.

A szabvány már megvan. A kriptográfiai eszközök — algoritmusok kulcsmérettel, móddal és görbével; kulcsok; tanúsítványok; protokollok — leírhatók a CycloneDX-ben, amely ECMA-424 néven jelent meg. Ez sémakérdés, nem beszerzési kérdés.

A legnehezebb negyedet nem Ön szkenneli. A hardveres biztonsági modulokat, fizetési eszközöket, beszállítói beágyazott könyvtárakat és SaaS-szolgáltatókat nem lehet leltározni azzal, hogy szkennert irányítunk rájuk. A leltárnak ez a része szerződéses tanúsításból épül fel, és a kikötésnek előbb kell léteznie, mint az ütemtervnek.

A határidő, amit senki nem árazott be

Olvassa el figyelmesen a publikált migrációs ütemezéseket, és a sorrend egyértelmű. A National Cyber Security Centre útiterve a feltárást — vagyis annak teljes képét, mely rendszerek és szolgáltatások támaszkodnak kriptográfiára — 2028-ra teszi, a legmagasabb prioritású migrációs munkát 2031-re, az összes rendszerre, szolgáltatásra és termékre kiterjedő befejezést pedig 2035-re. A NIST átállási jelentése, az IR 8547, ezzel összeegyeztethető pályán fut: a kvantumtámadásra sérülékeny nyilvános kulcsú algoritmusok, köztük az RSA és az ECC, 2030 után elavultak, 2035 után pedig tiltottak.

A banki programok többsége 2035-öt rögzítette magában dátumként. Az ütemterv rossz végéről tervezni.

Két dátum sokkal fontosabb. Az első 2028, mert a feltárás minden későbbi lépés bemenete — ismeretlen nevező mellett nem lehet migrációt terjedelmezni, árazni vagy ütemezni. A második 2030, mert szabályozott intézményben az „elavult” nem lágy szó: az a pont, ahol egy algoritmusra való további támaszkodás olyan döntéssé válik, amelyet valakinek alá kell írnia.

Innentől 2028-ig kevesebb mint harminc hónap van. Ez egy, legfeljebb két költségvetési ciklus egy olyan képesség felépítésére, amelybe az intézmények többsége bele sem kezdett.

A DORA-nyilvántartása mindent rögzít, csak a kriptográfiát nem

Itt jön az a rész, amely meglepi az embereket. A nagy európai bankok többsége már ma is részletes, rendszeresen felülvizsgált IKT-eszközleltárt vezet, mert a DORA erre kötelezi.

A Regulation (EU) 2022/2554 Article 8 előírja, hogy a pénzügyi szervezetek azonosítsák, osztályozzák és megfelelően dokumentálják valamennyi IKT-támogatott üzleti funkciójukat, az ezeket kiszolgáló információs és IKT-eszközöket, valamint azok szerepét és függőségeit az IKT-kockázathoz képest — és hogy térképezzék fel ezen eszközök konfigurációját és a köztük lévő kapcsolatokat, folyamatos felülvizsgálat mellett.

Ez komoly leltár. És rossz alakú ehhez a problémához.

1. táblázat: A meglévő nyilvántartás és az, amit a 2028-as mérföldkő megkíván

Kérdés	IKT-eszköznyilvántartás (DORA Article 8)	Kriptográfiai leltár (CBOM)
Mi ez az eszköz, és ki a gazdája?	Igen — ez a nyilvántartás magja	Nem ez a célja
Mennyire kritikus, és mitől függ?	Igen — osztályozás és függőségi feltérképezés	Az eszköznyilvántartásból öröklődik
Milyen algoritmusokat használ, és hol?	Nem	Igen — komponensenként, kulcsmérettel, móddal és görbével
Melyik könyvtár valósítja meg őket, melyik verzióban?	Részben, az SBOM révén, ha van ilyen	Igen, explicit kapcsolatként
Milyen tanúsítványokat mutat be, és mikor járnak le?	Ritkán, és rendszerint külön PKI-eszközben	Igen
Hol vannak a kulcsok, és hogyan védettek?	Nem	Igen — beleértve azt is, hogy HSM van-e az útvonalon
Kvantumtámadásra sérülékeny ez az eszköz?	Nem vezethető le	Közvetlenül megválaszolható

Az utolsó sor az egész érvelés. Egy intézmény lehet teljes mértékben Article 8-konform, átmehet a vizsgálaton, és mégsem tudja megválaszolni, hogy „hány rendszerünk törik el 2030-ban”, anélkül hogy nulláról indítana egy feltárási projektet.

Ez nem a DORA kritikája. Az Article 8 az ellenállóképességi és koncentrációs kérdések megválaszolására készült, és ezekre jól válaszol. Egyszerűen nem kriptográfiai agilitási kérdésre írták — a két nyilvántartást pedig össze kell kapcsolni, nem külön csapatok által birtokolt, külön táblázatokként futtatni.

Mit tartalmaz valójában egy CBOM

A kriptográfiai anyagjegyzék (CBOM) egy rendszer kriptográfiai eszközeinek formális leltára — az algoritmusok, kulcsok, tanúsítványok és protokollok, valamint az őket használó szoftverkomponensekhez fűződő kapcsolataik.

A lényeges szerkezeti pont az, hogy nem új fájlformátum. A kriptográfiai eszközök támogatását a CycloneDX-be vezették be, az OWASP által támogatott anyagjegyzék-specifikációba, amely ECMA-424 néven Ecma International szabványként jelent meg. A CBOM tehát olyan CycloneDX-dokumentum, amelyben ki vannak töltve a kriptográfiai mezők. Ugyanazzal a sémával validálódik, ugyanazokon a futószalagokon halad át, és ugyanabba az artefaktum-nyilvántartásba kerül, mint az SBOM-ok, amelyeket az intézmény ellátásilánc-célból már ma is előállít.

Ez többet számít, mint amennyire hangzik. A megvalósuló és az elakadó szabvány között rendszerint az a különbség, hogy kell-e hozzá új infrastruktúrát építeni. Ehhez nem kell.

2. táblázat: CBOM-eszközosztályok és a migrációs kérdés, amelyre mindegyik választ ad

Eszközosztály	Amit rögzít	A kérdés, amelyre válaszol
Algoritmus	Primitív, kulcsméret, mód, görbe, kitöltés és az ellátott funkció	Mely műveleteink kvantumtámadásra sérülékenyek, és milyen paramétererősség mellett?
Kulcs	Típus, méret, formátum, állapot és a kulcsanyag helye	Mely kulcsokat véd HSM, és melyek ülnek alkalmazásmemóriában?
Tanúsítvány	Alany, kibocsátó, aláírási algoritmus, érvényességi ablak	Mi jár le a migrációs ablak előtt, és mit írtak alá elavult algoritmussal?
Protokoll	Protokoll és verzió, a felkínált titkosítási csomagokkal	Mi az, amit ténylegesen egyeztetnek a vonalon, szemben azzal, amit a konfigurációs fájl állít?
Kapcsolódó komponens	A fentieket megvalósító könyvtár, verzió és kódhely	Ha ezt a könyvtárat lecserélik, mi mozdul még vele?

Az utolsó sor az, ami a leltárból tervet csinál. Az algoritmusok listája megmondja a probléma méretét. Az algoritmusok listája az őket megvalósító komponensekhez kapcsolva megmondja a munka alakját — és egy migrációs sorrend valójában ebből épül fel.

A feltárás négy probléma, nem egy

A programok bukásának leggyakoribb módja, hogy a feltárást egyetlen munkafolyamként kezelik. Négy különálló probléma, négy különböző eszközzel, négy különböző gazdával és nagyon eltérő megbízhatósági szinttel.

1. Forráskód — amit a kód kér. A saját repozitóriumok statikus elemzése megtalálja a kriptográfiai hívásokat, a beégetett paramétereket és a meghívott könyvtárakat. Nyílt eszközkészlet létezik: a CBOMkit projekt és annak SonarQube-bővítménye kriptográfiai eszközöket észlel a forrásban, és CycloneDX-et állít elő. A legnagyobb megbízhatóság, a legszűkebb lefedettség — csak azt a kódot látja, amelyet Ön írt, és amelyet még ma is fordít.

2. Bináris állományok és konténerek — ami ténylegesen kiszállításra kerül. A forráselemzés kihagy mindent, ami fordított függőségként érkezik vagy egy alapképbe van sütve. A konténer- és fájlrendszer-szkennelés részben zárja ezt a rést. Számítson rá, hogy a két nézet eltér; maga az eltérés is megállapítás.

3. A hálózat — amit ténylegesen egyeztetnek. A konfiguráció szándék, nem megfigyelés. Az élő TLS-egyeztetés passzív megfigyelése az állomány egészén az egyetlen módja annak, hogy kiderüljön: egy szolgáltatás, amely papíron TLS 1.3-at használ, még mindig elfogad valami régebbit egy olyan belső partnerrel, amely soha nem frissített. Egy fizetési állományban gyakran éppen az a partner számít.

4. A beszállítói és hardveres állomány — amit egyáltalán nem lehet szkennelni. Hardveres biztonsági modulok, fizetési terminálok, hálózati eszközök, nagygépes alrendszerek és a lánc minden SaaS-szolgáltatója. Ezekhez egyetlen szkenner sem ér el. Ezt a negyedet kérdezéssel, szerződéses alapon lehet leltározni — és a nagybanki működés valódi kitettsége itt sűrűsödik, mert a klíringet és a kiegyenlítést végző rendszerek aránytalanul nagy részben beszállítói szállításúak.

A negyedikkel érdemes most kezdeni, mert ennek a legnagyobb az átfutási ideje, és nem mérnöki feladat. Beszerzési feladat: kriptográfiai közzétételi és kriptográfiai agilitási kikötést kell beemelni a szerződésbe és a megújítási sablonba, hogy 2028-ra a válasz szállítói kötelezettségként érkezzen, ne szívességként. Minden negyedév, amelyben az a kikötés nincs benne a sablonban, egy negyedévnyi olyan megújítás, amelyet később újra fel kell nyitni.

Kontroll legyen belőle, ne projekt

Az a hibamód, amelyre fogadnék, nem az, hogy a bankok kihagyják a leltárt. Hanem hogy egyszeri munkaként rendelik meg, 2028-ban leszállítanak egy védhető pillanatképet, aztán hagyják elavulni — mert posztkvantum projekttermékként finanszírozták, nem fenntartott kontrollként építették.

A kriptográfiai leltár gyorsabban avul, mint egy eszköznyilvántartás. A tanúsítványok rotálódnak. A könyvtárakat a függőségi automatizálás emeli. Megváltozik egy alapkép, és egy egész szolgáltatás észrevétlenül más TLS-vermet kap. Egy 2028-ban készült pillanatkép 2029-re érdemben hibás lesz — pontosan akkor, amikor a 2031-es prioritizálási munka támaszkodna rá.

Három elköteleződés akadályozza ezt meg.

A futószalagon készüljön, ne kérdőívből. A CBOM-ot a build állítsa elő, az SBOM mellett, és verziózott artefaktumként tárolják a kiadáshoz kötve. Az a leltár, amely az alkalmazásgazdáknak kiküldött kérdőívekből áll össze, már érkezéskor elavult, és nem is diffelhető.

Diffelje, és riasszon a diffre. Az értékes jelzés nem a leltár, hanem a leltár változása. Egy szolgáltatás, amely új kriptográfiai függőséget kapott; egy tanúsítvány, amelynek rövidült a futamideje; egy algoritmus, amely ott jelent meg, ahol korábban nem volt — ezek az események érnek egy kontrollt. Ugyanaz az érvelés, ami miatt az SBOM diffelése hasznosabb, mint az SBOM archiválása.

Kapcsolja össze a már meglévő nyilvántartással. A CBOM arra válaszol, hogy „milyen kriptográfia”; az Article 8 szerinti nyilvántartás arra, hogy „mennyire kritikus, kié, és mi függ tőle”. Önmagában egyik sem prioritizálás. Összekapcsolva viszont az egyetlen olyan rangsort adják, amely számít: a kvantumtámadásra sérülékeny műveleteket a rájuk épülő üzleti funkció kritikussága szerint rendezve. Ez az összekapcsolás egy feltárási program tényleges terméke, és érdemes a tervben is így nevesíteni.

Az operatív forgatókönyv

Fogalmazza újra a 2028-as mérföldkövet képességként, ne jelentésként. A leszállítandó egy fenntartott, gépi olvasásra alkalmas leltár, amely magát újragenerálja — nem egy dokumentum, amely egyszer készül a felügyelet számára.
Már most állítson elő CBOM-ot a buildből, először az új szolgáltatásokon. Ne próbálja meg az állományt egy menetben. Kösse be a futószalagba mindarra, ami idén épül vagy érdemben változik, hogy a lefedettség halmozódjon, ne kampányt igényeljen.
A szerződéses kikötést még ebben a negyedévben tegye be a megújítási sablonba. Kriptográfiai közzététel és kriptográfiai agilitási vállalás. Ennek a legnagyobb az átfutási ideje a listán, és nem függ semmilyen eszközdöntéstől.
A hálózati megfigyelést először a fizetési és kiegyenlítési útvonalakon futtassa. Itt okozza a legnagyobb kárt a konfiguráció és a valóság közti rés, és itt sűrűsödnek az örökölt partnerek.
Kapcsolja a CBOM-ot az Article 8 szerinti nyilvántartáshoz, és az összekapcsolt adaton rangsoroljon. Tegye közzé a rangsorolt listát. Ez az az artefaktum, amely a mérnöki leltárból igazgatósági beszélgetést csinál ütemezésről és pénzről.
Minden újragenerálást diffeljen, és riasszon az új, kvantumtámadásra sérülékeny függőségekre. A diff nélküli leltár archívum.

Azok az intézmények, amelyek kényelmesen érnek 2031-be, nem azok, amelyek a legfejlettebben látják az ML-KEM-et. Hanem azok, amelyek bármely reggelen, projekt megrendelése nélkül meg tudják válaszolni, hol van valójában a kriptográfiájuk.

Gyakran ismételt kérdések

A CBOM más dolog, mint az SBOM?
Ugyanaz a dokumentumtípus, más mezőkkel kitöltve. A kriptográfiai eszközök támogatása bekerült a CycloneDX-be, amely ECMA-424 néven jelent meg, így a CBOM ugyanazzal a sémával validálódik és ugyanazon az eszközláncon halad át, mint az SBOM. Azok az intézmények, amelyek már ma is generálnak SBOM-ot, közelebb vannak ehhez, mint általában feltételezik.

Előír a DORA kriptográfiai leltárt?
Ilyen formában nem. A Regulation (EU) 2022/2554 Article 8 az IKT-eszközök azonosítását, osztályozását és dokumentálását, valamint konfigurációjuk és kölcsönös függőségeik feltérképezését írja elő. A kriptográfiai tulajdonságok nincsenek a rögzítendő attribútumok között — ezért nem tud egy Article 8-konform nyilvántartás kvantumsérülékenységi kérdésre válaszolni anélkül, hogy kibővítenék.

Miért kell a feltárásnak ennyivel a migráció előtt befejeződnie?
Mert a prioritizálás bemenete. Az NCSC iránymutatása pontosan azért teszi a feltárást 2028-ra és a legmagasabb prioritású migrációt 2031-re, hogy legyen egy meghatározott intervallum az állomány rangsorolására és a munka ütemezésére. A kettő összenyomása azt jelenti, hogy nem a legfontosabbat, hanem a legjobban ismertet migrálják.

Hogyan leltározzuk a beszállítói hardverben és SaaS-ben lévő kriptográfiát?
Nem szkenneljük, hanem közzétételt követelünk. A hardveres biztonsági modulokra, fizetési eszközökre és szolgáltatókra szerződéses kriptográfiai közzétételi és kriptográfiai agilitási kötelezettségnek kell vonatkoznia. Mivel ez megújítási ciklusoktól függ, nem mérnöki ráfordítástól, ennek a legnagyobb az átfutási ideje az egész programban, és ezzel kell kezdeni.

Megvárjuk, amíg az eszközkészlet beérik?
Nem, és az eszközérv rendszerint a költségvetési érv álruhája. Nyílt implementációk már ma is előállítanak CycloneDX kriptográfiai leltárakat forrásból és konténerképekből, a specifikáció pedig ratifikált szabvány. A 2028-as mérföldkő korlátja a lefedettség és a szerződéses hatókör, nem az eszközök elérhetősége.

Hivatkozások

European Parliament and Council of the European Union, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Brüsszel: Official Journal of the European Union. Elérhető: European Parliament and Council of the European Union, 2022..
National Cyber Security Centre, 2025. Timelines for migration to post-quantum cryptography. London: NCSC. Elérhető: 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. Elérhető: 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. Elérhető: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Wakefield: OWASP Foundation. Elérhető: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Wakefield: OWASP Foundation. Elérhető: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Armonk: IBM. Elérhető: IBM Research, 2026..

Utolsó felülvizsgálat 2026-08-05.

A cikk újraközlése

Nem migrálható, ami nincs leltárban: a bankok hiányzó CBOM-ja — Sebastien Rousseau

A 2028-as NCSC feltárási határidő megelőz minden migrációs határidőt. A bankok nem tudják teljesíteni: a DORA eszköznyilvántartás nem rögzíti a kriptográfiát.

Ez a cikk a következő licenc alatt áll: Creative Commons Attribution 4.0 International. Az újraközléshez a kanonikus URL forrásmegjelölése szükséges.

Nem migrálható, ami nincs leltárban: a bankok hiányzó CBOM-ja — Sebastien Rousseau

A 2028-as NCSC feltárási határidő megelőz minden migrációs határidőt. A bankok nem tudják teljesíteni: a DORA eszköznyilvántartás nem rögzíti a kriptográfiát.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER