Что случилось с NVD и почему опираться на один источник уязвимостей больше нельзя
Управление уязвимостями начинается не со сканера и не с отчёта, а с качественных данных. Организация должна понимать, какие ошибки безопасности существуют, какие продукты они затрагивают, насколько опасны и есть ли для них исправления или публичные эксплойты.
Долгое время многие компании фактически строили этот процесс вокруг двух элементов: международного реестра CVE и американской базы NVD. Такая модель казалась удобной: CVE присваивал уязвимости уникальный идентификатор, а NVD дополняла запись оценкой CVSS, сведениями о затронутых продуктах, типе слабости и дополнительными рекомендациями. Однако в 2024-2026 годах стало очевидно, что прежняя схема больше не гарантирует полноту и оперативность.
Какие источники данных использовать
БДУ ФСТЭК
Для российских организаций одним из ключевых источников остаётся Банк данных угроз безопасности информации ФСТЭК России. Он ориентирован на отечественное законодательство, российскую инфраструктуру и продукты, которые могут отсутствовать в зарубежных каталогах.
В БДУ публикуются описания уязвимостей, возможные последствия, сведения о затронутых системах и рекомендации по устранению. Записи получают идентификаторы формата BDU:2024-01398. Отдельно ведётся перечень наиболее опасных и активно обсуждаемых уязвимостей, который можно использовать как ориентир для первоочередной проверки инфраструктуры.
По состоянию на август 2026 года в банке насчитывается более 92 тысяч записей. Для российских компаний это не просто дополнительный каталог, а важный элемент нормативного и практического контура управления рисками.
CVE и MITRE
CVE - это прежде всего международная система идентификаторов, а не полноценная аналитическая база. Номер CVE позволяет однозначно связать одну и ту же уязвимость с бюллетенями производителей, отчётами исследователей, правилами сканеров и записями в национальных базах.
Например, CVE-2021-44228 стал общепринятым обозначением уязвимости Log4Shell. При этом сам идентификатор не отвечает на все вопросы: насколько опасна проблема, какие версии затронуты, можно ли её эксплуатировать удалённо и существует ли рабочий эксплойт. Эти сведения приходится получать из других источников.
NVD
Национальная база уязвимостей США традиционно считалась одним из самых удобных и подробных источников. Она связывала CVE с продуктами через CPE, публиковала оценки CVSS, описывала типы слабостей и помогала автоматизировать сопоставление уязвимостей с активами.
Проблема в том, что NVD перестала успевать обрабатывать весь поток новых записей. С февраля 2024 года массовое обогащение CVE фактически замедлилось: оценки, привязки к продуктам и классификация стали появляться с задержкой либо отсутствовать вовсе.
К концу 2025 года накопилось свыше 27 тысяч необработанных уязвимостей. В мае 2026 года аудит генерального инспектора Министерства торговли США подтвердил масштаб отставания и спрогнозировал появление более 60 тысяч новых уязвимостей за 2026 год.
С апреля 2026 года NIST перешёл к риск-ориентированной модели: приоритет получают уязвимости из каталогов активно эксплуатируемых угроз и проблемы в критически важном программном обеспечении. Для пользователей это означает простую вещь: отсутствие подробной записи в NVD больше нельзя воспринимать как отсутствие риска.
Почему нельзя использовать только NVD
Одна база не может одновременно быть самой быстрой, самой полной и одинаково хорошо описывать все продукты. У каждого источника есть собственные ограничения:
- национальные каталоги лучше отражают локальные требования и отечественное ПО;
- вендоры быстрее сообщают об уязвимостях в собственных продуктах;
- NVD удобна для стандартизированного обогащения, но может отставать;
- CVE даёт идентификатор, однако не заменяет анализ угроз;
- исследовательские команды публикуют технические детали и эксплойты раньше официальных баз.
Кроме того, одна и та же проблема может появиться в разных источниках под разными уровнями детализации. Если система управления уязвимостями проверяет только одну базу, она рискует пропустить свежую запись, локальный идентификатор, ошибочную привязку к версии или важное предупреждение производителя.
Контракт CVE как сигнал для отрасли
В апреле 2025 года истёк контракт MITRE на поддержку программы CVE. В течение примерно суток существовал риск остановки присвоения новых идентификаторов. Контракт продлили ещё на 11 месяцев - до марта 2026 года, а параллельно была создана независимая CVE Foundation.
Ситуация показала уязвимость самой инфраструктуры обмена данными: мировой рынок кибербезопасности долгое время зависел от единого механизма, финансируемого в рамках ежегодного государственного соглашения. К началу 2026 года финансирование перевели в базовую бюджетную статью, что снизило вероятность повторения кризиса, однако CVE Foundation продолжила развиваться как резервная модель.
Что делать с уязвимостями нулевого дня
Уязвимость нулевого дня может отсутствовать во всех каталогах. Если производитель ещё не выпустил бюллетень, исследователь не зарегистрировал CVE, а эксплойт уже используется злоумышленниками, ожидание обновления базы становится опасным.
Поэтому обнаружение таких угроз должно опираться не только на идентификаторы. Важны:
- уведомления производителей;
- сообщения центров реагирования;
- телеметрия средств защиты;
- данные о попытках эксплуатации;
- правила обнаружения подозрительного поведения;
- сведения об активных кампаниях и вредоносных инструментах.
Нулевой день следует рассматривать как событие управления риском. Даже если формального номера ещё нет, компания должна иметь возможность временно ограничить доступ, отключить уязвимый компонент, применить компенсирующее правило или усилить мониторинг.
Как должна выглядеть современная модель сбора данных
Надёжный процесс строится вокруг нескольких независимых каналов. Минимальный набор для российской организации может включать БДУ ФСТЭК, CVE, NVD, бюллетени поставщиков, данные об эксплойтах и собственные результаты исследований.
Все записи необходимо нормализовать: объединять дубликаты, сопоставлять CVE и BDU, приводить названия продуктов к единому виду, учитывать версии и исправления. Отдельно нужно хранить дату публикации, дату последнего обновления и источник каждого атрибута.
Система также должна уметь показывать не только наличие уязвимости, но и степень уверенности в сопоставлении. Автоматическая привязка по одному названию пакета может оказаться ошибочной, особенно если продукт поставляется в разных редакциях или собирается дистрибьютором.
Почему важна скорость
Запись об уязвимости, появившаяся через несколько недель после публикации исправления, может быть полезной для отчётности, но бесполезной для реагирования. На практике критичны первые часы и дни: именно в этот период производители выпускают патчи, исследователи анализируют проблему, а злоумышленники начинают массовое сканирование.
Поэтому система должна регулярно получать обновления, отслеживать изменения уже известных записей и немедленно пересчитывать приоритеты после появления эксплойта или подтверждения активной эксплуатации.
Как расставлять приоритеты
CVSS полезен, но его недостаточно. Высокая техническая оценка не всегда означает высокий риск именно для конкретной компании. В приоритизацию следует включать:
- наличие публичного эксплойта;
- факт эксплуатации в реальных атаках;
- доступность актива из интернета;
- критичность бизнес-сервиса;
- наличие конфиденциальных данных;
- возможность быстро установить исправление;
- наличие компенсирующих мер;
- соответствие уязвимости требованиям регулятора.
Такой подход помогает не превращать управление уязвимостями в бесконечную сортировку списка по CVSS и направлять ресурсы на действительно опасные сценарии.
Требования к программному обеспечению
Платформа для обнаружения и обработки уязвимостей должна поддерживать несколько источников, автоматическое обновление, импорт бюллетеней, работу с локальными базами и историю изменений. Желательны интеграции с системами инвентаризации, сканерами, SIEM, средствами управления конфигурациями и сервис-деском.
Не менее важны ручная корректировка результатов, возможность подтверждать или отклонять ложные срабатывания, назначать ответственных и контролировать сроки устранения. Без этих функций организация получает красивый каталог проблем, но не управляемый процесс remediation.
Главный вывод прост: NVD по-прежнему полезна, однако она больше не может быть единственным фундаментом программы управления уязвимостями. Устойчивый процесс требует нескольких источников, постоянного обновления, контроля качества сопоставления и приоритизации с учётом реального риска. Уязвимость должна не просто попасть в базу - её нужно вовремя обнаружить, правильно интерпретировать и связать с конкретным действием по защите инфраструктуры.