Чем БДУ ФСТЭК отличается от CVE и как найти соответствие

Ситуация типовая: сканер безопасности выдал отчёт со списком идентификаторов вида CVE-2024-1234, а во внутреннем регламенте, отчётности и требованиях регулятора фигурируют идентификаторы вида BDU:2024-00492. Разберёмся, что это за реестры, как они соотносятся и как перевести одно в другое.

Два разных реестра, а не два названия одного

CVE (Common Vulnerabilities and Exposures) — международный реестр идентификаторов уязвимостей. Идентификатор резервирует и публикует запись уполномоченная организация — CNA (CVE Numbering Authority); ими становятся крупные производители программного обеспечения, исследовательские центры и национальные центры реагирования. Формат идентификатора — CVE-ГГГГ-NNNN, где после года четыре цифры и более. Год в идентификаторе означает год резервирования или публичного раскрытия, а не год, когда уязвимость появилась.

БДУБанк данных угроз безопасности информации ФСТЭК — Государственный реестр угроз (УБИ) и уязвимостей на bdu.fstec.ru; используется при построении модели угроз. — Банк данных угроз безопасности информации ФСТЭКФедеральная служба по техническому и экспортному контролю — Регулятор технической защиты информации (ИСПДн, ГИС, КИИ); ведёт реестр сертифицированных СЗИ. России (bdu.fstec.ru), публично объявленный информационным сообщением ФСТЭК России от 06.03.2015 № 240/22/879. В нём два разных раздела: перечень угроз безопасности информации (идентификаторы вида УБИУгроза безопасности информации — Совокупность условий и факторов, создающих опасность нарушения безопасности информации; каталогизируются в БДУ..NNN — из них строится модель угроз) и база уязвимостей программного обеспечения (идентификаторы вида BDU:ГГГГ-NNNNN). Путать их не стоит: угроза и уязвимость — разные сущности, и в документах они используются по-разному.

Главное отличие практическое: в БДУ попадает не всякая уязвимость из CVE. Реестры ведутся независимо, разными организациями и с разными задачами, поэтому БДУ существенно меньше по объёму.

Где искать соответствие

Соответствие устанавливает сама ФСТЭК России: в карточке уязвимости БДУ есть поле с идентификаторами других систем описания уязвимости, и там, как правило, указан связанный CVE. Отдельного нормативно утверждённого справочника соответствий не существует — источником служат сами карточки и выгрузки банка.

Соответствие не обязано быть один к одному. Одному идентификатору CVE может отвечать несколько записей БДУ: ФСТЭК России заводит их отдельно по продуктам и решениям. Обратная ситуация тоже встречается — в одной записи БДУ перечислено несколько CVE. Поэтому при переводе стоит смотреть на все найденные записи, а не останавливаться на первой.

Перевести один идентификатор или весь список из отчёта сканера можно в нашем инструменте соответствия CVE и БДУ: он распознаёт идентификаторы прямо в тексте отчёта — таблицей, JSON или списком через запятую. Обратная задача решается из справочника уязвимостей: в карточке записи БДУ связанные CVE перечислены явно.

Чего в БДУ нет — и что с этим делать

Отсутствие записи в БДУ не означает, что уязвимости не существует или что её можно не устранять. Это означает ровно одно: ФСТЭК России такую запись пока не публиковала. Она может появиться позже.

Практический вывод: такие строки отчёта не выбрасываются из плана работ, а учитываются по идентификатору CVE. Требования к процессу устранения от наличия записи в БДУ не зависят.

Отдельно стоит помнить про отозванные идентификаторы CVE (состояние REJECTED): идентификатор признан недействительным — например, оказался дубликатом или ошибкой, — и запись остаётся в реестре только для того, чтобы это было видно. Работы по такой строке отчёта не требуются.

Почему регуляторы говорят на языке БДУ

Анализ уязвимостей — не добровольная практика, а мера защиты, прямо предусмотренная требованиями:

• ИСПДнИнформационная система персональных данных — Совокупность персональных данных в базах данных и обеспечивающих их обработку информационных технологий и технических средств. — меры АНЗАнализ защищённости — Группа мер защиты: выявление уязвимостей и контроль конфигураций..1 (выявление, анализ уязвимостей и оперативное устранение вновь выявленных) и АНЗ.2 (контроль установки обновлений программного обеспечения) приказа ФСТЭК России от 18.02.2013 № 21.
• Государственные информационные системы — управление уязвимостями и управление обновлениями как отдельные мероприятия (пункты 38 и 39 приказа ФСТЭК России от 11.04.2025 № 117).
• Значимые объекты КИИКритическая информационная инфраструктура — Информационные системы и сети госорганов и организаций ключевых отраслей; режим защиты установлен 187-ФЗ. — анализ уязвимостей значимого объекта (пункт 12.6 приказа ФСТЭК России от 25.12.2017 № 239) и группа мер по управлению обновлениями программного обеспечения.

При этом требования обычно называют БДУ как источник сведений, но не запрещают пользоваться другими: на практике работают с БДУ и международными базами одновременно. Разница в том, что в отчётности и во внутренних документах ожидают увидеть идентификатор БДУ, если он у уязвимости есть.

Сроки устранения

В Руководстве по организации процесса управления уязвимостями, утверждённом ФСТЭК России 17.05.2023, приведены сроки устранения по уровню критичности: критический — до 24 часов, высокий — до 7 дней, средний — до 4 недель, низкий — до 4 месяцев. В самом руководстве они названы рекомендуемыми, но именно на них опираются при разработке внутреннего регламента, и именно с ними сверяют фактические сроки при проверке.

Разумный подход — закрепить эти сроки (или обоснованно иные) в собственном регламенте управления уязвимостями: тогда они становятся обязательными внутри организации и понятны проверяющему.

Критичность по ФСТЭК и оценка CVSS — не одно и то же

Сканер показывает базовую оценку CVSS: число от 0 до 10 и качественный уровень (Low, Medium, High, Critical). Методика ФСТЭК России по оценке уровня критичности уязвимостей использует эту оценку лишь как один из факторов, а дальше учитывает контекст конкретной системы: тип уязвимого компонента, доступность из сети Интернет, наличие эксплойта и применение уязвимости в атаках, возможные последствия.

Поэтому одна и та же уязвимость с одинаковым CVSS в двух системах может получить разный уровень критичности — и это правильно: критичность оценивается применительно к системе, а не абстрактно. Названия уровней (критический, высокий, средний, низкий) совпадают со шкалой CVSS, а смысл и пороги — нет. Переносить уровень из отчёта сканера в отчётность без оценки контекста не следует.

Чем пользоваться на практике

• ScanOVAL — бесплатный инструмент проверки установленного программного обеспечения по описаниям уязвимостей БДУ; распространяется через сайт банка. Отчёт сразу содержит идентификаторы БДУ, то есть переводить ничего не нужно.
• Зарубежные сканеры дают более широкое покрытие, но говорят идентификаторами CVE — их результаты придётся переводить.
• Реестр программного обеспечения организации — то, без чего не работает ни один из вариантов: пока неизвестно, что именно установлено, сравнивать не с чем.

Как выстроить сам процесс — инвентаризация, мониторинг, оценка, устранение и контроль — разобрано в статье об управлении уязвимостями по требованиям ФСТЭК.