Почему закрытие тысяч уязвимостей может почти не снижать риск

Представим обычный отчёт по управлению уязвимостями.

За квартал обнаружено 18 тысяч уязвимостей. Закрыто 12 тысяч. Доля просроченных критических CVE снизилась. Среднее время устранения улучшилось. На дашборде почти всё зелёное.

Но в инфраструктуре продолжает существовать доступный извне сервис. Через его уязвимость можно получить первоначальный доступ, украсть учётные данные технической записи, переместиться на сервер управления и добраться до критической бизнес-системы.

Формально программа vulnerability management показывает положительную динамику. Фактически наиболее опасный сценарий атаки остался нетронутым.

Именно поэтому количество закрытых CVE — удобная метрика производительности, но слабая метрика риска.

Количество публикуемых уязвимостей растёт быстрее, чем возможности большинства компаний по их анализу, тестированию и устранению. По данным NIST, число заявок на регистрацию CVE увеличилось на 263% с 2020 по 2025 год, а в первом квартале 2026 года их поступило почти на треть больше, чем за тот же период предыдущего года. NIST уже переходит к риск-ориентированной модели обогащения записей в National Vulnerability Database, при которой приоритет получают наиболее значимые уязвимости. (NIST)

Это важный сигнал и для корпоративных программ ИБ.

Попытка обрабатывать все уязвимости с одинаковой срочностью больше не выглядит дисциплинированным подходом. Она создаёт огромный операционный шум, перегружает инфраструктурные и продуктовые команды и заставляет тратить ограниченные ресурсы там, где потенциальное снижение риска минимально.

В результате разработка и эксплуатация воспринимают vulnerability management как бесконечный поток технических требований, а руководство получает отчётность, которая демонстрирует активность, но не даёт ответа на главный вопрос:

стала ли компания после всех выполненных работ заметно менее уязвимой для реальной атаки?

Одна из наиболее распространённых ошибок — использовать базовый CVSS как готовую оценку риска.

Сами разработчики стандарта подчёркивают: CVSS Base Score измеряет техническую тяжесть уязвимости, а не риск. Базовая оценка не учитывает конкретную инфраструктуру организации, актуальность угрозы, существующие средства защиты и ценность затронутого актива. Для приближения к риск-ориентированной оценке FIRST рекомендует дополнять её Threat- и Environmental-метриками. (first.org)

Две одинаковые CVE могут иметь для разных компаний совершенно разное значение.

Критическая уязвимость на изолированном тестовом сервере, который не содержит ценных данных и недоступен из недоверенных сегментов, может представлять меньший срочный риск, чем уязвимость с оценкой medium на внешнем сервисе, позволяющая раскрыть информацию, украсть токен или продолжить уже существующий путь атаки.

Severity отвечает на вопрос:

Насколько серьёзными могут быть технические последствия эксплуатации?

Risk требует ответить ещё как минимум на четыре вопроса:

Без этого контекста компания ранжирует абстрактные дефекты программного обеспечения, а не собственные риски.

Уязвимость становится особенно значимой не тогда, когда у неё высокий балл, а когда появляется реалистичный сценарий её использования.

Для этого недостаточно смотреть только на CVSS. Необходимо учитывать несколько источников информации.

CISA поддерживает каталог Known Exploited Vulnerabilities как перечень уязвимостей, для которых существуют подтверждения эксплуатации в реальных атаках, и прямо рекомендует использовать его как входной сигнал для приоритизации vulnerability management. (CISA)

EPSS решает другую задачу: оценивает вероятность того, что конкретная опубликованная CVE будет эксплуатироваться в реальных условиях в течение следующих 30 дней. Это не готовая оценка бизнес-риска, но полезный динамический сигнал, позволяющий отличать теоретически опасные уязвимости от тех, вокруг которых уже формируется активность. (first.org)

Однако даже KEV и высокий EPSS не должны автоматически означать одинаковый приоритет для всех компаний. Сигнал об угрозе нужно сопоставить с собственной инфраструктурой:

Только после этого внешний threat intelligence превращается в управленческое решение.

Атакующий редко мыслит отдельными CVE.

Его интересует цепочка:

точка входа → выполнение кода → получение учётных данных → повышение привилегий → перемещение по инфраструктуре → доступ к критическому активу.

В этой цепочке могут одновременно участвовать:

Поэтому наиболее зрелый вопрос звучит не так:

Сколько критических CVE остаётся открытыми?

А так:

Какие реальные пути позволяют злоумышленнику добраться до наиболее важных активов и в каких точках эти пути можно разорвать?

Современные подходы к exposure management описывают attack path как сквозной маршрут, объединяющий активы, техники и слабые места от начальной точки проникновения до критической цели. Особое значение имеют choke points — узлы, через которые проходят сразу несколько сценариев атаки. Их устранение способно одновременно разрушить несколько опасных маршрутов. (Microsoft Learn)

Именно здесь появляется принципиальная разница между устранением уязвимостей и снижением риска.

Можно закрыть тысячу дефектов на периферийных или изолированных активах. А можно устранить одну ошибку конфигурации, отозвать привилегированную учётную запись или сегментировать административный контур — и разорвать сразу несколько путей к критическим системам.

Зрелая модель должна объединять по меньшей мере шесть видов контекста.

Нужно понимать не только имя сервера и его IP-адрес, но и бизнес-функцию:

Без связи с бизнесом все активы в сканере выглядят почти одинаково.

Следует определить, можно ли реально обратиться к уязвимому компоненту:

Наличие CVE ещё не означает наличие рабочего маршрута эксплуатации.

Здесь учитываются KEV, EPSS, наличие exploit-кода, активность группировок, данные SOC, телеметрия средств защиты и специфика отрасли.

Высокая техническая тяжесть без признаков эксплуатации и подтверждённая эксплуатация менее заметной уязвимости — это разные очереди работ.

Особенно важны слабые места, которые:

Патч — не единственный способ снизить риск.

Иногда быстрее и безопаснее временно:

NIST рассматривает patch management как полный цикл, включающий идентификацию, приоритизацию, установку и проверку исправлений, и рекомендует формировать общую корпоративную стратегию с участием бизнеса, владельцев систем, ИБ и технологических подразделений. (NIST Computer Security Resource Center)

Закрытая задача в ITSM ещё не означает устранённый риск.

После исправления необходимо проверить:

Результатом remediation должна быть подтверждённая новая конфигурация риска, а не только статус Resolved.

Я бы не пытался превращать приоритизацию в одну магическую формулу. Точная цифра часто создаёт лишь иллюзию объективности.

Гораздо полезнее использовать объяснимую модель принятия решений.

Уязвимость или слабое место:

Здесь может потребоваться не только срочное исправление, но и forensic triage: если путь был доступен, необходимо проверить, не использовал ли его кто-то раньше.

Прямых подтверждений атаки пока нет, но эксплуатация вероятна, актив достижим, а потенциальный ущерб или роль в attack path значительны.

Уязвимость технически серьёзная, но актив изолирован, маршрут заблокирован, действуют компенсирующие меры или последствия ограничены.

Исправление остаётся необходимым, но может выполняться в плановом окне.

Уязвимость неэксплуатируема в текущей конфигурации, относится к некритичному активу и не участвует в опасных сценариях.

Такой долг нельзя игнорировать бесконечно, однако его не следует смешивать с действительно срочными рисками.

Количество закрытых CVE можно оставить как операционную метрику. Но рядом должны появиться показатели, отражающие результат:

Такие показатели меняют сам разговор.

ИБ перестаёт доказывать, сколько задач она создала и закрыла. Вместо этого она показывает, какие сценарии атаки были разрушены, какие критические активы стали недостижимы и какой остаточный риск бизнес продолжает принимать.

Цель vulnerability management — не устранить максимальное количество дефектов. Цель — не позволить злоумышленнику превратить отдельные слабости в успешный бизнес-критичный сценарий.

Закрытые CVE являются промежуточным результатом. Настоящий результат — разрушенный путь атаки.

Это не означает, что патчи больше не важны. Напротив, качественный patch management остаётся обязательной частью кибергигиены. Но массовое исправление без знания активов, достижимости, идентификационных связей и потенциального ущерба превращается в дорогостоящую борьбу с очередью.

Зрелая функция ИБ должна уметь объяснить:

У компании может быть идеальная динамика закрытия уязвимостей и одновременно сохраняться один короткий маршрут от внешнего сервиса к критической системе.

Злоумышленнику не нужно эксплуатировать весь backlog. Ему нужен только один рабочий путь.

Поэтому следующий уровень зрелости — перейти от вопроса «сколько CVE мы закрыли?» к вопросу:

какие пути к нашим ключевым активам всё ещё остаются открытыми и какое действие разрушит максимальное количество таких путей?

Именно с этого vulnerability management начинает превращаться из фабрики тикетов в полноценный инструмент управления киберриском.

Подписывайтесь на мой ТГ канал: @ib_decisions