Классификация уязвимостей информационных систем — фундамент управления киберрисками. Без единой системы идентификации, описания и оценки уязвимости превращаются в бесконечный список разрозненных записей, которые нельзя сравнивать, приоритизировать и закрывать в срок. Мировое сообщество выработало три базовые системы: CVE (каталог конкретных уязвимостей), CWE (таксономия типов уязвимостей) и CVSS (метрика критичности). Россия добавляет к ним ещё две обязательные к применению — БДУ ФСТЭК (государственный реестр) и ГОСТ Р 56546-2015 (стандарт классификации). Пять систем решают разные задачи и работают вместе — и именно эта связка лежит в основе мер защиты, которые требуют приказы ФСТЭК №117, №21 и №239.
TL;DR: На практике уязвимость классифицируют пятью системами одновременно: CVE даёт уникальный идентификатор записи, CWE — тип (таксономия из 900+ паттернов), CVSS — оценку критичности 0.0–10.0, БДУ ФСТЭК — юридически значимую запись в российском контуре, ГОСТ Р 56546-2015 — единую форму для отчётности в ФСТЭК. Приказ №117 требует работать со всеми пятью для аттестации ГИС.
Эта статья — обзор всех пяти систем классификации уязвимостей с привязкой к российскому регулированию. Материал рассчитан на специалистов ИБ, ИТ-руководителей, аудиторов и разработчиков, которым нужно понимать, как разные каталоги связаны между собой и почему в отчётности для ФСТЭК недостаточно только CVE-идентификатора. В конце показан сквозной пример того, как одна уязвимость проходит через все пять систем — от записи в NVD до меры защиты из приказа №117 в SGRC-платформе КиберОснова.
Зачем нужна классификация уязвимостей
Современные информационные системы содержат тысячи компонентов: операционные системы, веб-серверы, базы данных, прикладное ПО, микросервисы, IoT-устройства, ИИ-модели. В каждом из них регулярно находят ошибки, которые атакующие могут использовать для нарушения конфиденциальности, целостности или доступности данных. Без единой системы классификации уязвимостей организация тонет в потоке разнородных уведомлений: одну и ту же проблему по-разному называют вендор, исследователь, багтрекер, регулятор.
Классификация уязвимостей информационных систем решает четыре задачи. Первая — идентификация: каждая уязвимость должна иметь уникальный идентификатор, по которому её можно найти в любой базе данных. Вторая — типизация: нужно понимать, к какому семейству относится ошибка (SQL-инъекция, переполнение буфера, ошибка авторизации), чтобы применять одни и те же техники защиты. Третья — оценка: необходимо сравнивать уязвимости между собой по критичности, чтобы приоритизировать работы. Четвёртая — отчётность: регулятор и руководство организации должны видеть единый язык, на котором говорит ИБ-команда.
Для российских организаций классификация уязвимости информации — ещё и юридическая необходимость. Приказ ФСТЭК №117, вступивший в силу 1 марта 2026 года, требует мониторинга БДУ ФСТЭК с жёсткими SLA на устранение, а ГОСТ Р 56546-2015 задаёт обязательную классификацию для аттестации государственных информационных систем. Международных каталогов недостаточно — их записи не имеют юридической силы в российском контуре, но игнорировать их тоже нельзя: значительная часть записей БДУ ФСТЭК ссылается на международные CVE и классифицирована по CWE. Поэтому на практике используют все пять систем одновременно.
CVE — каталог публичных уязвимостей (MITRE)
CVE (Common Vulnerabilities and Exposures) — старейший международный каталог конкретных уязвимостей. Ведётся MITRE Corporation с 1999 года при поддержке CISA (США). Цель проекта — дать каждой публично известной уязвимости уникальный идентификатор, чтобы специалисты по всему миру могли однозначно ссылаться на одну и ту же проблему.
Формат идентификатора — CVE-YYYY-NNNNN, где YYYY — год присвоения, NNNNN — порядковый номер. На начало 2026 года в каталоге более 250 000 записей. Каждый CVE содержит краткое описание проблемы (на английском), перечень затронутых продуктов и версий, ссылки на патчи, бюллетени вендоров, исследовательские публикации и присвоенный CVSS-балл. Параллельно запись дублируется в базе NVD (National Vulnerability Database) американского института NIST, где добавляется CWE-классификация и дополнительные метаданные.
CVE отвечает на вопрос «какая конкретно уязвимость найдена в каком продукте». Это нижний уровень классификации: не тип, не класс, не рейтинг, а конкретная запись о конкретной проблеме. Пример: CVE-2021-44228 — это Log4Shell в Apache Log4j 2.x, CVE-2022-0847 — Dirty Pipe в ядре Linux, CVE-2024-3094 — бэкдор в xz/liblzma.
Для российских организаций CVE — не обязательный, но необходимый источник. Большинство записей в БДУ ФСТЭК содержат ссылку на соответствующий CVE: это упрощает сопоставление сведений с международными бюллетенями и получение патчей от вендоров быстрее, чем выходит официальное обновление БДУ. При этом для отчётности в ФСТЭК используется именно номер БДУ, а не CVE — CVE-идентификатор считается вспомогательным.
CWE — классификация типов уязвимостей ПО (MITRE)
CWE (Common Weakness Enumeration) — международная таксономия типов уязвимостей ПО, которую MITRE развивает с 2006 года. Если CVE отвечает на вопрос «что найдено», то CWE — «к какому классу относится эта проблема». Каталог содержит свыше 900 записей, каждая из которых описывает паттерн ошибки: CWE-89 — SQL Injection, CWE-79 — Cross-Site Scripting, CWE-287 — Improper Authentication, CWE-862 — Missing Authorization, CWE-502 — Deserialization of Untrusted Data, CWE-918 — Server-Side Request Forgery.
Структура CWE иерархическая и состоит из четырёх уровней. Pillar — самый общий уровень (например, «неправильная нейтрализация данных»). Class — класс уязвимостей внутри столпа (например, «инъекция»). Base — базовый тип уязвимости (например, «SQL Injection»). Variant — конкретный вариант реализации. Такая иерархия позволяет работать на разных уровнях детализации: аудитор может оценивать покрытие по классам, а разработчик — искать конкретные варианты в коде.
Ежегодно MITRE публикует CWE Top 25 — рейтинг 25 самых опасных типов уязвимостей на основе анализа всех CVE за последние два года. В версии 2023 года первое место заняла CWE-787 (Out-of-bounds Write), на втором CWE-79 (Cross-site Scripting), на третьем CWE-89 (SQL Injection). Этот рейтинг используется как приоритет для SAST-правил и checklist-ов безопасного программирования.
Значение CWE для российских организаций ключевое: каждая запись БДУ ФСТЭК обязательно содержит CWE-классификацию. Именно CWE связывает российский реестр с международной практикой, SAST/DAST-сканерами (PT Application Inspector, Svace, SonarQube, Semgrep) и стандартами безопасной разработки. Подробный каталог CWE с описаниями на русском и привязкой к БДУ размещён на странице CWE КиберОснова. Детальный разбор применимости CWE Top 25 в российском регулировании — в отдельной статье о каталоге типов уязвимостей.
CVSS — метрика критичности уязвимости (FIRST.org)
CVSS (Common Vulnerability Scoring System) — открытый стандарт оценки критичности уязвимостей, разработанный международной организацией FIRST.org. CVSS переводит качественное описание уязвимости в количественную оценку от 0.0 до 10.0: чем выше балл, тем опаснее уязвимость. Это единственный международно признанный метод, который автоматически сравнивает тысячи уязвимостей между собой и строит объективный backlog на устранение.
В индустрии сейчас используются три версии. CVSS v2.0 — устарел, встречается только в старых базах данных. CVSS v3.1 — основная версия, которой пользуются NVD, БДУ ФСТЭК, все вендорские базы данных и коммерческие сканеры. CVSS v4.0 — новая версия 2023 года, постепенно внедряется в новых системах: в ней пересмотрены формулы Base, добавлены дополнительные метрики Supplemental (Automatable, Recovery, Value Density) и Threat.
Оценка CVSS складывается из трёх групп метрик. Base — неизменяемые характеристики самой уязвимости: вектор атаки (сеть, локальный, физический), сложность эксплуатации, требования к привилегиям, влияние на CIA-триаду. Temporal — изменяемые во времени характеристики: наличие публичного эксплойта, зрелость патча, степень подтверждения. Environmental — специфичные для конкретной организации: критичность актива, требования к конфиденциальности и целостности данных. В публичных базах обычно публикуется только Base Score — организация достраивает Temporal и Environmental самостоятельно с учётом своего контекста.
Классификация уязвимостей безопасности по CVSS стандартна: Critical — 9.0–10.0, High — 7.0–8.9, Medium — 4.0–6.9, Low — 0.1–3.9, None — 0.0. Именно по этой шкале работает приказ ФСТЭК №117: критические уязвимости должны быть устранены за 24 часа с момента обнаружения, высокие — за 7 дней, средние — за 30 дней, низкие — за 90 дней. SLA рассчитывается автоматически по CVSS-баллу из БДУ ФСТЭК. Посчитать балл для любой уязвимости онлайн можно в калькуляторе CVSS v4.0 КиберОснова — поддерживаются обе версии, v3.1 и v4.0, с вычислением Environmental-компонентов.
Нужен централизованный мониторинг CVSS для всей инфраструктуры? КиберОснова SGRC синхронизируется с БДУ ФСТЭК ежедневно, автоматически рассчитывает SLA по приказу №117 на основе CVSS-балла и назначает ответственных. Запросить демо →
БДУ ФСТЭК — российский реестр уязвимостей
БДУ ФСТЭК (Банк данных угроз безопасности информации) — официальный российский реестр уязвимостей, который ведёт Федеральная служба по техническому и экспортному контролю с 2015 года. На апрель 2026 года реестр содержит свыше 85 000 записей об уязвимостях и более 220 записей об угрозах безопасности информации (УБИ). Для российских организаций БДУ ФСТЭК — основной источник данных об уязвимостях при построении модели угроз и выполнении требований приказов ФСТЭК.
Формат идентификатора — BDU:YYYY-NNNNN, где YYYY — год, NNNNN — порядковый номер. Каждая запись содержит название уязвимости на русском языке, подробное описание, затронутое ПО (с точностью до версии), CWE-маппинг (ссылка на международную таксономию), CVSS-оценку по версии 3.1, ссылку на соответствующий CVE (если есть), рекомендации по устранению и список источников. Записи БДУ создаются как российскими исследователями, так и на основе зарубежных CVE, переведённых и адаптированных для российского контекста.
Принципиальное отличие БДУ ФСТЭК от международных каталогов — юридический статус. Записи БДУ обязательны к мониторингу для всех организаций, подпадающих под приказы ФСТЭК №117, №21, №239 и №77: государственные информационные системы, информационные системы персональных данных, значимые объекты критической информационной инфраструктуры. Отчётность в ФСТЭК принимается только по идентификаторам БДУ — ссылка на CVE не считается самостоятельной записью. Это значит, что даже если уязвимость опубликована в NVD и широко обсуждается в мировом сообществе, до появления записи БДУ её формально «нет» с точки зрения российского регулирования.
Онлайн-реестр БДУ ФСТЭК с фильтрацией по CWE, CVSS, производителю ПО и названию уязвимости доступен на странице реестра БДУ в КиберОснова. Платформа синхронизируется с официальным источником bdu.fstec.ru ежедневно и показывает новые записи в течение первых часов после публикации. Подробный разбор модуля БДУ в SGRC-платформе — на странице модуля БДУ ФСТЭК.
ГОСТ Р 56546-2015 — классификация уязвимостей по российскому стандарту
ГОСТ Р 56546-2015 — национальный стандарт Российской Федерации, утверждённый Росстандартом в 2015 году. Полное название: «Защита информации. Уязвимости информационных систем. Классификация уязвимостей информационных систем». Это единственный российский стандарт, который даёт формализованную таксономию уязвимостей информационных систем и обязателен к применению при аттестации государственных информационных систем и проверке значимых объектов КИИ. Если БДУ ФСТЭК — это реестр, то ГОСТ Р 56546-2015 — это метод его систематизации.
Стандарт разделяет уязвимости по четырём классификационным признакам. Первый — по источнику появления: кодовые (ошибки в исходном коде или бинарных файлах), конфигурационные (неверные настройки ПО или ОС), организационные (слабые процессы, отсутствие регламентов). Второй признак — по месту возникновения: архитектурные (на уровне проектирования системы), программные (в прикладном ПО), программно-аппаратные (в firmware), программно-технические (на стыке ПО и оборудования) и физические (в каналах связи или носителях информации). Такая классификация покрывает все уровни технологического стека — от бизнес-логики до физического доступа.
Третий классификационный признак — степень опасности. ГОСТ задаёт четыре уровня — критические, высокие, средние, низкие — и фактически ссылается на CVSS как механизм количественной оценки. Это делает международную шкалу CVSS частью российского нормативного поля. Четвёртый признак — этап жизненного цикла: проектирование, разработка, внедрение, эксплуатация, сопровождение. Этот признак важен для организации процессов: уязвимости этапа разработки закрываются через SAST и SCA в CI/CD, уязвимости эксплуатации — через процессы управления изменениями и патч-менеджмент. Гост классификация уязвимостей используется в отчётах для ФСТЭК при аттестации и переаттестации, а также при внутренних аудитах соответствия.
Важная особенность ГОСТ Р 56546-2015 — стандарт не задаёт перечень конкретных уязвимостей, а только правила их описания. Наполнение реестра ведёт БДУ ФСТЭК. Поэтому на практике работают в связке: БДУ даёт исходные данные, ГОСТ Р 56546 — единую форму для их классификации и отчётности. Дополнительно стандарт сопровождается ГОСТ Р 56545-2015 («Правила описания уязвимостей»), который задаёт структурированный формат записи — именно он используется в полях карточки БДУ.
Сравнительная таблица пяти систем классификации
| Система | Издатель | Назначение | Формат | Обязательна в РФ | Связь с приказами ФСТЭК |
|---|---|---|---|---|---|
| CVE | MITRE / CISA | Каталог конкретных уязвимостей | CVE-YYYY-NNNNN | Нет (вспомогательная) | Используется через БДУ |
| CWE | MITRE | Таксономия типов уязвимостей | CWE-NNN | Нет (через БДУ) | Классификатор в БДУ |
| CVSS | FIRST.org | Метрика критичности | 0.0–10.0 (v3.1 / v4.0) | Фактически (через БДУ) | SLA по приказу №117 |
| БДУ ФСТЭК | ФСТЭК России | Государственный реестр уязвимостей | BDU:YYYY-NNNNN | Да | Прямое требование №21, №117, №239 |
| ГОСТ Р 56546-2015 | Росстандарт | Стандарт классификации | 4 классификационных признака | Да (для ГИС и КИИ) | Аттестация ГИС, проверки КИИ |
Таблица показывает, что системы классификации уязвимостей информационных систем не конкурируют, а дополняют друг друга. CVE даёт уникальный идентификатор, CWE — тип уязвимости, CVSS — оценку критичности, БДУ — юридически значимую запись в российском контуре, ГОСТ Р 56546 — единую форму для отчётности. Полноценная работа с уязвимостями требует использования всех пяти — именно этого ожидает регулятор при проверках.
Как эти системы взаимодействуют на практике
Разберём сквозной пример. Представим, что в начале апреля 2026 года в популярной CMS Bitrix обнаружена уязвимость SQL-инъекции в модуле обработки форм. Атакующий может внедрить произвольный SQL-запрос через поле email и получить доступ к базе данных сайта, включая таблицы с персональными данными клиентов.
Шаг 1. Исследователь публикует уязвимость, MITRE присваивает идентификатор — условно CVE-2026-12345. Запись попадает в NVD, где получает CWE-классификацию — CWE-89 (Improper Neutralization of Special Elements used in an SQL Command). NVD рассчитывает CVSS Base Score по формулам v3.1 — допустим, 9.8 (Critical): вектор атаки «сеть», сложность «низкая», привилегии не нужны, взаимодействие пользователя не требуется, влияние на конфиденциальность, целостность и доступность «высокое». Параллельно NVD публикует оценку по CVSS v4.0.
Шаг 2. ФСТЭК России заносит уязвимость в БДУ ФСТЭК под номером BDU:2026-04567. В карточке: описание на русском, точные версии уязвимого продукта (Bitrix 24 версий с X.Y по X.Z), CWE-маппинг (CWE-89), CVSS-балл (9.8), ссылка на исходный CVE, рекомендации по устранению (обновить Bitrix до версии X.Z+1 или применить патч вручную).
Шаг 3. Согласно ГОСТ Р 56546-2015 уязвимость классифицируется так: по источнику — кодовая (ошибка в исходном коде), по месту возникновения — программная (в прикладном ПО), по степени опасности — критическая (CVSS 9.8), по этапу жизненного цикла — выявлена на этапе эксплуатации. Эта классификация вносится в отчёт об аттестации ГИС, если сайт построен на Bitrix и обрабатывает персональные данные граждан в государственной информационной системе.
Шаг 4. Применяются меры защиты из приказа ФСТЭК №117. Группа мер АНЗ (анализ уязвимостей) требует, чтобы сканирование по БДУ обнаружило проблему в течение суток. Группа мер ЗИС (защита информационной системы) требует изолировать уязвимый сервис от интернета до применения патча. Группа мер ОЦЛ (обеспечение целостности) требует проверить базу данных на следы эксплуатации. SLA на устранение — 24 часа с момента обнаружения, потому что CVSS 9.8 = Critical.
Шаг 5. В SGRC-платформе создаётся задача ИБ: ответственный, дедлайн, ссылка на запись БДУ, CVSS-балл, меры защиты. Система автоматически уведомляет руководство при приближении дедлайна и фиксирует исполнение в журнале для будущей проверки ФСТЭК. Так один инцидент проходит через все пять систем классификации и превращается в конкретную задачу с юридически значимой отчётностью.
Как КиберОснова автоматизирует работу со всеми системами классификации
SGRC-платформа КиберОснова связывает пять систем классификации уязвимостей в единый процесс управления. Специалист ИБ работает в одном интерфейсе вместо того, чтобы вручную сверять NVD, bdu.fstec.ru, сканеры SAST/DAST и Excel-таблицы активов.
Первый модуль — синхронизация с БДУ ФСТЭК. Платформа ежедневно скачивает свежие записи с официального источника bdu.fstec.ru и импортирует их в свой реестр с сохранением всех полей: CWE, CVSS, ссылки на CVE, рекомендации ФСТЭК. Новые записи попадают в систему в течение нескольких часов после публикации — это критично для критических уязвимостей, по которым SLA приказа №117 составляет 24 часа. Одновременно платформа ведёт локальный кэш с историей изменений — если ФСТЭК обновляет запись (например, добавляет новый CVE или уточняет затронутые версии), система фиксирует это в журнале.
Второй модуль — сопоставление уязвимостей с активами. Каждая уязвимость из БДУ автоматически проверяется на соответствие реестру ИТ-активов организации: если где-то установлена уязвимая версия Nginx, Bitrix, PHP или ядра Linux, система создаёт задачу на устранение. Маппинг идёт по CPE (Common Platform Enumeration) — международному стандарту идентификации продуктов, на который опирается как NVD, так и БДУ. Вручную заводить ничего не нужно: достаточно поддерживать актуальность реестра активов.
Третий модуль — расчёт SLA по приказу №117. Для каждой найденной уязвимости система определяет CVSS-балл из БДУ и автоматически рассчитывает дедлайн: Critical — 24 часа, High — 7 дней, Medium — 30 дней, Low — 90 дней. Дедлайн привязан к задаче ИБ, назначается ответственный, настраиваются уведомления о приближении срока. При приближении deadline система эскалирует задачу руководителю. Встроенный калькулятор CVSS позволяет пересчитать балл с учётом Environmental-компонентов — например, если актив не критичный, балл может быть снижен, и SLA изменится.
Четвёртый модуль — отчётность по ГОСТ Р 56546-2015. Платформа автоматически формирует отчёты для регулятора с классификацией уязвимостей по всем четырём признакам стандарта. Это критично при аттестации ГИС и проверках КИИ: без такой классификации отчёт не принимается. Отчёты выгружаются в формате DOCX и PDF, готовы к подписи руководителя и отправке в территориальные подразделения ФСТЭК. Для справки: полный перечень мер защиты, которые должны быть реализованы в связке с работой по уязвимостям, разбирается в статье Приказ ФСТЭК №117 вступил в силу и для КИИ в статье Приказ ФСТЭК №239.
Хотите увидеть, как это работает на ваших данных? КиберОснова покажет мониторинг БДУ ФСТЭК, автоматический расчёт SLA по приказу №117 и формирование отчётов по ГОСТ Р 56546-2015 на примере вашей инфраструктуры за 30 минут. Запросить демо →
Часто задаваемые вопросы
Ниже — короткие ответы на типовые вопросы о системах классификации уязвимостей. Более подробные материалы: OWASP Top 10 на русском для рейтинга десяти самых критичных классов уязвимостей веб-приложений, Уязвимости веб-приложений для базового обзора темы и Приказ ФСТЭК №117 для ГИС для детального разбора новых требований к мониторингу БДУ и SLA.
Классификация уязвимостей программного обеспечения в российском правовом поле — это не абстрактная методология, а вполне конкретные обязательства: ежедневный мониторинг БДУ ФСТЭК, CWE-сопоставление каждой находки, CVSS-приоритизация и отчётность по ГОСТ Р 56546-2015. Ручная реализация этих процессов в Excel возможна, но при реестре активов в сотни позиций становится узким местом: специалист ИБ тратит больше времени на сверку таблиц, чем на реальное устранение уязвимостей. Автоматизация через SGRC-платформу снимает эту нагрузку и превращает работу с пятью системами классификации в единый предсказуемый процесс.
