Нельзя мигрировать то, что не перечислено: CBOM, которого у банков нет

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-провайдеры не перечисляются наведением на них сканера. Эта часть инвентаризации строится на договорном подтверждении, и соответствующий пункт договора должен появиться раньше дорожной карты.

Дедлайн, который никто не заложил в бюджет

Прочитайте опубликованные графики миграции внимательно, и последовательность окажется однозначной. Дорожная карта National Cyber Security Centre относит выявление — полную картину того, какие системы и сервисы зависят от криптографии, — к 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 о цифровой операционной устойчивости финансового сектора (DORA). Брюссель: Официальный журнал Европейского союза. Доступно по адресу: Европейский парламент и Совет Европейского союза, 2022..
National Cyber Security Centre, 2025. Сроки миграции на постквантовую криптографию. Лондон: NCSC. Доступно по адресу: National Cyber Security Centre, 2025..
National Institute of Standards and Technology, 2024. NIST IR 8547 (первый публичный черновик), Переход к стандартам постквантовой криптографии. Гейтерсберг: Министерство торговли США. Доступно по адресу: National Institute of Standards and Technology, 2024..
National Institute of Standards and Technology, 2024. FIPS 203, Стандарт механизма инкапсуляции ключа на модульных решётках. Гейтерсберг: Министерство торговли США. Доступно по адресу: National Institute of Standards and Technology, 2024..
OWASP Foundation, 2026. Спецификация ведомости материалов CycloneDX (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. При повторной публикации требуется указание канонической ссылки.

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

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

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

SEBASTIEN ROUSSEAU FOUNDER · ENGINEER