Процесс управления уязвимостями: как выстроить его на практике

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

Это условный сценарий, а не пересказ реального инцидента. Но каждая его деталь узнаваема: закрытая заявка вместо подтверждённого исправления, актив без владельца, сканер, который добросовестно проверяет только то, что ему показали. У такой организации может быть дорогая платформа, еженедельные отчёты и даже регулярный пентест — и при этом не быть процесса управления уязвимостями. Есть набор действий, которые иногда пересекаются.

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

Почему сканер ещё не процесс

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

Хорошее напоминание об этом есть в самом NIST SP 800-115 (2008). Документ прямо называет себя обзором ключевых элементов технического тестирования и оценки безопасности, а не полноценной программой тестирования. Он описывает фазы отдельной оценки — планирование, выполнение и работу после выполнения, — но не берётся за то, как организация живёт с результатами между оценками. Эта часть — владение, приоритизация, исключения, контроль закрытия — и есть процесс, который приходится строить самостоятельно.

Что входит в область охвата

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

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

Практический цикл

На практике удобно мыслить пятью связанными шагами. Это авторская рабочая схема, а не формальная модель из какого-либо стандарта: фазы SP 800-115 описывают одну оценку, а этот цикл — то, как результаты разных оценок превращаются в решения и изменения.

1. Инвентаризация и владельцыКаждый актив в области охвата имеет владельца, класс критичности и отметку о доступности извне. Без этого любые находки висят в воздухе.
2. ОценкаСканирование, тестирование и анализ подбираются под класс актива. Методика и её версия фиксируются, чтобы результаты можно было сравнивать во времени.
3. ПриоритизацияТехническая критичность сочетается со свидетельствами эксплуатации, бизнес-критичностью и экспозицией актива. Ранги пересчитываются при изменении входных данных.
4. Устранение или решениеИсправление, компенсирующая мера, ограниченное по времени принятие риска либо документированное закрытие как ложного срабатывания, неприменимого случая или выведенного актива.
5. Повторная проверка и разбор причинИсходный сценарий повторяют и при необходимости дополняют релевантными вариантами или эквивалентной проверкой с описанными ограничениями. Повторяющиеся классы слабостей уходят в стандарты разработки и эксплуатации.

Управление и роли: кто владеет циклом

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

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

NIST Cybersecurity Framework 2.0 удобен как опора при написании такой политики. NIST позиционирует CSF 2.0 как инструмент, который помогает организациям понимать киберриски и совершенствовать управление ими. В нём есть профили для описания текущего и целевого состояния, краткие руководства для типовых задач и информативные ссылки, связывающие фреймворк с другими ресурсами NIST. Управление уязвимостями стоит вести так же: как риск-процесс с решениями и владельцами, а не как генератор отчётов.

Роли, без которых цикл разваливается

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

В небольшой компании несколько ролей может совмещать один человек. Если независимый проверяющий несоразмерен риску или недоступен, самопроверку дополняют воспроизводимыми доказательствами, утверждением владельца риска или коллегиальным ревью. Закрывать собственную заявку без какой-либо проверки нельзя.

Авторизация тестирования

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

Практическая тонкость: разрешение должно исходить от каждой стороны, которая вправе одобрять тестирование затронутых активов и сред. Облачный провайдер, хостинг, подрядчик, который сопровождает систему, владелец SaaS-сервиса — у каждого могут быть свои правила. Согласие ИТ-директора не распространяется автоматически на инфраструктуру, которой организация не владеет.

Инвентаризация и обнаружение: нельзя защитить то, о чём не знаешь

Основа процесса — инвентаризация активов с назначенными владельцами. Не таблица, которую заполнили при внедрении платформы, а регулярно сверяемый список: что есть, кому принадлежит, насколько критично для бизнеса, доступно ли из интернета. Сверка — ключевое слово. Источников правды обычно несколько: CMDB, облачные консоли, DNS, реестры сертификатов, данные сетевого оборудования. Расхождения между ними и есть кандидаты во «второй шлюз».

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

Сканирование, тестирование и анализ — разные инструменты

SP 800-115 даёт практические рекомендации по проектированию, проведению и сопровождению технического тестирования. Его ценность для процесса в том, что он описывает преимущества и ограничения разных техник: сканирования уязвимостей, тестирования на проникновение, анализа и ревью. Это помогает подобрать технику и периодичность под класс актива, а не прогонять всё одним сканером с одной частотой.

Например, для парка рабочих станций автоматическая проверка версий и конфигураций может дать повторяемый охват и выявлять отставание от обновлений. Для публичного API с платёжной логикой одного сканера недостаточно для проверки авторизации и бизнес-логики; здесь может потребоваться ручное тестирование, привязанное к значимым релизам. Для стабильной внутренней системы период глубокой оценки выбирают по риску, изменениям и обязательствам. Выбор — компромисс между стоимостью, частотой и глубиной, и его стоит записать в политику по классам активов.

Веб-приложения и API: версионированная методика

Для веб-приложений и API OWASP Web Security Testing Guide остаётся одним из основных публичных руководств по тестированию. На момент подготовки исходного материала стабильной считалась версия 4.2, а 5.0 находилась в разработке; перед тем как вписывать номер в договор, стоит проверить текущий статус. Сама идея важнее номера: если закрепить точную версию методики в планах тестирования, договорах и отчётах, результаты разных лет можно сравнивать между собой.

OWASP ASVS закрывает сторону требований. Стандарт задаёт проверяемые требования к безопасности приложения и основу для тестирования технических мер защиты. В ASVS 5.0.0 рекомендуется ссылаться на требования с указанием версии, например v5.0.0-1.2.5, поскольку нумерация между версиями может меняться. Списки требований публикуются в машиночитаемых форматах, в том числе CSV и JSON. Их можно импортировать в систему заявок или управления уязвимостями и привязывать каждую находку к конкретному требованию. Тогда «уязвимость в форме входа» превращается в проверяемое утверждение: такое-то требование такой-то версии не выполнено.

Конфигурационный дрейф

Слабостям конфигурации нужна лёгкая, но непрерывная проверка. MDN описывает браузерные механизмы безопасности, и у каждого из них есть своя граница ответственности, которую полезно понимать при разборе находок. Content Security Policy ограничивает, откуда странице разрешено загружать скрипты и другие ресурсы. CORS определяет, может ли скрипт в браузере прочитать ответ с другого источника, — это не авторизация на сервере, и разрешительная CORS-политика не заменяет проверку прав. Cross-Origin Resource Policy позволяет не отдавать тело некоторых no-cors-ответов чужим источникам, но не обязательно останавливает сами запросы. Permissions Policy управляет доступом страницы к функциям браузера.

MDN также указывает на HTTP Observatory для проверки конфигурации сайта. Такие проверки дёшево автоматизировать: это не замена тестированию, а ранний датчик дрейфа между релизами.

Приоритизация уязвимостей: критичность, эксплуатация и контекст

Высокая оценка критичности сама по себе не делает находку первоочередной. Если довериться только ей, команда получит сотни «критичных» задач и будет закрывать их в порядке поступления, а реально опасная проблема на доступном из интернета сервере затеряется в середине списка.

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

Несколько оговорок к таблице. EPSS — вероятностная оценка, а не обещание: низкое значение не означает, что уязвимость никогда не будет использована. Отсутствие уязвимости в KEV не доказывает её безопасность — каталог фиксирует то, для чего есть свидетельства эксплуатации, а не всё, что эксплуатируется. Сроки устранения, связанные с KEV, адресованы прежде всего федеральным ведомствам США и не являются универсальным требованием для всех организаций.

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

Уровни приоритета как проектное решение

Удобно свести сигналы к небольшому числу уровней. Ниже — проектное предложение, а не отраслевая норма; сроки для каждого уровня должны установить ваши владельцы рисков.

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

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

Пересчёт приоритетов

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

Устранение: патч, конфигурация, компенсация или принятие риска

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

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

Исключения, которые не превращаются в вечные

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

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

Изменения без страха простоя

У исправлений есть собственный эксплуатационный риск: команды откладывают обновления, опасаясь простоя. Руководство CISA о безопасном развёртывании ПО (Safe Software Deployment) описывает процесс выкладки с тестированием и измерениями на каждом этапе. Логика переносится и на внутреннюю эксплуатацию: если исправления безопасности проходят через проверенный конвейер изменений с возможностью отката, соблазн откладывать их снижается.

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

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

Исправлять находки по одной необходимо, но этого мало. Самый сильный рычаг — устранять целые классы дефектов, чтобы они переставали появляться.

MITRE в описании рейтинга CWE Top 25 2025 года подчёркивает именно эту роль: понимание первопричин даёт обратную связь в жизненный цикл разработки и архитектуру и помогает устранять целые классы проблем — например, связанные с безопасностью памяти и внедрением, — уменьшая число уязвимостей, с которыми приходится разбираться после развёртывания. Помимо основного списка MITRE публикует слабости, которые были близки к включению в рейтинг. Этот список полезен командам, чьи типичные находки лежат сразу за пределами основного.

Та же логика видна в материалах CISA Secure by Design. Агентство выпускает руководства по устранению отдельных классов уязвимостей — межсайтового скриптинга, внедрения команд ОС, обхода каталогов — и по дорожным картам перехода на языки, безопасные по работе с памятью, включая внешние open source-зависимости. Для собственной разработки вывод практический: повторяющиеся находки должны становиться стандартами безопасного кодирования, шаблонами, библиотеками и проверками в конвейере сборки. OWASP Top 10 в редакции 2025 года остаётся широко признанной базой осведомлённости разработчиков, но базой именно осведомлённости, а не полным перечнем требований.

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

Повторная проверка и доказательства закрытия

Закрытая заявка ещё не означает устранённую уязвимость. Для закрытия повторяют исходный сценарий и, где это релевантно, проверяют близкие варианты обхода; допустима валидная эквивалентная проверка, если метод и его ограничения зафиксированы. Для находки сканера это может быть повторное сканирование, для веб-находки — соответствующий тест по методике, а для применимого требования приложения или API — сверка с конкретным требованием ASVS. ASVS помогает задавать покрытие и строгость проверки именно для приложений; он не является критерием закрытия всей инфраструктуры.

SP 800-115 соотносит тестирование с семействами мер контроля, в том числе аудитом и подотчётностью, оценкой, авторизацией и мониторингом, оценкой рисков. Поэтому аккуратно собранные доказательства пригодятся и при аудитах, но сами по себе они не являются сертификацией или заключением о соответствии.

С доказательствами нужно обращаться как с чувствительными данными. Журналы и ответы серверов могут содержать токены, персональные данные и внутренние адреса. Минимизируйте сохраняемое, вычищайте секреты, ограничивайте доступ, защищайте целостность и задайте срок хранения.

Ещё одна граница: повторная проверка подтверждает конкретное исправление в заданных условиях и границах, а не постоянное отсутствие риска. Если через месяц сервис переконфигурировали, прежний результат ничего не говорит о новом состоянии. О том, как строить такие проверки и формулировать их выводы, — в материале о валидации исправлений после пентеста.

Независимый тест как проверка самого процесса

Периодическое независимое тестирование, например авторизованный тест на проникновение, может дать сигнал о качестве процесса наряду с проверкой систем. Если тестировщики находят то, что пропустила плановая оценка, стоит изучить охват, время проверки, выбранные техники и изменения системы; один такой результат не доказывает единственную причину. Пентест не является сертификацией или заключением о безопасности: это запись протестированных сценариев и результатов в согласованных границах и условиях. Если вы хотите обсудить, какие активы и какие доказательства включить в такую независимую проверку, это удобно начать с описания объёма пентеста вместе с командой Pentest.red.

Метрики: поток, а не объём

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

Привязка находок к CWE позволяет видеть тренды и проверять, окупается ли работа с первопричинами. Снижение повторяемости классов внедрения или ошибок работы с памятью — более сильный признак прогресса, чем снижение общего числа находок. Руководству стоит отчитываться в терминах риска, согласованных с результатами CSF 2.0: какая доля критичных активов под контролем, сколько экстренных находок открыто дольше, чем допускает политика, какие исключения истекают в ближайшем квартале.

Метрики, которые вредят

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

Выбор платформы или подрядчика под готовый процесс

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

CISA выпустила руководство Secure by Demand для заказчиков ПО — оно помогает формулировать вопросы к поставщикам в ходе закупки. Совместное руководство австралийского ACSC и CISA о выборе безопасных и проверяемых технологий обращено напрямую к закупающим организациям. Обе публикации полезны как источник вопросов, а не как перечень обязательных требований.

Что спрашивать у поставщика

При оценке платформы или внешней услуги просите проверяемых ответов, а не обещаний:

• какие методики и их версии используются, например SP 800-115, конкретная версия WSTG и ASVS 5.0.0;
• как документируются авторизация, границы и правила взаимодействия до начала любых работ;
• учитывает ли приоритизация свидетельства эксплуатации и контекст актива, а не только оценку критичности;
• привязываются ли находки к CWE, а применимые находки в приложениях и API — к версионированным требованиям ASVS;
• какие форматы экспорта и интеграции с вашей системой заявок доступны;
• включена ли повторная проверка для подтверждения закрытия и в каких условиях;
• как долго хранятся доказательства, кому они принадлежат и как защищены.

Ту же строгость стоит применять к продуктам, которые вы эксплуатируете. CISA ведёт добровольное обязательство Secure by Design Pledge с семью целями, по которым подписанты публикуют отчёты о прогрессе. Подписание — не сертификация, но такой отчёт — полезный входной сигнал. В материалах Secure by Design агентство также настаивает, что продукты должны быть безопасны по умолчанию, а базовые защитные функции, такие как многофакторная аутентификация, журналирование и единый вход, не должны продаваться за доплату.

Своими силами, аутсорсинг или гибрид

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

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

Если гибридная модель вам ближе, с Pentest.red можно обсудить внешнюю часть: какие классы активов включить в тестирование на проникновение, какие доказательства и в каком формате нужны вашей системе заявок, как организовать повторную проверку исправлений. Решения о владельцах, сроках и принятии риска при этом остаются за вашей организацией.

С чего начать

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

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