TL;DR. Дедлайн виявлення NCSC у 2028 році настає раніше за будь-яку міграцію. Банки його не виконають: реєстр активів DORA не фіксує криптографію всередині систем.

Ключові висновки

Дедлайн, який ніхто не заклав у бюджет. Прочитайте опубліковані міграційні терміни уважно — і послідовність виявиться однозначною.
Ваш реєстр за DORA фіксує все, окрім криптографії. Ось частина, яка людей дивує.
Що насправді містить CBOM. Cryptography Bill of Materials — це формальна інвентаризація криптографічних активів у системі: алгоритмів, ключів, сертифікатів і протоколів, а також їхніх зв'язків із програмними компонентами, що їх використовують.
Виявлення та інвентаризація — це чотири проблеми, а не одна. Ставитися до виявлення як до єдиного напряму робіт — найпоширеніший спосіб завалити такі програми.

Не можна мігрувати те, чого не перелічено: криптографічний реєстр матеріалів, якого досі немає у банків

Кожна постквантова дорожня карта в банківській справі припускає інвентаризацію, якої не існує. Плани написані, керівні комітети засідають, оціночні картки світяться жовтим. Під усім цим лежить припущення, що хтось десь здатен видати перелік кожного місця, де банк виконує криптографічну операцію: який алгоритм, яка довжина ключа, яка бібліотека, який сертифікат і коли він спливає. Майже жодна установа цього не може. Перша віха NCSC — це не віха міграції: це віха виявлення та інвентаризації, з терміном 2028 рік, і саме її ніхто не заклав у бюджет.

Стисло для керівництва

Послідовність така: виявлення, потім гнучкість, потім міграція. Настанови NCSC визначають віху виявлення та інвентаризації на 2028 рік, міграцію найвищого пріоритету — на 2031-й, а завершення — до 2035-го. Установа, яка почне мігрувати до того, як усе перелічить, мігруватиме ті системи, про які випадково знає.

Реєстр, який ви маєте, не відповідає на питання, що постало зараз. DORA Article 8 вимагає від фінансових установ ідентифікувати, класифікувати та документувати ІКТ-активи й мапувати їхні взаємозалежності. Він не вимагає жодної криптографічної властивості, тож реєстр, повністю відповідний Article 8, може бути завершеним і водночас непридатним для планування криптографічної гнучкості.

Стандарт уже існує. Криптографічні активи — алгоритми з розміром ключа, режимом і кривою; ключі; сертифікати; протоколи — представляються в CycloneDX, опублікованому як ECMA-424. Це питання схеми, а не закупівлі.

Найважчу чверть ви не проскануєте. Апаратні модулі безпеки, платіжні пристрої, вбудовані вендорські бібліотеки та SaaS-провайдери не перелічуються наведенням сканера. Ця частина інвентаризації будується з контрактних підтверджень, і відповідний пункт має існувати раніше, ніж дорожня карта.

Дедлайн, який ніхто не заклав у бюджет

Прочитайте опубліковані міграційні терміни уважно — і послідовність виявиться однозначною. Дорожня карта Національного центру кібербезпеки ставить виявлення та інвентаризацію — повну картину того, які системи й сервіси залежать від криптографії, — на 2028 рік, міграційні роботи найвищого пріоритету — на 2031-й, а завершення в усіх системах, сервісах і продуктах — на 2035-й. Перехідний звіт NIST, IR 8547, іде сумісною колією: вразливі до квантових атак алгоритми з відкритим ключем, включно з RSA та ECC, визнаються застарілими після 2030 року і забороняються після 2035-го.

Більшість банківських програм засвоїла 2035 рік як ту саму дату. Це неправильний кінець графіка, від якого варто планувати.

Дві дати важать значно більше. Перша — 2028 рік, бо виявлення та інвентаризація є входом для всього подальшого: ви не оціните обсяг, вартість і послідовність міграції проти невідомого знаменника. Друга — 2030 рік, бо «застарілий» у регульованій установі не м'яке слово: це момент, коли подальша опора на алгоритм стає рішенням, яке комусь доведеться підписати.

Від сьогодні до 2028 року лишається менш ніж тридцять місяців. Це один, можливо, два бюджетні цикли на побудову спроможності, до якої більшість установ ще не бралася.

Ваш реєстр за DORA фіксує все, окрім криптографії

Ось частина, яка людей дивує. Більшість великих європейських банків уже веде детальну інвентаризацію ІКТ-активів із регулярним переглядом, бо DORA їх до цього зобов'язує.

Article 8 Regulation (EU) 2022/2554 вимагає від фінансових установ ідентифікувати, класифікувати та належно документувати всі бізнес-функції з ІКТ-підтримкою, інформацію та ІКТ-активи, що їх забезпечують, а також їхні ролі й залежності стосовно ІКТ-ризику — і мапувати конфігурацію цих активів та зв'язки між ними, тримаючи мапу під переглядом.

Це серйозна інвентаризація. Вона також має неправильну форму для цієї задачі.

Таблиця 1: реєстр, який у вас є, і реєстр, потрібний для віхи 2028 року

Питання	Реєстр ІКТ-активів (DORA Article 8)	Криптографічна інвентаризація (CBOM)
Що це за актив і хто ним володіє?	Так — це ядро реєстру	Не його призначення
Наскільки він критичний і від чого залежить?	Так — класифікація та мапування взаємозалежностей	Успадковується з реєстру активів
Які алгоритми він використовує і де?	Ні	Так — покомпонентно, з розміром ключа, режимом і кривою
Яка бібліотека їх реалізує і якої версії?	Частково, через SBOM, якщо він існує	Так, як явний зв'язок
Які сертифікати він пред'являє і коли вони спливають?	Рідко, і зазвичай в окремому PKI-інструменті	Так
Де живуть ключі та як вони захищені?	Ні	Так — включно з тим, чи є HSM на шляху
Чи вразливий цей актив до квантових атак?	Вивести неможливо	Пряма відповідь

Останній рядок і є всім аргументом. Установа може повністю відповідати Article 8, пройти перевірку — і все одно не відповісти на питання «скільки наших систем зламається у 2030 році», не замовивши проєкт виявлення з нуля.

Це не докір DORA. Article 8 писали, щоб відповідати на питання стійкості та концентрації, і він відповідає на них добре. Його просто не писали, щоб відповідати на питання криптографічної гнучкості, і два реєстри треба з'єднати, а не вести як окремі таблиці в руках окремих команд.

Що насправді містить CBOM

Cryptography Bill of Materials — це формальна інвентаризація криптографічних активів у системі: алгоритмів, ключів, сертифікатів і протоколів, а також їхніх зв'язків із програмними компонентами, що їх використовують.

Важливий структурний момент: це не новий формат файлу. Підтримку криптографічних активів внесли в CycloneDX, специфікацію реєстру матеріалів під егідою OWASP, опубліковану як стандарт Ecma International — ECMA-424. Отже, CBOM — це документ CycloneDX із заповненими криптографічними полями. Він валідується тією самою схемою, рухається тими самими конвеєрами і потрапляє в той самий реєстр артефактів, що й SBOM, які установа вже виробляє для потреб ланцюга постачання.

Це важить більше, ніж звучить. Різниця між стандартом, який доїжджає, і стандартом, який глухне, зазвичай зводиться до того, чи потребує він нової сантехніки. Цей — не потребує.

Таблиця 2: класи активів CBOM і міграційне питання, на яке відповідає кожен

Клас активу	Що фіксується	Питання, на яке він відповідає
Алгоритм	Примітив, розмір ключа, режим, крива, доповнення та функція, яку він виконує	Які з наших операцій вразливі до квантових атак і за якої стійкості параметрів?
Ключ	Тип, розмір, формат, стан і місце, де зберігається матеріал	Які ключі захищені HSM, а які лежать у пам'яті застосунку?
Сертифікат	Суб'єкт, видавець, алгоритм підпису, вікно чинності	Що спливає до міграційного вікна і що підписано застарілим алгоритмом?
Протокол	Протокол і версія разом із запропонованими наборами шифрів	Що насправді узгоджується в мережі, на відміну від того, що стверджує конфігураційний файл?
Пов'язаний компонент	Бібліотека, версія та розташування коду, що реалізують наведене вище	Якщо цю бібліотеку замінити, що переїде разом із нею?

Останній рядок перетворює інвентаризацію на план. Перелік алгоритмів показує розмір проблеми. Перелік алгоритмів, з'єднаний із компонентами, які їх реалізують, показує форму роботи — а саме з неї і будується міграційна послідовність.

Виявлення та інвентаризація — це чотири проблеми, а не одна

Ставитися до виявлення як до єдиного напряму робіт — найпоширеніший спосіб завалити такі програми. Це чотири окремі проблеми з чотирма різними інструментами, чотирма різними власниками і дуже різними рівнями впевненості.

1. Вихідний код — те, чого просить код. Статичний аналіз ваших власних репозиторіїв знаходить криптографічні виклики, зашиті параметри та задіяні бібліотеки. Відкритий інструментарій існує: проєкт CBOMkit і його плагін для SonarQube виявляють криптографічні активи у вихідному коді та видають CycloneDX. Найвища впевненість, найвужче покриття — він бачить лише код, який ви написали і досі складаєте.

2. Бінарні файли та контейнери — те, що справді відвантажується. Аналіз вихідного коду пропускає все, що втягнуто як скомпільована залежність або запечено в базовий образ. Сканування контейнерів і файлових систем частково закриває цю прогалину. Очікуйте, що два погляди розійдуться; саме розходження і є знахідкою.

3. Мережа — те, що узгоджується насправді. Конфігурація — це намір, а не спостереження. Пасивне спостереження за живим узгодженням TLS у парку систем — єдиний спосіб дізнатися, що сервіс, який документує TLS 1.3, досі приймає щось старіше від внутрішнього контрагента, який ніколи не оновлювався. У платіжному парку саме той контрагент часто і має значення.

4. Вендорський і апаратний парк — те, що ви не проскануєте взагалі. Апаратні модулі безпеки, платіжні термінали, мережеві пристрої, підсистеми мейнфреймів і кожен SaaS-провайдер у ланцюгу. Жоден сканер до них не дістає. Ця чверть перелічується запитами за контрактом, і саме там концентрується справжня експозиція оптового банкінгу, бо системи, що клірять і розраховують, непропорційно часто постачаються вендорами.

За четверту треба братися вже зараз, бо вона має найдовший цикл підготовки і не є інженерним завданням. Це завдання закупівель: внести пункт про криптографічне розкриття та криптографічну гнучкість у контракт і в шаблон продовження, щоб до 2028 року відповідь приходила як зобов'язання постачальника, а не як послуга. Кожен квартал, коли цього пункту немає в шаблоні, — це квартал продовжень, які потім доведеться перевідкривати.

Зробити це контролем, а не проєктом

Режим відмови, на який я поставив би, — не в тому, що банки пропустять інвентаризацію. Він у тому, що вони замовлять її разово, здадуть захисний зріз у 2028 році і дадуть йому зогнити — бо її профінансували як результат постквантового проєкту, а не побудували як підтримуваний контроль.

Криптографічна інвентаризація гниє швидше за реєстр активів. Сертифікати ротуються. Бібліотеки підіймає автоматизація залежностей. Змінюється базовий образ — і цілий сервіс тихо набуває іншого стека TLS. Зріз, зроблений у 2028 році, буде суттєво хибним уже до 2029-го, тобто саме тоді, коли від нього залежатиме пріоритизація 2031 року.

Цьому запобігають три зобов'язання.

Генеруйте її в конвеєрі, а не в опитуванні. CBOM має видаватися складанням, поруч із SBOM, і зберігатися як версійований артефакт, прив'язаний до релізу. Інвентаризація, зібрана розсиланням анкет власникам застосунків, застаріває в момент прибуття і не піддається порівнянню версій.

Порівнюйте версії та сигналізуйте про різницю. Цінний сигнал — не інвентаризація, а зміна в ній. Сервіс, який набув нової криптографічної залежності; сертифікат, чий строк скоротився; алгоритм, що з'явився там, де його раніше не було, — ось події, гідні контролю. Це та сама логіка, через яку порівняння версій SBOM корисніше за їхнє архівування.

З'єднайте її з реєстром, який ви вже ведете. CBOM відповідає на питання «яка криптографія»; реєстр за Article 8 відповідає на питання «наскільки критично, чиє і що від цього залежить». Жодне з них саме по собі не є пріоритизацією. З'єднані, вони дають єдиний рейтинг, що має значення: вразливі до квантових атак операції, впорядковані за критичністю бізнес-функції, яка на них спирається. Це з'єднання і є справжнім результатом програми виявлення, і його варто назвати саме так у плані.

Операційний план дій

Переформулюйте віху 2028 року як спроможність, а не як звіт. Результат — підтримувана машиночитна інвентаризація, що перегенеровується сама, а не документ, зроблений один раз для наглядача.
Видавайте CBOM зі складання вже зараз, спершу для нових сервісів. Не намагайтеся охопити весь парк одним проходом. Вбудуйте це в конвеєр для всього, що будується або суттєво змінюється цьогоріч, щоб покриття наростало, а не вимагало кампанії.
Внесіть контрактний пункт у шаблон продовження вже цього кварталу. Криптографічне розкриття та зобов'язання щодо криптографічної гнучкості. Це має найдовший цикл підготовки з усього переліку і не залежить від жодного рішення щодо інструментарію.
Запустіть мережеве спостереження спершу на платіжних і розрахункових маршрутах. Саме там розрив між конфігурацією та реальністю завдає найбільшої шкоди і саме там концентруються застарілі контрагенти.
З'єднайте CBOM із реєстром за Article 8 і ранжуйте за з'єднанням. Опублікуйте ранжований перелік. Це той артефакт, що перетворює інженерну інвентаризацію на розмову правління про послідовність і гроші.
Порівнюйте кожну перегенерацію та сигналізуйте про нові вразливі до квантових атак залежності. Інвентаризація без порівняння версій — це архів.

Установи, які пройдуть 2031 рік спокійно, — не ті, що мають найпросунутіший погляд на ML-KEM. Це ті, що будь-якого ранку і без замовлення проєкту здатні відповісти, де насправді перебуває їхня криптографія.

Поширені запитання

Чи CBOM — це щось інше, ніж SBOM?
Це той самий тип документа з іншими заповненими полями. Підтримку криптографічних активів внесли в апстрим CycloneDX, опублікований як ECMA-424, тож CBOM валідується тією самою схемою і рухається тим самим інструментарієм, що й SBOM. Установи, які вже генерують SBOM, ближчі до цього, ніж зазвичай припускають.

Чи вимагає DORA криптографічної інвентаризації?
Не в таких словах. Article 8 Regulation (EU) 2022/2554 вимагає ідентифікації, класифікації та документування ІКТ-активів, а також мапування їхньої конфігурації та взаємозалежностей. Криптографічні властивості не входять до атрибутів, які він зобов'язує фіксувати, — тому реєстр, відповідний Article 8, не відповість на питання про вразливість до квантових атак без розширення.

Чому виявлення має завершитися настільки раніше за міграцію?
Бо воно є входом для пріоритизації. Настанови NCSC ставлять виявлення та інвентаризацію на 2028 рік, а міграцію найвищого пріоритету — на 2031-й саме для того, щоб існував визначений інтервал, у якому парк систем ранжують і роботу вибудують у послідовність. Стиснути ці два етапи означає мігрувати те, що найкраще зрозуміле, а не те, що найбільше важить.

Як інвентаризувати криптографію всередині вендорського обладнання та SaaS?
Ви її не скануєте — ви вимагаєте розкриття. Апаратні модулі безпеки, платіжні пристрої та постачальники послуг мають бути покриті контрактним зобов'язанням щодо криптографічного розкриття та криптографічної гнучкості. Оскільки це залежить від циклів продовження, а не від інженерних зусиль, воно має найдовший цикл підготовки в усій програмі і починатися має першим.

Чи варто чекати на дозрівання інструментарію, перш ніж починати?
Ні, і аргумент про інструментарій зазвичай є замінником аргументу про бюджет. Відкриті реалізації вже видають криптографічні інвентаризації у форматі CycloneDX із вихідного коду та з образів контейнерів, а специфікація є ратифікованим стандартом. Обмеженням для віхи 2028 року є покриття та контрактне охоплення, а не доступність інструментів.

Джерела

Європейський Парламент і Рада Європейського Союзу, 2022. Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA). Брюссель: Офіційний вісник Європейського Союзу. Доступно за посиланням: Європейський Парламент і Рада Європейського Союзу, 2022..
Національний центр кібербезпеки, 2025. Timelines for migration to post-quantum cryptography. Лондон: NCSC. Доступно за посиланням: Національний центр кібербезпеки, 2025..
Національний інститут стандартів і технологій, 2024. NIST IR 8547 (Initial Public Draft), Transition to Post-Quantum Cryptography Standards. Гейтерсберг: Міністерство торгівлі США. Доступно за посиланням: Національний інститут стандартів і технологій, 2024..
Національний інститут стандартів і технологій, 2024. FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard. Гейтерсберг: Міністерство торгівлі США. Доступно за посиланням: Національний інститут стандартів і технологій, 2024..
OWASP Foundation, 2026. CycloneDX Bill of Materials Specification (ECMA-424). Вейкфілд: OWASP Foundation. Доступно за посиланням: OWASP Foundation, 2026..
OWASP CycloneDX, 2026. Cryptography Bill of Materials (CBOM). Вейкфілд: OWASP Foundation. Доступно за посиланням: OWASP CycloneDX, 2026..
IBM Research, 2026. CBOM: Cryptography Bill of Materials. Армонк: IBM. Доступно за посиланням: IBM Research, 2026..

Останній перегляд 2026-08-05.

Перевидати цю статтю

Не можна мігрувати те, чого не перелічено: CBOM, якого немає у банків — Sebastien Rousseau

Дедлайн виявлення NCSC у 2028 році настає раніше за будь-яку міграцію. Банки його не виконають: реєстр активів DORA не фіксує криптографію всередині систем.

Ця стаття поширюється за ліцензією Creative Commons Attribution 4.0 International. Перевидання вимагає посилання на канонічну URL-адресу.

Не можна мігрувати те, чого не перелічено: CBOM, якого немає у банків — Sebastien Rousseau

Дедлайн виявлення NCSC у 2028 році настає раніше за будь-яку міграцію. Банки його не виконають: реєстр активів DORA не фіксує криптографію всередині систем.

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER