Управление уязвимостями: что это такое и как работает на практике

Что такое управление уязвимостями и почему это не просто «сканирование»

В большинстве компаний «управление уязвимостями» выглядит примерно так: раз в квартал запускают сканер, получают отчёт на 3 000 строк, пересылают его команде разработки и ждут. Разработчики чинят то, что успевают или что выглядит страшнее всего по CVSS. Через три месяца процесс повторяется — и картина почти не меняется. Это не vulnerability management. Это периодическое сканирование, замаскированное под управление рисками.

Vulnerability Management (VM) — это структурированный и непрерывный процесс: обнаружить все активы, выявить их уязвимости, оценить реальный риск для бизнеса, передать ответственным командам с конкретным SLA, проконтролировать исправление и зафиксировать результат в метриках. Ключевое слово здесь — «непрерывный». Не разовый. Не квартальный. Каждый день публикуются новые CVE, каждый день меняется инфраструктура, каждый день атакующие ищут точки входа — и процесс управления уязвимостями должен работать с той же скоростью.

Чем VM отличается от сканирования и пентеста

Три понятия, которые часто путают — и это дорого обходится. Vulnerability scanning — автоматическая проверка хостов и приложений на наличие известных уязвимостей. Сканер сравнивает версии ПО с базой CVE и выдаёт список потенциальных проблем. Это один инструмент одного из этапов VM, но не VM сам по себе. Penetration testing — ручная проверка конкретных систем с реальной попыткой эксплуатации уязвимостей. Пентест отвечает на вопрос «можно ли реально взломать вот это?», но не масштабируется на тысячи активов и не работает непрерывно. VM — это процесс, который связывает оба инструмента в систему управления рисками: регулярное сканирование, контекстная приоритизация, тикеты с SLA, ремедиация, верификация, отчётность руководству.

Почему VM — это непрерывный процесс

Ежедневно NVD публикует в среднем 50–70 новых CVE. Инфраструктура предприятия меняется не менее активно: DevOps-команды разворачивают новые сервисы, облачные ресурсы создаются по запросу, подрядчики подключают свои системы. Конфигурации дрейфуют. Зависимости обновляются. Результат: снимок состояния безопасности, сделанный месяц назад, уже не отражает реальности. Только цикличный и автоматизированный процесс — от инвентаризации до верификации — даёт актуальную картину рисков.

Пять этапов управления уязвимостями: полный lifecycle

VM-программа строится из пяти последовательных этапов, которые повторяются непрерывно. На каждом этапе — свои входные данные, инструменты и результат. Пропустить один этап означает сломать всю цепочку: блестяще настроенный сканер бесполезен без полного инвентаря, а точная приоритизация не даст результата без выстроенного процесса ремедиации.

Этап 1: инвентаризация активов

Нельзя защитить то, о чём не знаешь — и нельзя просканировать то, чего нет в списке. Инвентаризация активов — фундамент VM. Задача: получить полный и актуальный реестр всего, что есть в инфраструктуре. Сюда входят физические серверы, виртуальные машины, контейнеры и Kubernetes-кластеры, облачные ресурсы (AWS EC2, Azure VM, GCP), рабочие станции, сетевые устройства, веб-приложения и API, сторонние SaaS-платформы. Инструменты сбора: CMDB-системы (ServiceNow, Jira Service Management), агенты на хостах (Tenable.io, Qualys Cloud Agent), облачные API (AWS Config, Azure Resource Graph), пассивное обнаружение через сетевой трафик. Качество инвентаризации напрямую определяет качество всей VM-программы: «слепые зоны» инвентаря — это неуправляемые риски.

Этап 2: выявление уязвимостей

После инвентаризации каждый актив «просвечивается» на предмет известных уязвимостей. Основной метод — автоматическое сканирование: инструмент сопоставляет версии ОС, ПО и библиотек с базами данных CVE (NVD, CISA KEV, вендорские бюллетени). Сканирование бывает двух типов: credentialed (с учётными данными — глубокое, видит установленные пакеты и конфигурации) и uncredentialed (без авторизации — поверхностное, видит только открытые сервисы и баннеры). Дополнительно применяют DAST для веб-приложений, SCA для анализа open-source зависимостей, ручной аудит конфигураций для сетевых устройств. Результат этапа — сырой список уязвимостей с CVE-идентификаторами, затронутыми активами и первичными оценками.

Этап 3: приоритизация и оценка рисков

Это самый интеллектуально насыщенный этап VM — и именно здесь большинство программ дают сбой. Сырой список из 10 000 CVE не помогает принимать решения, он парализует. Задача приоритизации — выбрать те 50–100 уязвимостей, которые требуют немедленного внимания, и распределить остальные по срокам. Современная приоритизация учитывает: CVSS-балл (базовая тяжесть), EPSS (вероятность эксплуатации), наличие в CISA KEV (подтверждённая эксплуатация), критичность затронутого актива (прод vs дев, наличие клиентских данных), барьеры доступа (есть ли WAF, сегментация, MFA), blast radius (насколько компрометация актива влияет на остальную инфраструктуру). На выходе — тикеты с приоритетами P1/P2/P3 и SLA на исправление.

Этап 4: устранение и ремедиация

Приоритизированные уязвимости передаются командам-владельцам через ITSM: Jira, ServiceNow. Каждый тикет содержит конкретную рекомендацию: установить патч такой-то версии, изменить конфигурацию, закрыть порт, обновить зависимость. Для массового патчинга используют инструменты автоматизации: Ansible, Puppet, Chef, Intune, WSUS. Когда быстрое устранение невозможно — применяют compensating controls: правила WAF, IP-ограничения, отключение уязвимого сервиса, дополнительный мониторинг. Важно: compensating control — это временная мера, а не закрытие тикета. Срок действия таких мер должен быть зафиксирован и контролироваться.

Этап 5: верификация и отчётность

Слово «исправлено» в тикете не закрывает уязвимость — закрывает повторное сканирование, подтвердившее факт устранения. Верификация критична: без неё патчи объявляются применёнными, но реально не применяются, откат конфигурации возвращает уязвимость, а новые уязвимости появляются ровно там, где только что починили. После верификации данные агрегируются в отчётность: MTTR по классам, % уязвимостей закрытых в SLA, тренды по времени, соответствие требованиям стандартов. Эти метрики — язык общения с CISO и советом директоров.

CVSS, EPSS и KEV: три метрики, которые изменили приоритизацию

Ещё несколько лет назад приоритизация выглядела просто: сортируешь по CVSS сверху вниз и чинишь с Critical. Сегодня так не работает — и вот почему. CVSS 9.8 на уязвимости в Windows RDP не значит ничего, если в вашей компании RDP закрыт на периметре и доступен только через VPN. CVSS 7.2 на уязвимость в web-сервере без патча, активно эксплуатируемую ransomware-группировками прямо сейчас, — это P1, который нельзя откладывать ни на день. Контекст решает всё.

CVSS: классика и её ограничения

Common Vulnerability Scoring System — открытый стандарт оценки тяжести уязвимостей, поддерживаемый FIRST.org. Версия 3.1 и актуальная 4.0 оценивают уязвимость по трём группам метрик: базовые (вектор атаки, сложность, необходимые привилегии, взаимодействие пользователя, влияние на CIA), темпоральные (наличие эксплойта, уровень патча) и контекстные (применимые вручную модификаторы для конкретной среды). Итоговый балл: 0–3.9 Low, 4.0–6.9 Medium, 7.0–8.9 High, 9.0–10.0 Critical. Главное ограничение CVSS — он описывает уязвимость в вакууме, без учёта того, эксплуатируется ли она в реальных атаках. CVE с максимальным баллом может годами не использоваться атакующими, а CVE с баллом 6.5 — войти в арсенал активных ransomware-кампаний на следующей неделе.

EPSS: вероятность эксплуатации

Exploit Prediction Scoring System (EPSS) разработан FIRST.org и обновляется ежедневно. На основе машинного обучения модель анализирует атрибуты CVE, данные об активных атаках, публикации эксплойтов, активность в даркнете и предсказывает вероятность эксплуатации в ближайшие 30 дней — в виде числа от 0 до 1 (или 0% до 100%). Исследования показывают: лишь около 5% всех CVE имеют EPSS выше 0.1%. Это означает, что сосредоточившись на CVE с EPSS > 1%, команда VM обрабатывает приоритетную группу риска, игнорируя 95% шума. EPSS не заменяет CVSS — он его дополняет, добавляя измерение реальной угрозы.

CISA KEV: эксплуатируется прямо сейчас

Known Exploited Vulnerabilities Catalog — каталог CISA (агентство кибербезопасности США), который публикует CVE с подтверждённой эксплуатацией в реальных атаках. Это не «вероятность» и не «теория» — это факт активного использования. Каталог содержит более 1 200 CVE (на начало 2026 года) и регулярно пополняется. Для государственных организаций США внесение CVE в KEV обязывает к устранению в установленные сроки. Для всех остальных KEV — однозначный сигнал P1: если ваш актив затронут CVE из KEV и он доступен из интернета — это экстренная задача. Интеграция KEV в VM-платформу позволяет автоматически повышать приоритет таких уязвимостей.

Инструменты VM: что используют специалисты в 2026 году

Рынок VM-инструментов разнообразен — от бесплатных open-source сканеров до полноценных enterprise-платформ управления уязвимостями и экспозицией. Выбор инструмента зависит от размера инфраструктуры, зрелости команды и бюджета. Важно понимать: ни один инструмент не заменяет процесс. Даже самая дорогая VM-платформа без выстроенного workflow ремедиации и актуальной инвентаризации не даст результата.

Tenable Nessus / Tenable.io — один из самых распространённых коммерческих сканеров. Nessus Pro — для самостоятельного развёртывания, Tenable.io — облачная платформа с агентами, коннекторами к облакам и встроенной приоритизацией по CVSS и VPR (Vulnerability Priority Rating). Сильные стороны: широкая база плагинов, глубокое credentialed-сканирование, интеграция с ServiceNow и Splunk. Qualys VMDR — облачная платформа с акцентом на автоматизации всего цикла VM: обнаружение, оценка, приоритизация, оркестрация патчей. Встроенная интеграция с CISA KEV и EPSS, агенты для всех основных ОС. Rapid7 InsightVM — выделяется живыми дашбордами риска и глубокой интеграцией с InsightIDR (SIEM) и InsightConnect (SOAR). Microsoft Defender Vulnerability Management — нативное решение для Microsoft-сред: интегрировано с Defender for Endpoint, покрывает Windows, Linux, macOS, Android, iOS без дополнительных агентов.

Для тех, кто только начинает или работает в небольших командах, open-source решения остаются полноценной альтернативой. OpenVAS / Greenbone — полноценный сканер уязвимостей с открытым кодом, поддерживающий credentialed-сканирование и широкую базу NVTs (Network Vulnerability Tests). Nuclei от ProjectDiscovery — шаблонный сканер, незаменимый для веб-приложений и API: тысячи готовых шаблонов покрывают CVE, misconfig и exposed panels. Trivy — стандарт де-факто для сканирования контейнеров и IaC: находит уязвимости в Docker-образах, Kubernetes-манифестах, Terraform-конфигурациях и файлах зависимостей.

Как внедрить VM в компании с нуля

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

Шаг 1 — определите скоуп и найдите спонсора. VM затрагивает ИТ, разработку и ИБ одновременно. Без поддержки на уровне CISO или CTO команда ИБ будет бесконечно «просить» ИТ ставить патчи — без реального SLA и ответственности. Зафиксируйте, какие активы входят в скоуп первой итерации: internet-facing активы — приоритет. Шаг 2 — проведите инвентаризацию. До первого сканирования составьте реестр активов: хотя бы IP-диапазоны и критичные системы. Это сразу покажет пробелы. Шаг 3 — запустите первое credentialed-сканирование. Результат первого скана почти всегда шокирует. Тысячи уязвимостей, среди которых нужно найти реально критичные. Именно здесь пригодятся CVSS + EPSS + KEV. Шаг 4 — выстройте процесс ремедиации. Создайте шаблоны тикетов в ITSM с SLA: P1 — 72 часа, P2 — 30 дней, P3 — 90 дней. Назначьте владельцев для каждой группы активов. Шаг 5 — автоматизируйте постепенно. Начните с ручного процесса, потом добавляйте автоматическое создание тикетов, интеграции с SOAR, автоматический патчинг для некритичных систем.

KPI и метрики эффективности VM-программы

Метрики — это язык VM для руководства. Без них VM-программа невидима для бизнеса, а значит, не получает ресурсов и внимания. Ключевые метрики: MTTR (Mean Time to Remediation) — среднее время от обнаружения до устранения, в разбивке по P1/P2/P3; % уязвимостей, закрытых в SLA — показывает дисциплину процесса; Exposure Window — среднее время жизни критичной уязвимости в инфраструктуре; KEV Coverage — % активов, проверенных на наличие KEV-уязвимостей; Scan Coverage — доля инфраструктуры, покрытой сканированием; Recurrence Rate — доля уязвимостей, которые появляются повторно после исправления (признак проблем с конфигурационным управлением). Эти метрики отображают не только техническое состояние, но и зрелость процесса — именно их ждут от VM-программы на уровне совета директоров.