Управление уязвимостями: от сканера до приоритизации — и при чём здесь пентест

Управление уязвимостями (vulnerability management, VM) — одна из тех дисциплин информационной безопасности, где интуиция «найти и закрыть всё» разбивается о математику. В типичной корпоративной инфраструктуре на тысячу хостов сканер вернёт десятки, а то и сотни тысяч находок. Команда, которая попробует обработать их линейно — по дате обнаружения или по убыванию CVSS, — гарантированно утонет: она потратит спринты на технически высокие, но практически неэксплуатируемые дефекты, пока единственная уязвимость на публичном периметре, уже включённая в каталог активно эксплуатируемых, останется незакрытой неделями. Эта статья — детальный разбор того, как устроен процесс VM целиком: от инвентаризации активов и таксономии (CVE/CWE/CPE/CVSS/EPSS/KEV) до многофакторной приоритизации (CVSS + EPSS + KEV + SSVC) и места, которое в этой системе занимает пентест. Материал рассчитан на инженеров SOC, AppSec и инфраструктуры — поэтому акцент на механизмах, числах и edge-cases, а не на лозунгах.

Масштаб проблемы: почему «пропатчить всё» — не стратегия

Начнём с цифр, потому что именно они объясняют, зачем вообще нужна приоритизация. Программа CVE (Common Vulnerabilities and Exposures), которую координирует MITRE, существует с 1999 года. За первое десятилетие в ней регистрировались тысячи записей в год; к концу 2010-х счёт пошёл на десятки тысяч ежегодно. К 2024 году поток достиг порядка 40 тысяч CVE в год — это около 100+ записей в день, более трёх тысяч в месяц, и он продолжает расти. Причины структурные: расширение программы CNA (CVE Numbering Authorities), при которой сотни вендоров и проектов сами присваивают идентификаторы; взрывной рост числа компонентов в современном ПО (один контейнерный образ легко тянет сотни транзитивных зависимостей); и развитие автоматизированного поиска дефектов (фаззинг, статический анализ).

Чтобы рост был не абстракцией, а проверяемой динамикой, приведём опорные точки по годам (порядок величины по данным NVD/CVE.org):

Кривая не просто растёт — она ускоряется: скачок 2024 года относительно 2023-го составил около трети, и это не разовый выброс, а следствие расширения экосистемы CNA и автоматизации поиска. Любая стратегия, неявно предполагающая, что «поток находок стабилен», устаревает быстрее, чем формулируется.

Теперь посмотрим на это глазами обороняющейся стороны. Производительность исправлений конечна: каждый патч нужно протестировать на совместимость, согласовать окно простоя, прогнать через change management, иногда — обновить зависимый софт по цепочке. Реальная пропускная способность команды эксплуатации измеряется десятками-сотнями исправлений в месяц на инфраструктуру, а входящий поток находок — тысячами. Дисбаланс между «находим» и «чиним» накапливается как технический долг, и без приоритизации он растёт монотонно. Арифметика безжалостна: если входит три тысячи новых CVE в месяц (и лишь часть из них релевантна вашему стеку), а команда закрывает, скажем, двести исправлений, то очередь не «разгребается интенсивнее» — она структурно не может быть обработана целиком, и единственный осмысленный вопрос — в каком порядке.

Критично понимать вторую асимметрию: не все уязвимости эксплуатируются, и эксплуатируются они крайне неравномерно. Эмпирические исследования (в частности, работы Cyentia Institute совместно с RAND и FIRST.org, на которых построена модель EPSS) показывают, что публичный эксплойт или наблюдаемые попытки эксплуатации существуют для меньшинства CVE — порядка нескольких процентов от общего числа. Иными словами, если вы исправляете уязвимости пропорционально их CVSS-баллу, вы тратите большую часть усилий на то, что злоумышленник никогда не тронет, и можете пропустить ту небольшую долю, которую он атакует прямо сейчас.

Отсюда главный тезис всей статьи: VM — это не задача «обнулить список», а задача управления риском в условиях дефицита ресурсов. Цель — не «ноль уязвимостей» (недостижимо и экономически бессмысленно), а «вовремя закрыты те уязвимости, которые реально повышают вероятность инцидента на ваших активах». Это требует процесса (повторяемого жизненного цикла), модели риска (не одного балла, а нескольких сигналов) и измеримых SLA. Всё остальное в статье — разворачивание этих трёх идей.

Таксономия: CVE, CWE, CPE, CVSS, EPSS, KEV

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

CVE (Common Vulnerabilities and Exposures) — это идентификатор конкретной уязвимости в конкретном продукте, вида CVE-2021-44228 (год + порядковый номер). CVE — не оценка и не описание механизма; это уникальный «инвентарный номер», по которому все системы могут ссылаться на одну и ту же проблему. Реестр координирует MITRE как primary CNA; программа спонсируется CISA. Идентификаторы выдают CNA — авторитеты-нумераторы (вендоры, координационные центры, баг-баунти-платформы), которых на сегодня сотни, и каждая отвечает за свой scope (например, продукты собственного вендора).

CWE (Common Weakness Enumeration) — это классификация типов слабостей, а не конкретных экземпляров. Например, CWE-79 (Cross-Site Scripting), CWE-89 (SQL Injection), CWE-787 (Out-of-bounds Write). Если CVE — «вот эта дыра в этом продукте», то CWE — «к какому классу дефектов она относится». CWE тоже ведёт MITRE. Связь: одной CVE обычно сопоставлен один или несколько CWE. Классы CWE образуют иерархию (от абстрактных «pillar» до конкретных «variant»), и именно по CWE строятся такие сводки, как ежегодный список наиболее опасных типов слабостей.

CPE (Common Platform Enumeration) — структурированный машиночитаемый идентификатор продукта/платформы/версии, вида cpe:2.3:a:apache:log4j:2.14.1:*:*:*:*:*:*:*. CPE отвечает на вопрос «к каким именно версиям какого продукта применима данная CVE». Это клей между вашим инвентарём активов и базой уязвимостей: матчинг установленного ПО на CPE — основа работы сканеров. Словарь CPE исторически ведёт NIST в рамках NVD. Слабое место CPE — неполнота и неоднозначность вендорских/продуктовых строк: если ваш актив не матчится на CPE точно, релевантная CVE может «проскользнуть» мимо. Поэтому современные подходы дополняют CPE покомпонентной идентификацией (PURL/SBOM) для приложений.

CVSS (Common Vulnerability Scoring System) — система числовой оценки серьёзности уязвимости (0.0-10.0). Её спецификацию ведёт FIRST.org. CVSS отвечает на вопрос «насколько технически тяжелы последствия и насколько легко это в принципе проэксплуатировать» — но не «атакуют ли это в реальности».

EPSS (Exploit Prediction Scoring System) — вероятностная модель (0-1), предсказывающая, что для данной CVE будут наблюдаться попытки эксплуатации в ближайшие 30 дней. Тоже ведёт FIRST.org (SIG EPSS). Это сигнал об угрозе, а не о тяжести.

KEV (Known Exploited Vulnerabilities) — каталог CISA, в который попадают CVE с подтверждённой эксплуатацией в реальных атаках. Это уже не предсказание, а факт.

Запомните логическую раскладку: CWE — «какого рода дефект», CVE — «какой конкретно», CPE — «в каком продукте», CVSS — «насколько тяжело», EPSS — «насколько вероятно, что атакуют», KEV — «атакуют ли уже». Эти шесть сущностей не конкурируют — они отвечают на разные вопросы, и грамотный VM использует их совместно. Типичный поток данных таков: сканер сопоставляет инвентарь (через CPE) с базой CVE, каждая CVE несёт CWE-классификацию и CVSS-вектор, поверх накладываются EPSS и KEV — и только эта совокупность превращается в приоритет.

Жизненный цикл самой уязвимости (disclosure lifecycle)

Чтобы понимать, почему время — критический фактор, нужно проследить путь уязвимости от обнаружения исследователем до массовой эксплуатации. Это отдельный процесс, не путать с жизненным циклом управления (о нём — следующий раздел).

1. Research / discovery. Исследователь (внутренний, независимый, баг-баунти-хантер или, увы, злоумышленник) находит дефект. На этом этапе о нём знают единицы.
2. Coordinated / responsible disclosure. Этичный путь — приватно уведомить вендора, дать ему время на исправление. Координацию часто берут на себя CERT/CC, национальные CERT или платформы. Существует стандарт ISO/IEC 29147 (vulnerability disclosure) и ISO/IEC 30111 (vulnerability handling processes), описывающие, как вендор должен принимать и обрабатывать отчёты. Типичный embargo — порядка 90 дней (классическая практика, популяризованная Google Project Zero), но это договорённость, а не закон.
3. Присвоение CVE. Уязвимости выдаётся идентификатор через CNA. Иногда это происходит до публикации патча (зарезервированный, «reserved» статус), иногда одновременно с раскрытием.
4. Патч вендора. Выходит исправление. С этого момента начинается гонка: дельту между «до» и «после» (бинарный диффинг) аналитики используют, чтобы реконструировать уязвимость и написать эксплойт.
5. Появление публичного эксплойта (PoC). В Exploit-DB, GitHub, Metasploit или в составе коммерческих наборов появляется рабочий код. С этого момента порог входа для атакующего падает почти до нуля.
6. Массовая эксплуатация. Уязвимость встраивается в сканеры массового заражения, ботнеты, программы-вымогатели. Атаки идут по всему адресному пространству Интернета.
7. Попадание в KEV. CISA фиксирует подтверждённую эксплуатацию и добавляет CVE в каталог с конкретной датой исправления для федеральных агентств.

Ключевые понятия здесь — окна риска. 0-day — уязвимость, для которой ещё нет патча вендора (либо она эксплуатируется до того, как вендор о ней узнал). Защититься от неё прямым исправлением нельзя — только компенсирующими мерами. n-day — уязвимость, для которой патч уже есть, но вы его ещё не применили; «n» — число дней с момента выхода исправления. Парадокс в том, что большинство реальных взломов происходит именно через n-day, а не через дорогие 0-day: атакующему дешевле эксплуатировать то, что админы не успели закрыть, чем разрабатывать новое.

Именно поэтому время критично. Промежуток между выходом патча (шаг 4) и появлением публичного эксплойта (шаг 5) для опасных уязвимостей нередко составляет считанные дни, а иногда — часы. Каждый день вашего «окна n-day» — это день, в течение которого порог атаки уже снижен, а вы ещё уязвимы. История с Log4Shell (CVE-2021-44228) в декабре 2021 — хрестоматийный пример: от публичного раскрытия (9-10 декабря 2021) до глобальной волны сканирования и эксплуатации прошли не недели, а часы, потому что уязвимость была тривиально эксплуатируема и затрагивала вездесущую библиотеку. Log4Shell к тому же эксплуатировался как 0-day ещё до публичного раскрытия (с начала декабря 2021), а после раскрытия мгновенно перешёл в фазу массовой n-day-эксплуатации — то есть один и тот же дефект побывал в обоих окнах риска подряд. Вывод для VM: скорость реакции на уязвимости с высоким сигналом угрозы важнее, чем полнота обработки всего списка.

Жизненный цикл управления уязвимостями: шесть этапов

Управление уязвимостями — это непрерывный цикл, а не разовая кампания. Канонически его раскладывают на шесть этапов: инвентаризация, обнаружение, приоритизация, устранение, проверка, метрики. Базовые принципы описаны в NIST SP 800-40 (Guide to Enterprise Patch Management Planning) и в требовании A.8.8 «Management of technical vulnerabilities» стандарта ISO/IEC 27001:2022. Разберём каждый этап с инструментами и метриками.

(а) Инвентаризация активов

Аксиома VM: нельзя защитить то, чего не видишь. Любая программа начинается с актуального инвентаря — CMDB (Configuration Management Database) или хотя бы поддерживаемого реестра активов. Сюда входят серверы, рабочие станции, сетевое оборудование, контейнеры, облачные ресурсы, мобильные устройства, и — отдельной строкой — shadow IT: ресурсы, поднятые в обход процессов (тестовый стенд на чьём-то облачном аккаунте, забытый поддомен, старый VPS).

Инструменты: пассивное и активное asset discovery (сканирование диапазонов, ARP/DNS-инвентаризация), интеграция с облачными API (AWS Config, Azure Resource Graph), агенты на хостах, CASB для SaaS. Для внешнего периметра отдельный класс — EASM (External Attack Surface Management): инструменты, непрерывно картирующие то, что видно из Интернета.

Критичный шаг — классификация критичности актива. У каждого актива должны быть атрибуты: владелец, бизнес-функция, уровень данных (содержит ли PII, секреты, платёжные данные), сетевая экспозиция (доступен ли извне), и tier критичности. Без этой классификации приоритизация невозможна: одна и та же CVE на изолированном тестовом хосте и на платёжном шлюзе несёт совершенно разный риск. На практике именно отсутствие или устаревание этих атрибутов — а не нехватка сканеров — становится узким местом: сканер выдаёт CVE на хосте, но без asset_value и exposure его невозможно корректно ранжировать.

Эвристика зрелости: если ваш сканер находит активы, которых нет в CMDB, — проблема не в сканере. Расхождение между «что просканировано» и «что числится» — само по себе метрика, и она должна стремиться к нулю.

(б) Обнаружение

Здесь работают сканеры и анализаторы. Важнейшее различие — authenticated vs unauthenticated сканирование. Неаутентифицированный (network) скан смотрит на хост «снаружи», как атакующий без доступа: видит открытые порты, баннеры, версии сервисов. Он быстрый, но даёт много догадок и пропускает всё, что не торчит в сеть. Аутентифицированный (credentialed) скан логинится на хост и читает реальные версии пакетов, конфигурацию, патч-уровень — он на порядок точнее и резко снижает ложные срабатывания, но требует управления учётными данными.

Второе различие — agent-based vs network-based. Агент на хосте даёт непрерывную видимость (важно для ноутбуков, которые не всегда в сети) и не нагружает сеть, но требует развёртывания и поддержки. Сетевое сканирование не требует агента, но видит только то, что доступно на момент скана.

Отдельные классы инструментов под разные поверхности:

• SCA (Software Composition Analysis) — анализ зависимостей приложения: какие версии библиотек используются и какие у них известные CVE. Базируется на разборе манифестов (package-lock.json, pom.xml, go.sum) и сверке с базами уязвимостей. Тесно связан с концепцией SBOM (Software Bill of Materials, формат CycloneDX или SPDX).
• Container / image scanning — проверка слоёв образа на уязвимые пакеты ОС и зависимости приложения (Trivy, Grype, Clair). Запускается в CI и в реестре.
• CSPM (Cloud Security Posture Management) — поиск не «дыр в коде», а опасных конфигураций облака: открытые S3-бакеты, чрезмерные IAM-права, незашифрованные тома.

Важная оговорка про ложные срабатывания (false positives) и их зеркало — false negatives. Неаутентифицированный скан может пометить хост уязвимым по баннеру, хотя вендор уже выпустил back-port исправления, не меняя строку версии (типично для RHEL/Debian — это так называемые back-ported security fixes). Обратная ошибка опаснее: false negative — уязвимость есть, но скан её не увидел (нет credential-доступа, нестандартный путь установки, новый CVE без сигнатуры). Поэтому findings из обнаружения — это сырьё, а не приговор; нормальный процесс включает дедупликацию, корреляцию и валидацию.

(в) Приоритизация

Сердце процесса — настолько важное, что ему посвящён отдельный большой раздел ниже. Коротко: на вход идёт поток находок, на выход — упорядоченный список того, что чинить в первую очередь, основанный не на одном балле, а на комбинации тяжести (CVSS), угрозы (EPSS, KEV) и контекста актива (экспозиция, критичность).

(г) Устранение

У устранения несколько форм, и патч — лишь одна из них:

• Patch management — установка официального исправления вендора. Предпочтительный путь.
• Обновление версии — переход на новую мажорную/минорную версию, где дефект уже исправлен (типично для зависимостей и контейнерных базовых образов).
• Переконфигурация — отключение уязвимого модуля, смена небезопасного параметра, ограничение прав. Иногда устраняет уязвимость без патча.
• Компенсирующие меры — то, что снижает эксплуатируемость без устранения корня: сегментация сети, ограничение доступа по IP, MFA, отключение наружу.
• Virtual patching / WAF — правило на уровне WAF/IPS, блокирующее эксплойт-паттерн. Покупает время, пока готовится настоящий патч; не заменяет его.
• Risk acceptance — осознанное решение не исправлять, зафиксированное владельцем риска с обоснованием и сроком пересмотра. Это легитимный исход, если стоимость исправления превышает риск, — но он должен быть задокументирован, а не возникать по умолчанию из-за бездействия.

(д) Проверка

Исправление без проверки — гипотеза. После remediation обязателен rescan: повторное сканирование, подтверждающее, что находка действительно закрыта (а не просто помечена «исправлено» в тикете). Сюда же — проверка на регресс: не сломал ли патч функциональность, не вернулась ли уязвимость после отката/переустановки. Закрытие тикета должно триггериться фактом rescan, а не словами исполнителя. Отдельная ловушка — эфемерные активы: контейнер пересоздаётся из образа, и если уязвимый базовый слой не пересобран, «закрытая» CVE возвращается при каждом деплое; здесь проверять нужно образ в реестре, а не работающий экземпляр.

(е) Метрики и отчётность

Без измерений нельзя управлять. Ключевые метрики:

• MTTD (Mean Time To Detect) — среднее время от появления уязвимости до её обнаружения у вас. Зависит от частоты сканирования и покрытия.
• MTTR (Mean Time To Remediate) — среднее время от обнаружения до устранения. Главная метрика эффективности; считается отдельно по уровням severity.
• Coverage — доля активов, реально охваченных сканированием (от инвентаря, не от «того, что просканировалось»).
• SLA по severity — целевые сроки устранения: например, KEV/critical — N дней, high — M, medium — K. SLA-compliance показывает, насколько процесс держит обещания.
• Risk burndown — динамика суммарного риска во времени: снижается ли «хвост» старых высокорисковых находок или только накапливается.

Разумная отправная точка для SLA — отталкиваться от обязательных сроков для активно эксплуатируемых уязвимостей (см. KEV/BOD 22-01 ниже) и ужесточать их для активов с внешней экспозицией. Полезно различать «средний» MTTR и MTTR по верхнему перцентилю: среднее легко «замыливается» массой быстро закрытых тривиальных находок, тогда как именно «хвост» (p90/p95) показывает, как долго реально живут трудные высокорисковые дефекты.

Оценка риска: почему один балл не работает

Это центральный раздел статьи. Распространённая ошибка — приравнять «CVSS-балл» к «риску». CVSS отвечает на вопрос «насколько тяжела уязвимость в принципе», но риск для вашей организации — это произведение тяжести на вероятность атаки и на контекст актива. Разберём четыре системы оценки, каждая из которых освещает свою грань, и покажем, как они дополняют друг друга.

CVSS детально

CVSS (текущие версии — 3.1 и 4.0) состоит из групп метрик:

• Base — неизменные характеристики самой уязвимости (тяжесть и «врождённая» эксплуатируемость). Именно этот балл публикуется в NVD и обычно подразумевается под «CVSS-баллом».
• Temporal (в v3.1; в v4.0 переименована в Threat) — характеристики, меняющиеся со временем: зрелость эксплойт-кода, доступность исправления.
• Environmental — корректировки под вашу среду: насколько критичны для вас конфиденциальность/целостность/доступность данного актива, есть ли смягчающие факторы.
• Supplemental (только в v4.0) — информативная группа, которая не влияет на числовой балл.

Base-метрики делятся на две подгруппы — Exploitability (как трудно атаковать) и Impact (что будет, если получится). Расшифровка base-метрик v3.1:

Из этих метрик по формуле получается число 0.0-10.0, которому сопоставлена качественная шкала: 0.0 — None, 0.1-3.9 — Low, 4.0-6.9 — Medium, 7.0-8.9 — High, 9.0-10.0 — Critical.

Различия v3.1 и v4.0 касаются именно структуры Base и появления новых групп:

• введена новая Base-метрика Attack Requirements (AT) — она отражает предусловия среды/конфигурации, отделённые от «сложности атаки» AC (в v3.1 они были смешаны);
• метрика Scope заменена раздельным учётом влияния на уязвимую систему (VC/VI/VA) и на последующую систему (SC/SI/SA) — вместо бинарного «Changed/Unchanged» теперь явно описывается, что происходит с каждой из двух систем по конфиденциальности, целостности, доступности;
• добавлена группа Supplemental-метрик (Automatable, Recovery, Safety, Value Density, Vulnerability Response Effort, Provider Urgency), которые дают полезный контекст, но не входят в расчёт числового балла. Safety дополнительно присутствует и в Environmental как Modified-метрика.

Важно не путать классы: единственная новая Base-метрика в v4.0 — это AT. Automatable, Recovery и Safety — это Supplemental, то есть информативные, а не влияющие на score.

Чтобы разница была наглядной «на руках», рассмотрим RCE с выходом за пределы компонента. В v3.1 такое влияние моделировалось одним переключателем Scope: Changed (плюс C/I/A=High) — и тонкость терялась: «Changed» лишь сигнализировал, что затронут другой контекст безопасности. В v4.0 та же ситуация раскладывается явно: высокий impact на уязвимую систему (VC/VI/VA = High) и отдельно — impact на последующую систему (SC/SI/SA), что позволяет различить «компрометирован только сам сервис» и «через сервис скомпрометирован хост/соседняя система». При этом, например, метка Safety из Supplemental ничего не прибавит к числу — она лишь подскажет триаж-команде, что у дефекта есть аспект безопасности людей.

Ключевой тезис: CVSS Base ≠ риск. Он измеряет тяжесть и теоретическую лёгкость эксплуатации, но ничего не говорит о том, существует ли эксплойт, атакуют ли это сейчас и важен ли затронутый актив. Использовать только Base для приоритизации — значит игнорировать две трети сигнала. Именно поэтому FIRST прямо рекомендует дополнять Base группами Threat и Environmental.

EPSS детально

EPSS закрывает ровно тот пробел, что оставляет CVSS: вероятность атаки. Это статистическая модель, поддерживаемая FIRST.org (её происхождение — работа SIG при участии Cyentia Institute и RAND), которая для каждой CVE выдаёт probability — оценку вероятности того, что в ближайшие 30 дней будут наблюдаться попытки эксплуатации этой уязвимости. Значение — число от 0 до 1.

Модель строится на машинном обучении поверх большого набора признаков: упоминания в источниках, наличие PoC/эксплойта в публичных репозиториях и Metasploit, свойства CVE (CWE, вендор), данные сенсоров о реально наблюдаемой эксплуатации. Скоры пересчитываются ежедневно — это принципиально: EPSS отражает текущую динамику угрозы, а не статичную картину.

Два числа, которые нельзя путать:

• probability — собственно вероятность (0-1).
• percentile — позиция данной CVE относительно всех остальных. Percentile 0.95 означает, что у этой CVE EPSS-вероятность выше, чем у 95% всех CVE.

Распределение EPSS сильно скошено: подавляющее большинство CVE имеют очень низкую вероятность (медиана значительно ниже 0.1), и лишь небольшой «хвост» имеет высокие значения. Практический вывод: порог нужно выбирать осознанно, увязывая его с пропускной способностью команды (десятки-сотни исправлений в месяц из раздела 1).

• Порог probability ≥ 0.1 оставляет порядка нескольких процентов всех CVE, но захватывает большинство реально эксплуатируемых — это разумная точка отсечения «шума» при разумном объёме работ.
• Повышение порога до 0.5 сокращает список в разы (остаётся уже доли процента CVE), резко снижая объём работ, но ценой роста пропусков (false negatives) — часть реально атакуемых уязвимостей имеет probability между 0.1 и 0.5.
• Многие команды комбинируют сигналы: «эскалировать, если EPSS ≥ 0.1 или percentile ≥ 0.95», чтобы не зависеть только от абсолютной вероятности.

Смысл в том, чтобы перестать тратить ресурсы на нижние перцентили, где вероятность атаки околонулевая, и при этом не задрать порог так высоко, что в работу не попадут уязвимости из «среднего» диапазона, которые тоже атакуются.

Пример строки из ежедневного EPSS-фида:
cve,epss,percentile
CVE-2021-44228,0.94380,0.99970   # Log4Shell: высокая вероятность, верхний перцентиль
CVE-2023-XXXXX,0.00042,0.07310   # типичная CVE: околонулевая вероятность, низкий перцентиль

EPSS не заменяет CVSS — он отвечает на другой вопрос. CVSS говорит «насколько будет больно», EPSS — «насколько вероятно, что ударят». Их нужно использовать вместе.

CISA KEV

Там, где EPSS предсказывает, KEV констатирует. Каталог Known Exploited Vulnerabilities, который ведёт CISA, содержит CVE с подтверждённой эксплуатацией в реальных атаках (включая задокументированные попытки). Критерий включения строгий и состоит из трёх условий: уязвимости назначен CVE-идентификатор; есть надёжное свидетельство активной эксплуатации в реальных атаках; существует чёткое действие по устранению (remediation), например патч или обходное решение. Это не «может эксплуатироваться» и не «есть PoC» — это «эксплуатируется по факту».

KEV неотделим от BOD 22-01 (Binding Operational Directive) — обязательной директивы CISA для федеральных гражданских агентств США. По ней агентства обязаны устранять уязвимости из KEV в установленные due dates (даты, привязанные к моменту добавления в каталог). Для частного сектора директива не обязательна юридически, но KEV де-факто стал отраслевым стандартом «что чинить вне очереди».

Практическое правило простое и жёсткое: если CVE в KEV — она идёт в работу немедленно, минуя обычную очередь приоритизации, при условии, что у вас есть затронутый актив. KEV — самый сильный из доступных сигналов, потому что он основан на наблюдаемой реальности, а не на оценке. Оборотная сторона — KEV неполон по построению: в него попадает только то, что CISA смогла подтвердить, поэтому «нет в KEV» не означает «не эксплуатируется». Именно поэтому KEV используют как форсирующий сигнал поверх EPSS/CVSS, а не вместо них.

SSVC

CVSS, EPSS и KEV дают числа и факты, но финальное решение «что делать» всё равно нужно принять. SSVC (Stakeholder-Specific Vulnerability Categorization), методология, разработанная CMU SEI и адаптированная CISA, предлагает альтернативу числовой шкале — дерево решений, выводящее не балл, а действие.

Кастомизированное дерево CISA формально оперирует пятью решающими точками (decision points):

• Exploitation — состояние эксплуатации: None / PoC / Active.
• Automatable — можно ли надёжно автоматизировать эксплуатацию в масштабе (Yes / No).
• Technical Impact — техническое воздействие (Partial / Total).
• Mission Prevalence — насколько затронутая система важна для миссии организации.
• Public Well-being Impact — влияние на благополучие и безопасность людей.

Две последние точки (Mission Prevalence и Public Well-being Impact) на финальном шаге сворачиваются в составную координату Mission & Well-being, поэтому в упрощённых изложениях дерево часто описывают четырьмя входами; по сути же решающих факторов пять.

На выходе — одна из категорий действия:

• Track — следить, можно не торопиться, устранять в плановом порядке.
• Track\* — следить внимательнее, могут быть нюансы.
• Attend — заняться в приоритетном порядке, привлечь ответственных.
• Act — действовать немедленно.

Ценность SSVC в том, что он явно встраивает ваш контекст (миссию, влияние на людей) в решение и выдаёт не абстрактный балл, который ещё надо интерпретировать, а конкретный вердикт. Это особенно полезно для организаций, которым трудно объяснить бизнесу, почему «9.8» иногда можно отложить, а «6.5» — нет.

Сравнительная таблица

Практическая приоритизация: модель и разобранный пример

Сведём теорию в работающую модель. Концептуально риск можно выразить как произведение четырёх факторов:

risk ≈ exploitability × exposure × asset_value × impact

где:

• exploitability — насколько вероятна/легка эксплуатация (сигнал из EPSS и KEV, частично из CVSS-Exploitability);
• exposure — сетевая доступность актива (Интернет / внутренняя сеть / изолированный сегмент);
• asset_value — бизнес-ценность актива и чувствительность данных (из инвентаря);
• impact — техническое воздействие (CVSS-Impact: C/I/A).

Это не точная формула, а ментальная модель: важно, что факторы перемножаются, а не складываются. Околонулевой множитель (например, изолированный сегмент или околонулевой EPSS) обнуляет произведение, как бы высоки ни были остальные. Поэтому уязвимость с CVSS 9.8 на изолированном dev-стенде без эксплойта в природе — низкий риск, а уязвимость с CVSS 6.5, но в KEV, на публичном API с платёжными данными — критический. Рассмотрим конкретный пример из пяти находок.

Наивная сортировка по CVSS дала бы порядок A → D → C → B → E. Это почти инверсия правильного. Применим логику решения:

def priority(f):
    if f.in_kev:                       # факт эксплуатации перевешивает всё
        return "P1-немедленно"
    if f.exposure == "internet" and f.epss >= 0.10:
        return "P1-немедленно"         # доступно извне и вероятно атакуют
    if f.cvss >= 9.0 and f.asset_value == "high":
        return "P2-срочно"
    if f.exposure == "internet" and f.cvss >= 7.0:
        return "P2-срочно"
    if f.epss < 0.01 and f.exposure == "isolated":
        return "P4-плановое"           # шум: околонулевая угроза, нет доступа
    return "P3-обычная очередь"

Прогон даёт:

• CVE-B → P1. В KEV, на публичном API с платёжными данными, EPSS 0.91. Несмотря на «всего лишь» Medium по CVSS — это безусловный приоритет №1. Здесь видно, почему CVSS вводит в заблуждение.
• CVE-C → P1. Интернет-экспозиция, EPSS 0.45 (выше порога 0.10) — попадает в P1 по правилу «интернет + EPSS ≥ 0.10». Реальная угроза.
• CVE-D → P2. Critical и высокоценная БД, но внутренняя сеть и низкий EPSS (0.08) — срочно, но не «бросай всё».
• CVE-A → P3. Несмотря на 9.8 — dev-стенд, нет эксплуатации, внутренняя сеть. Обычная очередь.
• CVE-E → P4. Околонулевой EPSS, изолированный сегмент, Medium — плановое устранение или кандидат на risk acceptance.

Итоговый порядок работ: B → C → D → A → E — то есть почти противоположный наивной сортировке по баллу. Это и есть практический смысл многофакторной приоритизации: вы тратите дефицитные ресурсы там, где произведение «вероятность × доступность × ценность × воздействие» максимально, а не там, где просто большое число в одной колонке. Обратите внимание, что псевдокод детерминирован и легко аудируется — для любого тикета можно показать, какое именно правило присвоило приоритет, что критично для разговора с владельцами активов и аудиторами.

Где пентест и чем он отличается от сканера

Сканер и пентест часто путают или считают взаимозаменяемыми — это серьёзная ошибка. Сканер отвечает на вопрос «какие известные уязвимости присутствуют» — широко, автоматически, по сигнатурам. Пентест отвечает на вопрос «что реально может сделать атакующий» — глубоко, с человеческим интеллектом, включая бизнес-логику, цепочки и неочевидные комбинации. Это разные инструменты с разной ролью в программе.

Типы пентестов по уровню знаний о цели:

• Black-box — тестировщик не знает ничего, кроме точки входа (имитация внешнего злоумышленника). Реалистично, но дорого по времени.
• Grey-box — частичные знания: учётные данные обычного пользователя, схема, документация. Оптимальный баланс глубины и стоимости.
• White-box — полный доступ к коду, архитектуре, конфигурации. Максимальное покрытие, ближе к аудиту.

Методологии и стандарты (называть их в отчёте — признак зрелости):

• PTES (Penetration Testing Execution Standard) — сквозной процесс от pre-engagement до отчёта.
• OWASP WSTG (Web Security Testing Guide) — детальная методология для веб-приложений.
• NIST SP 800-115 (Technical Guide to Information Security Testing and Assessment) — методический фундамент тестирования.
• OSSTMM (Open Source Security Testing Methodology Manual) — измеримый подход к оценке операционной безопасности.

Классические этапы пентеста:

1. Recon (разведка) — сбор информации о цели: OSINT, перечисление поддоменов, идентификация технологий.
2. Scanning / enumeration — активное картирование: порты, сервисы, версии, точки входа.
3. Exploitation — собственно эксплуатация найденных уязвимостей для получения доступа.
4. Post-exploitation — что можно сделать после прорыва: повышение привилегий, латеральное движение, доступ к данным, закрепление.
5. Reporting — структурированный отчёт: находки, доказательства (PoC), оценка риска, рекомендации.

Главное, что даёт пентест и не даёт сканер, — chaining (построение цепочек). Сканер оценивает каждую находку изолированно; человек видит, как несколько низких по отдельности дефектов складываются в критический сценарий. Пример kill chain:

1. Self-XSS (Low)            — XSS, эксплуатируемый только на себя; сканер: "низкий риск".
2. CSRF на смену профиля     — нет анти-CSRF токена на форме редактирования профиля.
3. Отсутствие rate-limit     — на endpoint, упрощает доставку и перебор.
4. IDOR в профиле (Medium)   — можно читать чужой userId.
 
Цепочка:
CSRF записывает XSS-payload в поле профиля атакуемого пользователя →
это поле отображается в админ-панели без экранирования (stored, не self) →
админ открывает запись, payload крадёт его сессию →
через IDOR доступ к данным любого пользователя → массовый захват аккаунтов.
 
Итог: четыре Low/Medium находки = критический сценарий (захват аккаунтов).

Разберём ключевой шаг подробнее, потому что именно он превращает «безобидный» Self-XSS в критический stored-XSS. Self-XSS сам по себе бесполезен: жертва должна сама вставить payload себе. Но если на форме редактирования профиля нет анти-CSRF-токена, атакующий с помощью CSRF-запроса записывает XSS-payload в поле профиля жертвы от её имени. Дальше работает разница в контексте отображения: это поле профиля рендерится в админ-интерфейсе (например, в списке пользователей или карточке) без должного экранирования — то есть payload становится stored, а не self. Когда администратор открывает эту запись, скрипт исполняется уже в его сессии и крадёт её. Связка с IDOR довершает дело: с правами/сессией админа атакующий через прямой доступ к чужим userId выгребает данные всех пользователей. Ни один из этих шагов по отдельности не вызвал бы тревоги в отчёте сканера — критичен именно их порядок и сочетание.

Именно поэтому пентест незаменим: он измеряет не наличие дефектов, а реализуемость атаки — то, что в конечном счёте и определяет риск.

Зрелость и слои контроля

VM и пентест — не конкуренты, а соседние слои одной программы. Зрелая практика выстраивает их как эшелонированную систему, где каждый слой закрывает слепые зоны предыдущего:

• Vulnerability Management — непрерывный широкий контроль: находит и приоритизирует известные уязвимости на всём парке активов. Основа, работает постоянно.
• Пентест — периодическая глубокая проверка: подтверждает реальную эксплуатируемость, находит то, что сканер не видит (логика, цепочки), даёт «честный» взгляд на конкретный scope.
• Red team — имитация реального противника с конкретной целью (доступ к данным, домен) и без предупреждения «синих». Проверяет не только наличие дыр, но и способность обнаружить и среагировать. Это тест людей и процессов, а не только техники.
• Bug bounty — непрерывный краудсорсинг внешних исследователей. Масштабирует поиск за счёт множества независимых глаз и платит за результат, а не за время.
• Threat Intelligence — контекст угроз: какие уязвимости и техники используют актуальные для вашей отрасли группировки. Питает приоритизацию (фактически усиливает сигнал EPSS/KEV вашей спецификой) и хорошо ложится на матрицу MITRE ATT&CK для описания техник противника.

Модель зрелости программы обычно описывают как движение от реактивности к управлению риском:

1. Реактивный — чиним то, что взломали или что прислал аудит. Нет инвентаря, нет SLA.
2. Сканирование — есть регулярные сканы, но приоритизация по голому CVSS, нет учёта актива.
3. Процессный — есть жизненный цикл, SLA по severity, метрики MTTR/coverage.
4. Risk-based — приоритизация по комбинации CVSS + EPSS + KEV + контекст актива (как в этой статье); пентест и TI встроены в процесс.
5. Оптимизируемый — непрерывная обратная связь, автоматизация remediation, red team валидирует устойчивость, метрики управляют решениями.

Движение по этой лестнице — не покупка нового инструмента, а взросление процесса. Большинство организаций «застревают» на уровне 2-3 именно из-за того, что приоритизируют по одному баллу. Характерный признак перехода с уровня 2 на 3 — появление SLA, привязанного к severity; с 3 на 4 — момент, когда KEV и EPSS начинают переопределять порядок работ, ранее заданный голым CVSS.

Частые ошибки

1. Приоритизация по голому CVSS Base. Самая дорогая ошибка: команда годами чинит «девятки» без эксплойтов, пропуская эксплуатируемые «шестёрки». CVSS Base — это про тяжесть, а не про риск. Лечится добавлением EPSS, KEV и контекста актива. Конкретный симптом: в бэклоге сверху висят Critical на внутренних стендах, а KEV-уязвимость на публичном сервисе ждёт своей очереди.

1. Игнорирование инвентаря. Если 20% активов не сканируются (shadow IT, забытые поддомены, теневые облачные аккаунты), то любая статистика по уязвимостям описывает только видимую часть. Атакующий же ищет именно невидимую. Coverage от инвентаря, а не от «того, что просканировалось», — обязательная метрика.

1. Неаутентифицированные сканы как основной метод. Они дают много ложных срабатываний (по баннерам) и пропускают всё, что не торчит наружу. Без credentialed-сканов вы не знаете реального патч-уровня хостов, а из-за back-ported fixes ещё и видите фантомные «уязвимости» там, где их уже нет.

1. Сканер вместо пентеста (и наоборот). Считать, что прогон сканера = «нас проверили», — иллюзия: сканер не видит бизнес-логику и цепочки. Обратная ошибка — раз в год заказать пентест и не вести непрерывный VM: между пентестами накапливаются n-day, которые и эксплуатируют.

1. Закрытие тикета без rescan. «Исправлено» в трекере ≠ «исправлено» на хосте. Без подтверждающего повторного скана метрики MTTR врут, а часть «закрытых» уязвимостей живёт дальше (откатили патч, пересоздали хост из старого образа).

1. Risk acceptance по умолчанию (молчаливое). Когда уязвимость «висит» месяцами без решения — это де-факто принятие риска, но без владельца, обоснования и срока пересмотра. Легитимный risk acceptance оформляется явно; молчаливый — это просто незакрытая дыра, прикрытая бюрократией.

1. Отсутствие SLA по severity. Без целевых сроков устранения процесс не имеет «давления времени»: всё чинится «когда дойдут руки». SLA, привязанный к severity и экспозиции (а для KEV — к due date CISA), превращает намерение в обязательство.

1. Слепое доверие к одному источнику данных об уязвимостях. Опора только на NVD/CVSS без учёта статуса CNA, задержек обогащения и альтернативных фидов приводит к слепым зонам: уязвимость уже эксплуатируется, а ваш единственный источник ещё не обновил запись. Зрелый процесс кросс-сверяет несколько фидов (вендорские бюллетени, KEV, EPSS, TI).

Чек-лист внедрения и что почитать

Минимальный набор шагов для запуска или аудита программы VM:

• Поддерживается актуальный инвентарь активов (CMDB) с атрибутами критичности, владельца и экспозиции.
• Coverage сканирования измеряется от инвентаря и стремится к 100%; расхождение «скан vs CMDB» отслеживается.
• Используются authenticated/credentialed сканы для серверов; SCA для зависимостей; image scanning в CI; CSPM для облака.
• Приоритизация многофакторная: CVSS + EPSS + KEV + контекст актива (а не один балл).
• KEV-уязвимости с затронутыми активами идут вне очереди, по SLA не хуже BOD 22-01.
• Заданы SLA по severity и экспозиции; считаются MTTR, MTTD, coverage, SLA-compliance, risk burndown.
• Каждое устранение подтверждается rescan; risk acceptance оформляется явно, с владельцем и датой пересмотра.
• VM дополнен периодическим пентестом (с методологией в отчёте) и, по зрелости, red team / bug bounty / threat intelligence.

Что почитать (первоисточники, а не пересказы):

• NIST SP 800-40 — Guide to Enterprise Patch Management Planning.
• NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment.
• ISO/IEC 27001:2022, Annex A.8.8 — Management of technical vulnerabilities (и сопутствующий ISO/IEC 27002).
• ISO/IEC 29147 / 30111 — vulnerability disclosure и handling.
• FIRST.org — спецификации CVSS v3.1 / v4.0 и документация EPSS.
• CISA — каталог KEV, директива BOD 22-01, материалы по SSVC; CMU SEI — методология SSVC.
• OWASP WSTG и PTES — методологии тестирования.

Заключение

Управление уязвимостями — это не гонка за нулём в дашборде, а дисциплина управления риском в условиях, когда находок всегда больше, чем рук. Работающая программа стоит на трёх опорах: повторяемом жизненном цикле (инвентаризация → обнаружение → приоритизация → устранение → проверка → метрики), многофакторной приоритизации (CVSS говорит о тяжести, EPSS — о вероятности атаки, KEV — о факте эксплуатации, SSVC — о действии, и только вместе они дают риск) и осознанном разделении ролей между сканером (широта) и пентестом (глубина и цепочки). Команда, которая усвоит, что «9.8 на изолированном стенде» бывает менее срочной, чем «6.5 в KEV на публичном API», уже опережает большинство.

Лучший способ почувствовать разницу между «находкой сканера» и «реальной эксплуатацией» — собрать цепочку руками. Это можно отработать во вводном курсе по периметровому пентесту на стендах прямо в браузере: разведка, перечисление, эксплуатация и построение kill chain из нескольких low-severity находок — ровно тот навык, который и отличает приоритизацию по риску от приоритизации по баллу.