Ключевые выводы
- БДУ ФСТЭК нельзя рассматривать как замену CVE. В NVD указано 348 194 CVE-записи, но БДУ нужен российским командам для локального контекста: русскоязычного описания, связи с отечественными продуктами, регуляторной терминологии и привязки к требованиям защиты информации.
- Главная практическая задача — сопоставление 2 идентификаторов. Security-инженеру важно держать связку CVE ↔ BDU: CVE помогает быстро получить международные технические детали, а BDU-номер нужен для внутреннего учета, отчетности и коммуникации с владельцами российских информационных систем.
- Оценка CVSS без контекста дает неполную картину риска. Уязвимость с CVSS 9,8, как в примере CVE-2026-3843, требует ускоренной реакции, но фактический приоритет зависит от экспонирования сервиса, наличия затронутой версии, компенсирующих мер и критичности актива.
- Рабочий процесс должен состоять минимум из 4 этапов. Мониторинг, разбор, исправление и проверка нужны как единый цикл; пропуск проверки после установки обновления оставляет риск «закрытой на бумаге» уязвимости.
- Интеграция БДУ в SIEM и SOAR полезна только при нормализации данных. Для Solar, Positive Technologies и других стеков важны единые поля: CVE, BDU, CVSS, продукт, версия, владелец актива, статус исправления и ссылка на задачу.
- Для DevSecOps связка БДУ, SCA и SBOM становится обязательной практикой. Без перечня компонентов команда видит бюллетень уязвимости, но не может быстро ответить, есть ли затронутая библиотека в продуктивной среде.
Контекст исследования
БДУ ФСТЭК уязвимости — это рабочий контур для команд, которые отвечают за безопасность российских информационных систем, инфраструктуры с отечественными операционными системами, прикладного программного обеспечения и средств защиты информации. Банк данных угроз безопасности информации ФСТЭК России используется как источник сведений об угрозах и уязвимостях, а также как язык, на котором удобно связывать технический риск с регуляторными требованиями, моделью угроз и планом защитных мер.
В практической работе БДУ редко живет отдельно. Security-инженер видит CVE в сканере уязвимостей, в отчете SCA, в бюллетене производителя или в правиле SIEM, а затем проверяет, есть ли соответствующая запись БДУ. Обратная ситуация тоже частая: в БДУ появляется запись с русскоязычным описанием, перечнем затронутого программного обеспечения и внешними идентификаторами, после чего команда ищет технические детали в NVD, MITRE CVE, GitHub Advisory Database, бюллетенях вендоров и базах отечественных поставщиков.
Эта статья рассматривает БДУ как операционный инструмент учета уязвимостей, а не как юридическую инструкцию. Для формального соответствия требованиям ФСТЭК нужно сверять внутренние процедуры с действующими нормативными документами, моделью угроз и применимым классом защищаемой системы.
Методология и источники
Материал подготовлен как исследовательский обзор для команд информационной безопасности, DevSecOps и владельцев ИТ-инфраструктуры. Мы сопоставили открытые карточки уязвимостей, документацию NVD API, публичные записи Positive Technologies, зеркала карточек БДУ и открытые материалы ФСТЭК. Отдельное внимание уделено не описанию одной базы, а рабочему процессу: как связать CVE, BDU-номер, актив, задачу на исправление и контроль результата.
Числовые утверждения в тексте привязаны к источникам или к публичным заявлениям вендоров. Где официальный сайт БДУ недоступен для автоматизированной проверки, использованы публичные карточки и вторичные каталоги, которые сохраняют ссылку на исходную запись ФСТЭК. Такие данные следует воспринимать как ориентир для черновика и перепроверять перед публикацией или внедрением в регламент.
Охват исследования
- География: российские организации, которые используют БДУ ФСТЭК для учета уязвимостей, отчетности, оценки защищенности и интеграции с процессами управления рисками.
- Сегмент: корпоративная ИТ-инфраструктура, DevSecOps, прикладная разработка, средства защиты информации, SIEM, SOAR, vulnerability management и учет компонентов через SBOM.
- Период: 2024-2026 годы как основной горизонт операционной практики; отдельные карточки БДУ более ранних лет используются для иллюстрации формата.
- Исключения: статья не оценивает закрытые каналы обмена данными, не описывает обход ограничений сайтов и не заменяет внутренний регламент реагирования на уязвимости.
Основные результаты
Что такое БДУ ФСТЭК и зачем он нужен
Банк данных угроз безопасности информации ФСТЭК России — это государственный ресурс со сведениями об угрозах и уязвимостях, который используется при построении моделей угроз, оценке защищенности и планировании защитных мер. В части уязвимостей БДУ дает идентификатор вида BDU:год-номер, русскоязычное описание, сведения о затронутом программном обеспечении, версии, уровне опасности, CVSS-векторе, статусе исправления и внешних идентификаторах, включая CVE, если такая связь известна.
Для инженерной команды ценность БДУ не в том, что он повторяет международные базы, а в том, что он переводит глобальную информацию об уязвимости в контекст российского учета. Это важно для инфраструктуры на отечественных ОС, для сертифицированных средств защиты, для объектов критической информационной инфраструктуры и для организаций, где отчетность должна опираться на терминологию ФСТЭК.
Как искать CVE по БДУ через интерфейс
Базовый сценарий начинается с карточки БДУ. Инженер открывает раздел уязвимостей на сайте БДУ, вводит идентификатор BDU или фрагмент названия продукта, затем проверяет блок внешних идентификаторов. Если уязвимость сопоставлена с международной записью, в карточке обычно указывается CVE. После этого CVE проверяется в NVD или MITRE CVE, чтобы получить англоязычное описание, ссылки на бюллетени производителя, CVSS-вектор и дополнительные технические детали.
Обратный сценарий начинается с CVE. Если сканер показывает CVE-2026-3843, инженер ищет этот идентификатор в БДУ или в корпоративном адаптере к БДУ. В публичной карточке Positive Technologies для CVE-2026-3843 среди ссылок указан BDU:2025-13914, что показывает типовую связку: международный идентификатор используется для технического обнаружения, а BDU-номер — для локального учета и отчетности.
Как строить API-слой для БДУ без хрупкой автоматизации
Внутренний API-слой лучше проектировать как адаптер, а не как прямую зависимость от одной веб-страницы. В типовой реализации сервис vulnerability-intake принимает CVE, BDU, название продукта и версию, затем нормализует запись в единый формат: идентификаторы, описание, CVSS, затронутые версии, источник, дата обновления и ссылка на оригинальную карточку. Если доступна официальная выгрузка или разрешенный машинный формат, он используется первым. Если команда работает с ручной проверкой, результат фиксируется в CMDB или системе задач.
{
"cve": "CVE-2026-3843",
"bdu": "BDU:2025-13914",
"cvss_v3": 9.8,
"product": "BUK TS-G Gas Station Automation System",
"affected_version": "2.9.1",
"source": "bdu.fstec.ru",
"status": "triage"
}Сопоставление CVE и BDU-номера
Сопоставление CVE ↔ BDU-номер должно быть отдельной сущностью в учете уязвимостей. Ошибка многих команд в том, что они хранят только CVE, а затем не могут быстро подготовить отчет в российской терминологии. Обратная ошибка — хранить только BDU и терять ссылки на международные бюллетени, где часто раньше появляются технические детали, исправленные версии и признаки эксплуатации.
Практичный минимум — таблица соответствий. В ней должны быть CVE, BDU, продукт, версия, источник, дата последней проверки, ответственный владелец и статус. Для высоких и критических уязвимостей стоит добавлять поле «экспонирование»: интернет-доступность, наличие внешнего периметра, принадлежность к критичному бизнес-процессу и наличие компенсирующих мер.
| Поле | Зачем нужно | Пример |
|---|---|---|
| CVE | Международный технический идентификатор | CVE-2026-3843 |
| BDU | Российский идентификатор учета | BDU:2025-13914 |
| CVSS | Базовая оценка опасности | 9,8 |
| Актив | Понимание фактического воздействия | Промышленная система, сервер приложения, узел CI |
| Статус | Управление жизненным циклом | Новая, в разборе, исправлена, проверена |
Рабочий процесс security-инженера: мониторинг, разбор, исправление, проверка
Рабочий процесс начинается с мониторинга. Источниками могут быть БДУ, NVD, бюллетени производителей, SCA-инструменты, отчеты сканеров, правила SIEM и результаты анализа SBOM. Цель мониторинга — не собрать максимум сигналов, а быстро понять, какие записи относятся к реальным активам организации.
На этапе разбора инженер сопоставляет уязвимость с инвентаризацией. Если в компании нет затронутой версии, запись закрывается как неприменимая с указанием причины. Если актив есть, назначается владелец, оценивается экспонирование и выбирается срок исправления. Для критичных уязвимостей с удаленной эксплуатацией без аутентификации решение обычно принимается не по недельному циклу, а по ускоренному процессу.
Исправление включает обновление версии, установку патча, изменение конфигурации, отключение функции или временное ограничение доступа. Проверка завершает цикл: повторный скан, контроль версии, анализ логов, проверка правила SIEM и закрытие задачи только после подтверждения факта исправления.
Интеграция БДУ в SIEM и SOAR
В SIEM БДУ полезен как слой обогащения событий. Например, если Solar или MaxPatrol SIEM получает событие эксплуатации уязвимости, правило может добавить к нему BDU-номер, CVE, уровень CVSS и критичность актива. Это сокращает время первичного разбора: аналитик видит не только сигнатуру атаки, но и связь с уязвимостью, перечнем затронутых продуктов и планом реакции.
В SOAR связка БДУ и CVE помогает автоматизировать рутинные действия: создать задачу владельцу сервиса, запросить данные из CMDB, проверить наличие компонента в SBOM, запустить сканирование, отправить уведомление в канал дежурной команды и перевести инцидент в статус ожидания исправления. При этом автоматизация не должна сама закрывать риск без технической проверки.
БДУ в SIEM и SOAR работает лучше всего не как отдельная справочная ссылка, а как нормализованное поле, по которому можно строить правила корреляции, отчеты, задачи и метрики закрытия уязвимостей.
Сравнение с MITRE CVE и NVD
MITRE CVE отвечает за идентификацию публично раскрытых уязвимостей: одна уязвимость получает один CVE-идентификатор. NVD обогащает CVE дополнительными данными, включая CVSS, CWE, CPE, ссылки и машинно-читаемый API. БДУ добавляет российский контекст: русскоязычное описание, локальную классификацию, связь с отечественными продуктами и применимость в процессах, где важна терминология ФСТЭК.
Поэтому вопрос «что лучше» некорректен. Для международного технического анализа нужна CVE/NVD-связка. Для российской отчетности и внутренней коммуникации с подразделениями ИБ нужен БДУ. Для зрелого процесса vulnerability management нужны оба слоя.
Демонстрационный пример реакции: CVE-2026-3843 → BDU:2025-13914
В публичной карточке Positive Technologies CVE-2026-3843 описана как SQL Injection в системе автоматизации АЗС BUK TS-G версии 2.9.1 с CVSS 3.1 на уровне 9,8. Среди внешних ссылок указана запись БДУ BDU:2025-13914. Для security-инженера это не просто справочная связь, а стартовый набор действий.
Первый шаг — проверить, есть ли BUK TS-G версии 2.9.1 в инвентаризации. Второй — определить, доступен ли уязвимый компонент из внешних сетей или из технологического сегмента. Третий — назначить владельца, проверить обновление производителя и временно ограничить доступ к затронутому endpoint, если обновление невозможно установить сразу. Четвертый — после исправления выполнить повторную проверку и сохранить доказательства: версию, результат сканирования и ссылку на закрытую задачу.
Сравнительный анализ
| Критерий | БДУ ФСТЭК | MITRE CVE | NVD |
|---|---|---|---|
| Основная роль | Российский учет угроз и уязвимостей | Глобальная идентификация уязвимостей | Обогащение CVE техническими данными |
| Идентификатор | BDU:год-номер | CVE-год-номер | CVE-год-номер |
| Язык и контекст | Русский, терминология ФСТЭК | Английский, международная программа CVE | Английский, техническая база NIST |
| Машинная обработка | Зависит от доступных выгрузок и внутреннего адаптера | Публичные записи CVE | Документированный CVE API |
| Числовой ориентир | BDU-номер для локальной отчетности | Один CVE на одну публичную уязвимость | 348 194 CVE-записи в документации API |
| Где использовать | Модель угроз, отчеты, внутренний реестр, российский контур ИБ | Поиск первичной записи и ссылок | Автоматизация, CVSS, CPE, интеграция со сканерами |
Что это значит для рынка
БДУ ФСТЭК становится особенно ценным там, где управление уязвимостями связано не только с техническим исправлением, но и с доказуемостью процесса. Для зрелой команды важно показать, что уязвимость обнаружена, применимость проверена, риск оценен, владелец назначен, исправление выполнено, а результат подтвержден. BDU-номер в этом процессе играет роль связующего идентификатора между техническим событием и управленческим учетом.
- Для CTO: БДУ помогает перевести поток CVE в управляемый риск для конкретных систем, владельцев и сроков исправления.
- Для CISO: связка CVE ↔ BDU повышает качество отчетности и снижает спорность приоритизации уязвимостей.
- Для security-инженера: главное — не вручную читать сотни карточек, а встроить БДУ в нормализованный процесс мониторинга, разбора и проверки.
- Для DevSecOps: ценность БДУ растет при наличии SBOM и SCA, потому что команда может быстро понять, затронут ли конкретный компонент приложения.
Рекомендации
- Создайте единую таблицу соответствий CVE и BDU. Это снижает потери контекста между международными сканерами, внутренним реестром и отчетами по российскому контуру ИБ.
- Добавьте поля БДУ в карточку уязвимости. Минимум: BDU, CVE, CVSS, продукт, версия, владелец актива, дата проверки, статус исправления и ссылка на исходную карточку.
- Свяжите БДУ с инвентаризацией активов. Без CMDB, SBOM или другого перечня компонентов команда будет знать об уязвимости, но не сможет быстро доказать ее применимость.
- Используйте SIEM для обогащения, а SOAR — для маршрутизации. SIEM должен добавлять контекст, SOAR — создавать задачи и проверки, но финальное закрытие риска должно подтверждаться техническим контролем.
- Разделяйте базовую опасность и фактический риск. CVSS 9,8 требует внимания, но приоритет исправления должен учитывать экспонирование, критичность актива и наличие компенсирующих мер.
- Закрепите процесс в регламенте. Для каждой критичной уязвимости нужен один понятный маршрут: источник → проверка применимости → владелец → исправление → повторная проверка → закрытие.
Выводы
БДУ ФСТЭК уязвимости — это не просто справочник, а важный элемент российского процесса vulnerability management. Он дает локальный идентификатор, терминологию и контекст, который нужен для отчетности, оценки защищенности и коммуникации с владельцами систем. При этом техническая полнота достигается только при совместном использовании БДУ, CVE, NVD, бюллетеней производителей, сканеров, SCA и SBOM.
Практический результат появляется тогда, когда БДУ встроен в ежедневный рабочий процесс. Команда должна уметь быстро найти CVE по BDU, найти BDU по CVE, связать запись с активом, назначить владельца, проконтролировать исправление и подтвердить результат.
Главная зрелость не в том, чтобы иметь еще один список уязвимостей, а в том, чтобы каждая запись БДУ превращалась в проверяемое действие с владельцем, сроком и техническим доказательством закрытия.
- Доступность источников. Официальные страницы БДУ могут быть недоступны для автоматизированной проверки, поэтому часть примеров сверялась через публичные карточки и вторичные каталоги со ссылками на исходные записи.
- Неполнота машинного доступа. В статье не утверждается наличие универсального публичного API БДУ; для промышленной интеграции требуется проверять разрешенные форматы доступа и условия использования.
- Демонстрационный характер примера. CVE-2026-3843 и BDU:2025-13914 использованы как открытый пример связки идентификаторов; перед внедрением реагирования нужно сверять актуальную карточку и бюллетень производителя.
- Регуляторная применимость. Материал не заменяет юридическую оценку требований ФСТЭК, внутренний регламент организации и модель угроз конкретной системы.
FAQ о БДУ ФСТЭК уязвимости
Что такое БДУ ФСТЭК простыми словами?
БДУ ФСТЭК — это Банк данных угроз безопасности информации, где публикуются сведения об угрозах и уязвимостях, значимых для российских организаций. В части уязвимостей карточка БДУ помогает понять, какой продукт затронут, какие версии уязвимы, какой уровень опасности указан, есть ли связь с CVE и какие источники нужно проверить. Для инженера это не замена NVD или MITRE CVE, а российский слой учета, который удобно использовать в отчетах, регламентах и внутренних задачах на исправление.
Как найти CVE по номеру БДУ?
Откройте карточку уязвимости БДУ и найдите блок с внешними идентификаторами. Если уязвимость сопоставлена с международной базой, там будет указан CVE. Затем этот CVE нужно проверить в NVD или MITRE CVE, чтобы получить дополнительные технические детали: CVSS-вектор, CWE, ссылки на бюллетени производителя и машинно-читаемые данные. В корпоративной практике лучше сохранять обе ссылки в одной карточке уязвимости, чтобы не искать соответствие повторно при каждом отчете или повторном сканировании.
Можно ли использовать только БДУ без NVD и MITRE CVE?
Для зрелого процесса управления уязвимостями этого недостаточно. БДУ дает важный российский контекст и идентификатор, но международные базы часто содержат больше технических деталей, ссылок на производителя, CPE, CWE и данные для автоматизации. На практике лучше использовать связку: БДУ для локального учета и регуляторной терминологии, CVE для международной идентификации, NVD для API, CVSS, CPE и обогащения данных. Такой подход снижает риск пропустить важное исправление или неправильно оценить применимость уязвимости.
Как встроить БДУ ФСТЭК в SIEM или SOAR?
Начинать нужно с нормализации полей. Внутренний реестр должен хранить CVE, BDU, CVSS, продукт, версию, владельца актива, статус исправления и ссылку на источник. После этого SIEM может обогащать события BDU-номером и уровнем риска, а SOAR — создавать задачи, запускать проверки и маршрутизировать уведомления владельцам. Закрывать задачу автоматически только по факту отправки уведомления нельзя: нужен повторный технический контроль, например сканирование, проверка версии или подтверждение установки обновления.
Чем БДУ помогает при работе с SBOM и SCA?
SBOM показывает, какие компоненты и версии входят в приложение, а SCA находит уязвимости в этих компонентах. БДУ добавляет российский слой учета: если уязвимый компонент связан с записью БДУ, команда может включить ее в отчетность и внутренний реестр. Это особенно полезно для организаций, где важно показать не только CVE, но и BDU-номер. Подробнее о практической связке компонентов, SCA и процессов разработки см. в материале SBOM и SCA в России 2026.
Какой рабочий процесс нужен security-инженеру для БДУ уязвимостей?
Минимальный процесс состоит из четырех этапов: мониторинг, разбор, исправление и проверка. Сначала команда получает сигнал из БДУ, NVD, сканера или SCA. Затем проверяет, есть ли затронутый продукт в инфраструктуре. После этого назначает владельца и выбирает способ исправления: обновление, изменение конфигурации или временное ограничение доступа. Финальный этап — повторная проверка. Без нее уязвимость может остаться закрытой только в системе задач, но не в реальной среде.
*Обзор основан на квартальной отчётности компаний и отраслевых опросах. Цифры верифицированы по двум независимым источникам где возможно.*