📚 Это часть 11 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.
Управление уязвимостями начинается с информации: о каких уязвимостях вообще нужно знать. Но за последние пару лет сама экосистема источников пережила настоящее землетрясение. То, что раньше казалось вечным и незыблемым (единая база CVE, заботливо обогащенная американским NVD), внезапно зашаталось. Разберем, откуда брать данные сегодня и почему опираться на один источник стало рискованно.
Основные источники данных об уязвимостях для РФ рынка
БДУ ФСТЭК (bdu.fstec.ru) - российский национальный банк данных угроз.
Преимущества:
ориентированность на российский рынок и законодательство
официальные данные, признанные на государственном уровне
детальные описания и рекомендации по устранению
покрытие отечественного ПО, которого может не быть в западных базах
На август 2026 года в БДУ более 92 тысяч уязвимостей [1]. Идентификаторы вида BDU:2024-01398. По уязвимостям здесь можно найти описание, последствия и рекомендации. Отдельно ФСТЭК ведет раздел наиболее опасных (трендовых) уязвимостей - российский аналог каталога эксплуатируемых уязвимостей.
NVD (nvd.nist.gov) - американская национальная база данных об уязвимостях, которую ведет NIST.
Преимущества: широкий охват, детальные описания, привязка к CVSS и CPE. Но именно с NVD случилась главная драма последних лет - о ней ниже.
База CVE (cve.org), поддерживаемая MITRE, - международный реестр идентификаторов уязвимостей. CVE - это стандарт идентификации: один и тот же номер CVE-2021-44228 (Log4Shell) узнают по всему миру. На CVE опираются и NVD, и БДУ, и продукты вендоров.
Сайты вендоров. Бюллетени безопасности производителей ПО: Microsoft, Cisco, ГК “Астра”, Positive Technologies и другие. Часто это самый ранний и самый точный источник: вендор знает о своем продукте больше всех. Классический пример - бюллетень Microsoft MS17-010 об уязвимости в SMB (EternalBlue), которую потом использовал WannaCry.
Внутренние источники. Собственные исследователи компаний-вендоров находят уязвимости, в том числе в чужих и собственных продуктах, и вносят их в свои базы.
Что сломалось в мировой экосистеме (2024-2026)
Это новый раздел, которого не было и не могло быть в первых редакциях книги. Но без него картина была бы неполной.
Кризис NVD (с февраля 2024). Американский NVD, на который десятилетиями опирался весь мир, в феврале 2024 года фактически прекратил массовое обогащение CVE: перестал вовремя добавлять оценки CVSS, привязки к продуктам (CPE), классификацию слабостей. Причина банальна - поток уязвимостей вырос на сотни процентов, а ресурсов аналитиков больше не стало. К концу 2025 года накопился backlog более чем в 27 тысяч необработанных уязвимостей - эту цифру подтвердил и аудит генерального инспектора Минторга США в мае 2026-го, добавив прогноз: более 60 тысяч новых уязвимостей за весь 2026 год. С апреля 2026 года NIST официально перешел на риск-ориентированный подход: в первую очередь обрабатываются только уязвимости из каталога эксплуатируемых и критически важное ПО (как похоже на то, что происходит с уязвимостями в инфраструктурах компаний, да?)) [2]. Проще говоря, привычная “бесплатная” аналитика NVD больше не покрывает все.
Едва не остановившаяся программа CVE (апрель 2025). В апреле 2025 года истек контракт MITRE на ведение программы CVE, и на сутки мир оказался на грани того, что новые CVE перестанут выпускаться вообще. Контракт продлили в последний момент - на 11 месяцев, до марта 2026 года, - а энтузиасты создали независимую CVE Foundation на случай повторения [3]. Это был холодный душ: оказалось, что фундамент всей мировой кибербезопасности держится на одном ежегодном госконтракте. К началу 2026 года ситуацию частично стабилизировали: CISA перевела финансирование CVE-программы в статус базовой статьи бюджета вместо разовой дискреционной, что снижает риск повторения весеннего сценария. CVE Foundation при этом продолжает существовать как независимая структура, но управление программой на себя не взяла - острая необходимость в запасном варианте пока отступила.
Запуск EUVD (май 2025). В ответ на нестабильность Евросоюз устами агентства ENISA запустил собственную европейскую базу уязвимостей - EUVD [4]. Она агрегирует данные из CVE, каталога эксплуатируемых уязвимостей и национальных CERT стран ЕС.
Dbugs - витрина поверх конвейера. С июля 2025 года PT ведет открытый портал dbugs.ptsecurity.com: бесплатный агрегатор данных об уязвимостях без регистрации. На старте - более 300 тысяч записей и 45 тысяч исследователей, сейчас - уже свыше 410 тысяч записей и около 4 тысяч новых в неделю. Каждой уязвимости присваивается собственный ID вида PT-YYYY-XXXXX - внутренняя нумерация карточек портала, статус CNA (CVE Numbering Authority) за PT не закреплен. Описания генерируются с помощью LLM, трендовость считается по активности в соцсетях (X, Reddit, Telegram), ведутся профили исследователей. Мотивация запуска прямая - тот же кризис NVD и MITRE, который мы разбирали выше [10].
Какой вывод из всего этого должен сделать практик? Эпоха единого источника закончилась. Раньше можно было считать NVD “истиной в последней инстанции”. Теперь приходится работать с несколькими источниками сразу: БДУ ФСТЭК для российской специфики и официального статуса, CVE для идентификации, EUVD и бюллетени вендоров для полноты, каталоги эксплуатируемых уязвимостей (CISA KEV, трендовые БДУ) для приоритизации. Для российских компаний эта фрагментация даже выгодна: БДУ ФСТЭК давно развивалась как самостоятельный источник и не зависит от перипетий американского NVD.
Почему нельзя просто взять все из NVD
Даже если бы NVD работал в штатном режиме, без всякого кризиса, полагаться на одну агрегированную базу было бы ошибкой - дело тут не в одной скорости обогащения.
У каждой записи CVE в NVD есть applicability statement - формальное описание того, к каким продуктам и версиям привязана уязвимость. По сути это набор CPE Match Criteria: строки вида cpe:2.3:a:vendor:product:version и диапазоны версий, помеченные как уязвимые. Сам NIST честно пишет, что эта конструкция рассчитана на машины и человеку читается тяжело [5] - и это не преувеличение, если вы хоть раз пытались руками разобрать такую строку.
Беда в том, что CPE-диапазоны регулярно промахиваются в обе стороны. То уязвимой помечена вся линейка версий продукта, хотя проблемная функция включена по умолчанию далеко не везде. То логические операторы внутри блока конфигураций (AND/OR между CPE) обрабатываются некорректно - и это ловят даже открытые сканеры вроде Grype, баг с такими операторами всплывает там не первый год [6].
Но главная дыра не в этом. CPE ничего не говорит об условиях существования уязвимости: при каких настройках, включенных фичах или сочетаниях компонентов брешь реально работает. Какие версии затронуты - это одно. Что должно быть включено, доступно из сети или настроено, чтобы атака прошла, - совсем другое. NVD отвечает только на первый вопрос.
Возьмем Log4Shell (CVE-2021-44228). В CPE уязвимыми числятся версии Log4j 2.0-beta9-2.14.1. Но условия эксплуатации и способ защиты сильно зависят от конкретной сборки: параметр log4j2.formatMsgNoLookups=true, который блокирует атаку, появился только в версии 2.10. Для более ранних веток он вообще не работает, и единственный выход - вручную выпилить класс JndiLookup из classpath [7]. В диапазоне версий из NVD об этом ни слова - знает только тот, кто читал бюллетень разработчика.
Вот почему бюллетень вендора - не дублирующий, а часто более точный источник, чем агрегированные базы. Вендор пишет по-человечески: уязвимость касается только конфигураций с включенным таким-то модулем, для атаки нужен сетевой доступ к такому-то порту, начиная с такой-то версии есть обходной путь без обновления. Поэтому в 2025-2026 годах в VM-индустрии и наметился сдвиг: от “NVD как единственная правда” к модели, где первичным источником становится вендор или CNA, а NVD и агрегаторы остаются для сверки и приоритизации [8].
Кстати, если рассмотреть все решения на отечественном рынке, которые отвечают за поиск уязвимостей, то вы очень сильно удивитесь когда узнаете, что условие существования уязвимостей учитывает только парочку старичков, а все остальные слепо берут CPE2CVE)) Сравнивайте решения правильно)
А как же уязвимости нулевого дня
Предположим, мы собираем данные из всех источников. Но есть уязвимости, о которых не знает ни один из них, - те самые zero-day. Чтобы ловить их, важно внедрять анализ кода еще на этапе разработки.
Если компания разрабатывает собственное ПО, в процесс сборки должны быть встроены анализаторы кода (SAST, DAST, SCA). Но даже если вы ничего не разрабатываете, а просто держите сайт на WordPress или другой CMS, его все равно стоит регулярно проверять анализаторами - в популярных CMS и их плагинах уязвимости находят постоянно (вспомним, что больше всего CVE за 2025 год выпустили именно компании, занимающиеся безопасностью WordPress-плагинов).
Почему процесс должен быть автоматизированным и быстрым
Две причины:
Новые уязвимости появляются ежедневно - около 130 в день в 2025 году (48 185 CVE за год, на 20% больше, чем в 2024-м), и среди них есть критические. Скорость обнаружения критична.
Нужно быстро понять, где у вас эта уязвимость внутри инфраструктуры.
Вручную это потребовало бы целой команды, которая круглосуточно мониторит источники и сопоставляет их с инфраструктурой. Дорого, медленно, ненадежно. Поэтому - специализированные инструменты, автоматизирующие процесс.
Требования к ПО для детектирования уязвимостей
Хороший инструмент детектирования должен отвечать семи требованиям:
Широкий охват источников. Чем больше источников покрыто, тем полнее картина угроз.
Быстрота получения информации. Данные должны попадать в систему максимально быстро.
Быстрота использования. Полученную информацию нужно сразу применять для поиска уязвимостей в инфраструктуре.
Продвинутые методики сканирования. Стандартный сканер проверяет наличие уязвимости только в момент сканирования - этого мало. Нужны продукты, которые собирают и хранят детальную информацию об активах, чтобы выявлять уязвимости сразу после обновления базы, без повторного сканирования.
Непрерывное обновление базы. Устранение должно начинаться как можно быстрее после обнаружения, особенно для трендовых уязвимостей. Напомним: по требованиям ФСТЭК на критические уязвимости отводится 24 часа.
Снижение времени реакции. Чем меньше времени между получением информации об уязвимости и реакцией, тем больше шансов закрыть ее до атаки. А времени мало: медианное время от публикации CVE до попадания в каталог эксплуатируемых уязвимостей CISA KEV сократилось до 5 дней, а почти каждая четвертая (29%) эксплуатируемая уязвимость атакуется в день публикации CVE или раньше [9].
Источники данных об эксплойтах
Помимо данных об уязвимостях, специалисту полезно знать источники данных об эксплойтах - чтобы понимать, что уже доступно злоумышленникам.
Дисклеймер. Все перечисленные ресурсы приводятся исключительно в образовательных целях - для понимания ландшафта угроз и построения защиты. Автор и площадка не призывают к использованию эксплойтов в противоправных целях. Любое тестирование на проникновение допустимо только с письменного разрешения владельца системы. Напомню, что в России деятельность по поиску уязвимостей до сих пор законодательно не урегулирована, а неправомерный доступ к компьютерной информации преследуется по статье 272 УК РФ.
Exploit Database (Exploit-DB) - открытая база эксплойтов от Offensive Security. Бесплатный доступ, широкий ассортимент, подробные описания. exploit-db.com
Metasploit Framework - мощный инструмент разработки и применения эксплойтов, используемый в легальном пентесте. Большая коллекция встроенных эксплойтов, автоматизация. metasploit.com
GitHub и репозитории кода - исследователи публикуют PoC-эксплойты и инструменты. Доступ к исходникам, переписка с автором. github.com
Профильные форумы и сообщества - Reddit (r/netsec), Security Stack Exchange и специализированные площадки. Обсуждение реальных кейсов, ответы опытных специалистов.
Для российского контекста стоит добавить и легальные площадки исследователей: программы багбаунти (Standoff Bug Bounty, BI.ZONE Bug Bounty) и их публичные отчеты дают представление о реальных уязвимостях в отечественных продуктах.
Как устроена доставка данных об уязвимостях у вендора
Сейчас распишу как процесс должен быть реализован в решениях по анализу защищенности.
Приоритизация ПО. Заказчики используют тысячи разных программ - покрыть все детектами сразу невозможно. Поэтому нужно приоритизировать: учитываем наличие эксплойтов, информацию от вендоров и из баз, анализируем популярность ПО по открытым источникам и делим его на целевое, ключевое и периметровое.
Создание детектов. После приоритизации создаем детекты. Классический подход включает стендирование (установку ПО на стенд, анализ его параметров), разработку описания артефактов и их взаимосвязей, написание скриптов, тестирование и выпуск. Сложность сильно варьируется: для Windows версию можно взять из реестра, а для сложного ПО вроде Confluence, где база может быть разнесена на разные серверы, приходится изобретать обходные пути (например, искать файлы командой find на Linux). Для сбора данных используются транспорты: RPC, реестр, WMI, файловые системы для Windows, ODBC для баз данных, SSH для Linux.
Сбор и обработка данных. Собранные должны систематизироваться: скрипты автоматически собирают информацию о версиях ПО, атрибуцируют уязвимости и формируют данные для продукта.
SLA на обновления. Информацию о новых уязвимостях нужно доставлять как можно чаще, но минимум 1 раз в 24 часа (это пессимистичный вариант). Все трендовые уязвимости доложны быть выделены на отдельный дашборд или другой инфомрационный блок с датой обнаружения и деталями.
Жизненный цикл и оценка трендовости. Уязвимость проходит путь от недостатка в коде до общеизвестной угрозы, о которой пишут СМИ. Задача вендора - анализировать, на каком этапе находится уязвимость, и по специальному плейбуку принимать решение о ее трендовости, опираясь на множество источников и собственную базу.
Зачем нам этот закулисный рассказ? Чтобы вы понимали: выбирая VM-инструмент, вы выбираете сканер и вместе с ним весь невидимый конвейер аналитики за его базой уязвимостей. При нынешней фрагментации мировых источников качество этого конвейера становится решающим, да да, именно этот невидимый слой является решающим, а не “более красивый интерфейс”.
А как у вас?
Как вы пережили кризис NVD - заметили вообще или живете на данных вендора и не паритесь? На какие источники опираетесь сейчас и не завязаны ли на единственный?
📚 Источники и ссылки
Источники главы
БДУ ФСТЭК России. https://bdu.fstec.ru/
NIST, “NIST Updates NVD Operations to Address Record CVE Growth”, 15.04.2026, nist.gov; Help Net Security о кризисе обогащения NVD; аудит генерального инспектора Минторга США (OIG), май 2026, о состоянии backlog.
Krebs on Security, “Funding Expires for Key Cyber Vulnerability Database”, апрель 2025; The Record, “CISA extends CVE program contract with MITRE”; создание CVE Foundation, 16.04.2025; CSO Online, “CVE program funding secured, easing fears of repeat crisis”, 2026.
ENISA, запуск European Vulnerability Database (EUVD), 13.05.2025.
NVD, “Understanding Vulnerability Detail Pages” - об applicability statement и CPE Match Criteria. nvd.nist.gov
GitHub, anchore/grype, issue #1349 - пример некорректной обработки логических операторов CPE.
Rapid7, разбор CVE-2021-44228 (Log4Shell); Apache Log4j Security Vulnerabilities.
Kodem Security, “NVD’s decision changes the practice of vulnerability management more than most teams realize”, 2026.
Jerry Gamblin, “2025 CVE Data Review”, январь 2026; Rapid7, 2026 Global Threat Landscape Report; VulnCheck, State of Exploitation 2025-2026; Mandiant (Google Cloud), M-Trends.
Positive Technologies, запуск портала Dbugs, 16-17.07.2025, global.ptsecurity.com; Xakep.ru, обзор портала, июль 2025; dbugs.ptsecurity.com.
Навигация по серии: ⬅️ Предыдущая: Гл. 10. Из 48 000 уязвимостей опасен 1% · 📑 Оглавление серии · Следующая: Гл. 12. Управление активами и уязвимостями на практике ➡️
Если у вас в инфраструктуре что-то устроено иначе - расскажите в комментариях. Зашло - подписывайтесь, чтобы не пропустить следующую часть.
