Nie zmigrujesz tego, czego nie policzysz: CBOM, którego banki nie mają

TL;DR. Termin rozpoznania NCSC na 2028 r. wypada przed każdym terminem migracji. Banki go nie dotrzymają, bo rejestr aktywów DORA nie zapisuje kryptografii.

Kluczowe wnioski

Termin, którego nikt nie wycenił. Proszę uważnie przeczytać opublikowane harmonogramy migracji, a kolejność okaże się jednoznaczna.
Państwa rejestr DORA zapisuje wszystko poza kryptografią. Tu leży część, która ludzi zaskakuje.
Co naprawdę zawiera CBOM. Cryptography Bill of Materials to formalna inwentaryzacja aktywów kryptograficznych w systemie — algorytmów, kluczy, certyfikatów i protokołów oraz ich relacji z komponentami oprogramowania, które z nich korzystają.
Rozpoznanie to cztery problemy, nie jeden. Traktowanie rozpoznania jako jednego strumienia prac to najczęstszy sposób, w jaki te programy się wykładają.

Każdy bankowy plan postkwantowy zakłada inwentaryzację, która nie istnieje. Plany są napisane, komitety sterujące się zbierają, karty wyników świecą na bursztynowo. Pod tym wszystkim leży założenie, że ktoś, gdzieś, potrafi wyprodukować listę każdego miejsca, w którym bank wykonuje operację kryptograficzną: jaki algorytm, jaka długość klucza, jaka biblioteka, jaki certyfikat i kiedy wygasa. Prawie żadna instytucja tego nie potrafi. Pierwszy kamień milowy NCSC nie jest kamieniem migracyjnym: to kamień rozpoznania, z terminem na 2028 rok, i to właśnie jego nikt nie wycenił.

Streszczenie dla zarządu

Kolejność brzmi: rozpoznanie, potem zwinność, potem migracja. Wytyczne NCSC wyznaczają rozpoznanie na 2028 rok, migrację najwyższego priorytetu na 2031, a zakończenie do 2035. Instytucja, która zacznie migrować, zanim policzy, zmigruje te systemy, o których akurat wie.

Rejestr, który Państwo mają, nie odpowiada na pytanie, przed którym teraz stoją. Artykuł 8 DORA wymaga od podmiotów finansowych identyfikacji, klasyfikacji i dokumentowania aktywów ICT oraz mapowania ich współzależności. Nie wymaga ani jednej właściwości kryptograficznej, więc rejestr zgodny z artykułem 8 może być kompletny i zarazem bezużyteczny w planowaniu zwinności kryptograficznej.

Standard już istnieje. Aktywa kryptograficzne — algorytmy z rozmiarem klucza, trybem i krzywą; klucze; certyfikaty; protokoły — dają się wyrazić w CycloneDX, publikowanym jako ECMA-424. To pytanie o schemat, nie o zakupy.

Najtrudniejszej ćwiartki nie przeskanują Państwo sami. Sprzętowych modułów bezpieczeństwa, urządzeń płatniczych, bibliotek wbudowanych przez dostawców i usług SaaS nie da się policzyć, kierując na nie skaner. Ta część inwentaryzacji powstaje z atestacji kontraktowej, a klauzula musi istnieć wcześniej niż plan działania.

Termin, którego nikt nie wycenił

Proszę uważnie przeczytać opublikowane harmonogramy migracji, a kolejność okaże się jednoznaczna. Plan National Cyber Security Centre umieszcza rozpoznanie — pełny obraz tego, które systemy i usługi zależą od kryptografii — w 2028 roku, prace migracyjne najwyższego priorytetu w 2031, a zakończenie we wszystkich systemach, usługach i produktach w 2035. Raport przejściowy NIST, IR 8547, biegnie zgodnym torem: podatne na ataki kwantowe algorytmy klucza publicznego, w tym RSA i ECC, są wycofywane po 2030 roku i zakazane po 2035.

Większość programów bankowych przyswoiła sobie rok 2035 jako datę docelową. To zły koniec harmonogramu, żeby od niego planować.

Znacznie ważniejsze są dwie inne daty. Pierwsza to 2028, bo rozpoznanie jest wejściem do wszystkiego, co następuje później — nie da się określić zakresu, kosztu ani kolejności migracji wobec nieznanego mianownika. Druga to 2030, bo w instytucji regulowanej „wycofany” nie jest łagodnym słowem: to moment, w którym dalsze poleganie na algorytmie staje się decyzją, którą ktoś musi podpisać.

Od dziś do 2028 roku zostało mniej niż trzydzieści miesięcy. To jeden, może dwa cykle budżetowe na zbudowanie zdolności, której większość instytucji nawet nie zaczęła.

Państwa rejestr DORA zapisuje wszystko poza kryptografią

Tu leży część, która ludzi zaskakuje. Większość dużych banków europejskich prowadzi już szczegółową, regularnie przeglądaną inwentaryzację aktywów ICT, bo DORA je do tego zobowiązuje.

Artykuł 8 Regulation (EU) 2022/2554 wymaga od podmiotów finansowych identyfikowania, klasyfikowania i odpowiedniego dokumentowania wszystkich funkcji biznesowych wspieranych przez ICT, informacji i aktywów ICT, które je wspierają, oraz ich ról i zależności w odniesieniu do ryzyka ICT — a także mapowania konfiguracji tych aktywów i powiązań między nimi, utrzymywanego pod przeglądem.

To poważna inwentaryzacja. Ma też zły kształt wobec tego problemu.

Tabela 1: Rejestr, który mają Państwo, i rejestr, którego wymaga kamień milowy 2028

Pytanie	Rejestr aktywów ICT (DORA artykuł 8)	Inwentaryzacja kryptograficzna (CBOM)
Czym jest to aktywo i kto jest jego właścicielem?	Tak — to rdzeń rejestru	Nie taki jest jej cel
Jak jest krytyczne i od czego zależy?	Tak — klasyfikacja i mapowanie współzależności	Dziedziczone z rejestru aktywów
Jakich algorytmów używa i w których miejscach?	Nie	Tak — per komponent, z rozmiarem klucza, trybem i krzywą
Która biblioteka je implementuje i w jakiej wersji?	Częściowo, przez SBOM, jeśli istnieje	Tak, jako jawna relacja
Jakie certyfikaty przedstawia i kiedy one wygasają?	Rzadko, zwykle w osobnym narzędziu PKI	Tak
Gdzie żyją klucze i jak są chronione?	Nie	Tak — łącznie z tym, czy w ścieżce stoi HSM
Czy to aktywo jest podatne na ataki kwantowe?	Nie da się wyprowadzić	Odpowiedź wprost

Ostatni wiersz to cały argument. Instytucja może być w pełni zgodna z artykułem 8, przejść kontrolę i nadal nie umieć odpowiedzieć na pytanie „ile naszych systemów pęknie w 2030 roku” bez zamówienia projektu rozpoznawczego od zera.

To nie jest krytyka DORA. Artykuł 8 napisano po to, by odpowiadał na pytania o odporność i koncentrację, i odpowiada na nie dobrze. Po prostu nie napisano go po to, by odpowiadał na pytanie o zwinność kryptograficzną, a oba rejestry trzeba połączyć, a nie prowadzić jako osobne arkusze należące do osobnych zespołów.

Co naprawdę zawiera CBOM

Cryptography Bill of Materials to formalna inwentaryzacja aktywów kryptograficznych w systemie — algorytmów, kluczy, certyfikatów i protokołów oraz ich relacji z komponentami oprogramowania, które z nich korzystają.

Istotny punkt konstrukcyjny brzmi: to nie jest nowy format pliku. Obsługę aktywów kryptograficznych wniesiono do CycloneDX, specyfikacji bill-of-materials firmowanej przez OWASP, publikowanej jako standard Ecma International, ECMA-424. CBOM jest zatem dokumentem CycloneDX z wypełnionymi polami kryptograficznymi. Waliduje się tym samym schematem, przechodzi przez te same potoki i ląduje w tym samym rejestrze artefaktów co dokumenty SBOM, które instytucja już wytwarza na potrzeby łańcucha dostaw.

To znaczy więcej, niż brzmi. O tym, czy standard wchodzi do użycia, czy grzęźnie, zwykle decyduje to, czy wymaga nowej instalacji rur. Ten nie wymaga.

Tabela 2: Klasy aktywów CBOM i pytanie migracyjne, na które każda odpowiada

Klasa aktywów	Co jest zapisywane	Pytanie, na które odpowiada
Algorytm	Prymityw, rozmiar klucza, tryb, krzywa, dopełnienie i pełniona funkcja	Które z naszych operacji są podatne na ataki kwantowe i przy jakiej sile parametrów?
Klucz	Typ, rozmiar, format, stan i miejsce, w którym leży materiał	Które klucze chroni HSM, a które siedzą w pamięci aplikacji?
Certyfikat	Podmiot, wystawca, algorytm podpisu, okno ważności	Co wygasa przed oknem migracji i co jest podpisane wycofanym algorytmem?
Protokół	Protokół i wersja wraz z oferowanymi zestawami szyfrów	Co jest faktycznie negocjowane na łączu, w odróżnieniu od tego, co deklaruje plik konfiguracyjny?
Powiązany komponent	Biblioteka, wersja i miejsce w kodzie, które to implementuje	Jeśli wymienimy tę bibliotekę, co jeszcze rusza się razem z nią?

Ostatni wiersz zamienia inwentaryzację w plan. Lista algorytmów mówi Państwu, jak duży jest problem. Lista algorytmów połączona z komponentami, które je implementują, mówi, jaki kształt ma praca — a to z tego buduje się kolejność migracji.

Rozpoznanie to cztery problemy, nie jeden

Traktowanie rozpoznania jako jednego strumienia prac to najczęstszy sposób, w jaki te programy się wykładają. To cztery odrębne problemy z czterema różnymi narzędziami, czterema różnymi właścicielami i bardzo różnymi poziomami pewności.

1. Kod źródłowy — o co prosi kod. Analiza statyczna własnych repozytoriów znajduje wywołania kryptograficzne, parametry zaszyte na sztywno i wywoływane biblioteki. Otwarte narzędzia istnieją: projekt CBOMkit i jego wtyczka do SonarQube wykrywają aktywa kryptograficzne w źródłach i emitują CycloneDX. Najwyższa pewność, najwęższe pokrycie — widzi tylko kod, który Państwo napisali i nadal budują.

2. Binaria i kontenery — co naprawdę trafia na produkcję. Analiza źródeł pomija wszystko, co wciągnięto jako skompilowaną zależność albo wpieczono w obraz bazowy. Skanowanie kontenerów i systemu plików domyka część tej luki. Proszę zakładać, że oba widoki będą się różnić; sama rozbieżność jest ustaleniem.

3. Sieć — co jest naprawdę negocjowane. Konfiguracja to zamiar, nie obserwacja. Pasywna obserwacja negocjacji TLS na żywo w całym majątku to jedyny sposób, by dowiedzieć się, że usługa dokumentująca TLS 1.3 nadal przyjmuje coś starszego od wewnętrznego kontrahenta, który nigdy się nie zaktualizował. W majątku płatniczym to zwykle właśnie ten kontrahent ma znaczenie.

4. Majątek dostawców i sprzętu — czego nie przeskanują Państwo wcale. Sprzętowe moduły bezpieczeństwa, terminale płatnicze, urządzenia sieciowe, podsystemy mainframe i każdy dostawca SaaS w łańcuchu. Żaden skaner tam nie sięga. Tę ćwiartkę liczy się, pytając na podstawie umowy, i to w niej koncentruje się prawdziwa ekspozycja bankowości korporacyjnej, bo systemy, które rozliczają i rozrachowują, są nieproporcjonalnie często dostarczane przez dostawców.

Od czwartego trzeba zacząć teraz, bo ma najdłuższy czas realizacji i nie jest zadaniem inżynierskim. Jest zadaniem zakupowym: wprowadzić do umowy i do wzorca przedłużenia klauzulę o ujawnianiu kryptografii i o zwinności kryptograficznej, tak by do 2028 roku odpowiedź przychodziła jako obowiązek dostawcy, a nie przysługa. Każdy kwartał bez tej klauzuli we wzorcu to kwartał przedłużeń, które trzeba będzie później otwierać na nowo.

Uczynić z tego mechanizm kontrolny, a nie projekt

Tryb awarii, na który bym postawił, nie polega na tym, że banki pominą inwentaryzację. Polega na tym, że zamówią ją jednorazowo, dostarczą obronny zrzut w 2028 roku i pozwolą mu się zdegradować — bo sfinansowano ją jako produkt projektu postkwantowego, a nie zbudowano jako utrzymywany mechanizm kontrolny.

Inwentaryzacja kryptograficzna degraduje się szybciej niż rejestr aktywów. Certyfikaty się rotują. Biblioteki podbija automatyzacja zależności. Zmienia się obraz bazowy i cała usługa po cichu dostaje inny stos TLS. Zrzut wykonany w 2028 roku będzie istotnie błędny w 2029, czyli dokładnie wtedy, gdy oprze się na nim praca priorytetyzacyjna na 2031.

Zapobiegają temu trzy zobowiązania.

Generować w potoku, nie w ankiecie. CBOM powinien być emitowany przez proces budowania, obok SBOM, i przechowywany jako wersjonowany artefakt przypisany do wydania. Inwentaryzacja zebrana przez rozesłanie kwestionariusza do właścicieli aplikacji jest nieaktualna w chwili dostarczenia i nie da się jej porównać różnicowo.

Porównywać różnicowo i alarmować na różnicy. Wartościowym sygnałem nie jest inwentaryzacja, lecz zmiana w inwentaryzacji. Usługa, która nabyła nową zależność kryptograficzną, certyfikat o skróconej ważności, algorytm, który pojawił się tam, gdzie go wcześniej nie było — to są zdarzenia warte mechanizmu kontrolnego. Ta sama logika sprawia, że porównywanie SBOM daje więcej niż ich archiwizowanie.

Połączyć to z rejestrem, który już Państwo prowadzą. CBOM odpowiada na pytanie „jaka kryptografia”; rejestr z artykułu 8 odpowiada „jak krytyczne, czyje i co od tego zależy”. Żadne z nich samo w sobie nie jest priorytetyzacją. Połączone dają jedyny ranking, który ma znaczenie: operacje podatne na ataki kwantowe posortowane według krytyczności funkcji biznesowej, która na nich stoi. To złączenie jest faktycznym produktem programu rozpoznawczego i warto je tak nazwać w planie.

Podręcznik operacyjny

Przeformułować kamień milowy 2028 jako zdolność, nie raport. Produktem jest utrzymywana, czytelna maszynowo inwentaryzacja, która sama się odtwarza, a nie dokument wytworzony raz dla nadzoru.
Emitować CBOM z procesu budowania już teraz, najpierw dla nowych usług. Proszę nie próbować objąć całego majątku jednym przebiegiem. Wpiąć to w potok dla wszystkiego, co jest budowane lub istotnie zmieniane w tym roku, żeby pokrycie narastało, zamiast wymagać kampanii.
Wpisać klauzulę umowną do wzorca przedłużenia w tym kwartale. Ujawnianie kryptografii i zobowiązanie do zwinności kryptograficznej. To ma najdłuższy czas realizacji ze wszystkiego na tej liście i nie zależy od żadnej decyzji narzędziowej.
Uruchomić obserwację sieci najpierw na ścieżkach płatniczych i rozrachunkowych. Tam luka między konfiguracją a rzeczywistością szkodzi najbardziej i tam koncentrują się starzy kontrahenci.
Połączyć CBOM z rejestrem z artykułu 8 i uszeregować po złączeniu. Opublikować uszeregowaną listę. To artefakt, który zamienia inwentaryzację inżynierską w rozmowę zarządu o kolejności i pieniądzach.
Porównywać różnicowo każde odtworzenie i alarmować na nowych zależnościach podatnych na ataki kwantowe. Inwentaryzacja bez porównania różnicowego to archiwum.

Instytucje, które dojdą do 2031 roku spokojnie, to nie te z najbardziej zaawansowanym oglądem ML-KEM. To te, które potrafią odpowiedzieć — dowolnego ranka i bez zamawiania projektu — na pytanie, gdzie ich kryptografia faktycznie jest.

Najczęściej zadawane pytania

Czy CBOM to co innego niż SBOM?
To ten sam typ dokumentu z wypełnionymi innymi polami. Obsługę aktywów kryptograficznych wniesiono do CycloneDX, publikowanego jako ECMA-424, więc CBOM waliduje się tym samym schematem i przechodzi przez te same narzędzia co SBOM. Instytucje, które już generują SBOM, są bliżej tego, niż zwykle zakładają.

Czy DORA wymaga inwentaryzacji kryptograficznej?
Nie w takich słowach. Artykuł 8 Regulation (EU) 2022/2554 wymaga identyfikacji, klasyfikacji i dokumentowania aktywów ICT oraz mapowania ich konfiguracji i współzależności. Właściwości kryptograficzne nie należą do atrybutów, których zapisania wymaga, i dlatego rejestr zgodny z artykułem 8 nie odpowie na pytanie o podatność na ataki kwantowe bez rozszerzenia.

Dlaczego rozpoznanie musi skończyć się tak długo przed migracją?
Bo jest wejściem do priorytetyzacji. Wytyczne NCSC stawiają rozpoznanie na 2028 rok, a migrację najwyższego priorytetu na 2031 właśnie po to, by istniał określony odstęp na uszeregowanie majątku i ułożenie kolejności prac. Ściśnięcie obu oznacza migrowanie tego, co jest najlepiej zrozumiane, zamiast tego, co ma największe znaczenie.

Jak zinwentaryzować kryptografię wewnątrz sprzętu dostawców i usług SaaS?
Nie skanuje się jej; wymaga się ujawnienia. Sprzętowe moduły bezpieczeństwa, urządzenia płatnicze i dostawcy usług muszą być objęci umownym obowiązkiem ujawniania kryptografii i zwinności kryptograficznej. Ponieważ zależy to od cykli przedłużeń umów, a nie od nakładu inżynierskiego, ma najdłuższy czas realizacji w całym programie i powinno ruszyć jako pierwsze.

Czy poczekać z rozpoczęciem, aż narzędzia dojrzeją?
Nie, a argument narzędziowy jest zwykle przykrywką dla argumentu budżetowego. Otwarte implementacje już emitują kryptograficzne inwentaryzacje CycloneDX ze źródeł i z obrazów kontenerów, a specyfikacja jest ratyfikowanym standardem. Ograniczeniem dla kamienia milowego 2028 są pokrycie i zasięg umowny, nie dostępność narzędzi.

Bibliografia

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

Ostatnia weryfikacja 2026-08-05.

Opublikuj ponownie ten artykuł

Nie zmigrujesz tego, czego nie policzysz: CBOM, którego banki nie mają — Sebastien Rousseau

Termin rozpoznania NCSC na 2028 r. wypada przed każdym terminem migracji. Banki go nie dotrzymają, bo rejestr aktywów DORA nie zapisuje kryptografii.

Ten artykuł jest objęty licencją Creative Commons Attribution 4.0 International. Ponowna publikacja wymaga przypisania do kanonicznego adresu URL.

Nie zmigrujesz tego, czego nie policzysz: CBOM, którego banki nie mają — Sebastien Rousseau

Termin rozpoznania NCSC na 2028 r. wypada przed każdym terminem migracji. Banki go nie dotrzymają, bo rejestr aktywów DORA nie zapisuje kryptografii.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER