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

Условный сценарий. Онлайн-маркетплейс среднего размера подписывает договор на управление уязвимостями как сервис после убедительной демонстрации: аккуратный портал, графики по критичности, интеграция с трекером задач. Через три месяца картина выглядит иначе. Разработчики каждую неделю получают выгрузку на сотни строк, и заметная часть в ней — дубликаты одной проблемы на разных хостах. Технический директор спрашивает, стала ли компания защищённее, и никто не может ответить: портал показывает количество находок, а не изменение риска. Тестовый поддомен, поднятый полгода назад для партнёра, в мониторинг так и не попал, потому что его никто не подключил. А одна «закрытая» критическая уязвимость на деле не исправлена: администратор просто заблокировал IP-адреса сканера, и повторный прогон показал «не обнаружено».

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

Управление уязвимостями как сервис (vulnerability management as a service, VMaaS) охватывает разные договорные модели. В целевой модели этой статьи внешний провайдер отвечает за согласованные части повторяющегося цикла: обнаруживает и подтверждает слабости, расставляет приоритеты, сопровождает или выполняет устранение, если это делегировано договором, и повторно проверяет исправления. Ниже разберём, из чего состоит этот цикл, как описать его на языке открытых стандартов, как отличить процесс от подписки на дашборд и как построить пилот, который покажет разницу на ваших системах.

Что на самом деле покупают под названием VMaaS

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

Платформа против процесса

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

Цикл, который должен замыкаться

NIST SP 800-115, техническое руководство по тестированию и оценке информационной безопасности, ставит цель помочь организациям планировать и проводить технические тесты, анализировать результаты и вырабатывать стратегии снижения рисков. Формально публикация описывает оценку в три фазы: планирование, выполнение и работы после выполнения, куда входят анализ, отчётность и рекомендации по снижению рисков. Она же оговаривает, что не является исчерпывающей программой тестирования. Управляемый сервис превращает эту разовую последовательность в повторяющийся цикл — это редакционная адаптация, а не требование документа. Сервис, который только пересылает сырой вывод сканера, покрывает одно звено из нескольких.

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

NIST Cybersecurity Framework 2.0 смотрит шире: его цель — помочь организациям понимать киберриски и лучше управлять ими. С этой точки зрения VMaaS — часть управления рисками, а не периодический отчёт. Хороший сервис показывает, какие активы затронуты, какие слабости важны, какие исправления просрочены и снизилась ли подверженность атакам.

Подключение активов и охват: где сервис теряет связь с реальностью

Ни один провайдер не проверит то, о чём не знает. Поэтому первым стоит обсудить не сканер, а процедуру подключения активов. Кто вносит новый сервис, домен или облачный аккаунт в инвентарь? Как провайдер узнаёт, что команда выкатила новый API или переехала в другой регион облака? Что происходит с активами, которые обнаружил сам провайдер, но которых нет в договоре: их начинают проверять или сначала согласуют с заказчиком? От ответов зависит, совпадёт ли охват сервиса с реальной поверхностью атаки через полгода.

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

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

Кто за что отвечает: роли и соглашения об уровне сервиса

Аутсорсинг передаёт работу, но не ответственность. CSF 2.0 исходит из того, что организация сама управляет своими киберрисками: решение принять риск, отложить исправление или вывести систему из эксплуатации остаётся за заказчиком, даже если обнаружение и тестирование ведёт подрядчик. Это стоит прямо записать в договор, иначе возникает удобная серая зона, в которой находка «передана», но никем не принята.

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

Ниже — сравнение моделей, между которыми обычно выбирают. Это не рейтинг: каждая модель уместна в своих условиях, и их часто сочетают.

Стандарты как язык охвата, а не как значок

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

OWASP Top 10 — документ для повышения осведомлённости о наиболее критичных рисках веб-приложений. В редакции 2025 года он остаётся удобным общим словарём для отчётов, но не спецификацией тестирования. Фраза «покрываем OWASP Top 10» называет категории рисков и ничего не говорит о глубине проверки.

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

OWASP WSTG (в версии 4.2) описывает, как тестировать веб-приложения на практике. SP 800-115 добавляет уровень программы: как проектировать и поддерживать процесс технического тестирования. MITRE CWE классифицирует слабости — первопричины, которые объединяют разрозненные находки в классы.

Важная оговорка: ASVS и WSTG охватывают веб-приложения и API, но сами по себе не задают весь инфраструктурный охват. Сопоставление находки с требованием ASVS или классом CWE — способ описания, а не доказательство соответствия. Пентест может дать доказательство для конкретного применимого требования в зафиксированных условиях, но идентификатор в каждой строке не означает, что требование проверено целиком, а приложение соответствует стандарту. Ни пентест, ни управляемый сервис сами по себе не являются сертификацией, аттестацией или заключением о соответствии.

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

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

CVSS, EPSS, KEV и экспозиция актива

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

Четвёртый вопрос знает только заказчик — и провайдер, если ему передали контекст: насколько актив доступен атакующему и что на нём хранится. Условный пример: уязвимость средней серьёзности во внешнем сервисе входа, отмеченная в KEV, может требовать более срочной реакции, чем «критическая» уязвимость во внутренней тестовой среде без чувствительных данных и без маршрута из интернета. Это иллюстрация логики, а не правило. Зрелый сервис объясняет, какие факторы привели к приоритету, и позволяет заказчику оспорить вывод. Универсальных порогов вроде «всё с EPSS выше определённого значения — срочно» нет: пороги выбирает организация, а провайдер должен объяснить предпосылки своих настроек по умолчанию. Подробнее — в разборе приоритизации уязвимостей с учётом риска.

От отдельных находок к первопричинам

Второй уровень приоритизации — классы слабостей. MITRE CWE Top 25 в редакции 2025 года выделяет опасные слабости, которые часто легко обнаруживаются и эксплуатируются и могут приводить к захвату системы, краже данных или нарушению работы приложений. Рядом публикуются CWE Top 10 KEV Weaknesses, ранжирующий слабости по данным каталога KEV, и список «On the Cusp» со слабостями, чуть не вошедшими в основной рейтинг.

Смысл не в том, чтобы сверяться с рейтингом, а в обратной связи. MITRE предлагает передавать первопричины в жизненный цикл разработки и архитектуру, чтобы устранять целые классы дефектов, например связанные с инъекциями или безопасностью памяти, и отмечает, что слабости вроде внедрения команд привлекают внимание злоумышленников. Если сервис каждый месяц сообщает о новых экземплярах одной инъекции в разных модулях, полезнее не десять заявок, а одна задача на общий механизм обработки входных данных. При этом CWE классифицирует слабость, а не оценивает вероятность эксплуатации конкретной CVE, и не заменяет данных об эксплуатации и контекста актива.

Глубина тестирования: что даёт автоматизация и где нужен человек

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

Автоматизированное сканирование даёт ширину и повторяемость: известные уязвимые версии компонентов, ошибки конфигурации, отсутствующие защитные заголовки. Ручное тестирование по WSTG добавляет глубину там, где нужно понимать задуманное поведение системы: бизнес-логику, разграничение доступа между ролями и арендаторами, цепочки операций, которые по отдельности выглядят безобидно. Инструменты здесь помогают, но результат обычно требует человеческой интерпретации; о том, как заказывать такую проверку, мы писали в статье про тестирование бизнес-логики. Соотношение автоматики и ручной работы должно быть прописано в техническом задании. Удобный инструмент — ASVS: попросите провайдера разметить, какие требования проверяются автоматически, какие вручную, а какие не входят в охват.

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

Авторизация и правила проведения работ

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

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

Веб-находки, которые сервис должен объяснять, а не перечислять

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

MDN описывает механизмы, которые регулярно фигурируют в отчётах. Content Security Policy определяет, какие ресурсы может загружать страница, и помогает смягчать атаки вроде межсайтового скриптинга и внедрения данных. CORS сообщает браузеру, может ли скрипт с другого источника читать ответ; опасная настройка может открыть ответ с учётными данными в браузере пользователя, но не заменяет серверную авторизацию. Для некоторых междоменных запросов в режиме no-cors Cross-Origin Resource Policy может скрыть тело ответа от вызывающего контекста, но не обязательно предотвращает сам запрос. Permissions Policy ограничивает функции браузера и API, доступные коду сайта. Для предварительной самопроверки конфигурации MDN предлагает HTTP Observatory.

Хороший отчёт объясняет каждую такую находку через риск, который она снижает, и, где применимо, связывает её с требованием ASVS с версией. Он отличает отсутствие заголовка, добавляющего эшелон защиты, от эксплуатируемой инъекции и учитывает назначение ресурса. Разрешительная политика CORS для ответа, задуманного как публично читаемый из других источников, — не то же, что настройка, позволяющая контролируемому атакующим источнику прочитать ответ авторизованного пользователя. CORS регулирует доступ браузера к ответу и не решает, какие ресурсы сервер должен авторизовать; обе стороны нужно проверять отдельно.

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

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

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

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

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

Компромиссы аутсорсинга управления уязвимостями

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

Есть и то, чего аутсорсинг не меняет. CISA в программе Secure by Design отмечает, что бремя кибербезопасности непропорционально легло на потребителей и небольшие организации, а не на производителей технологий, и настаивает, что поставщики должны отвечать за безопасность своих продуктов на уровне руководства. Вывод для заказчика: управляемый сервис помогает управлять риском, но не заменяет исправления изъянов самими поставщиками ПО. Давление на них через закупки и договоры по-прежнему нужно.

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

Вопросы провайдеру и безопасность его платформы

Провайдер сам является цифровым сервисом, где будет храниться подробная карта ваших слабостей, поэтому к нему применимы те же ожидания, что и к любому поставщику ПО. CISA в материалах Secure by Design и Secure by Demand призывает к продуктам, безопасным по умолчанию, где многофакторная аутентификация, журналирование и единый вход доступны без доплаты. Для портала провайдера это конкретный вопрос: входят ли MFA для пользователей, SSO и журнал аудита в базовое предложение или продаются как опции.

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

Вопросы о процессе полезно задать всем кандидатам одинаково, чтобы ответы можно было сравнить. Какая версия ASVS и какие требования входят в охват, указываются ли ссылки с версией? Какие приёмы WSTG и SP 800-115 используются и каковы их заявленные ограничения? Как подтверждаются находки и как в приоритизации учитываются EPSS, KEV и контекст активов? Сообщается ли о первопричинах в терминах CWE? Входит ли повторное тестирование и как оформляется его результат? Можно ли выгрузить все данные в машиночитаемых форматах, например CSV или JSON, в том числе при расторжении договора? Как долго хранятся данные об уязвимостях и как подтверждается их удаление?

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

Как провести пилот и принять решение

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

Начните с целей: какие риски вы хотите снизить и какие системы для этого важнее всего. Ресурсы CSF 2.0, включая краткие руководства и профили, помогают сформулировать это на языке управления рисками. Затем задайте базовый уровень проверки — набор требований ASVS с версией для типичных приложений — и попросите провайдеров описать методику в терминах WSTG и SP 800-115 вместе с ограничениями, а также объяснить модель приоритизации.

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

Тревожные признаки видны уже на этом этапе: «соответствие OWASP Top 10» без привязки к требованиям, непроверенный вывод сканера под видом находок, отсутствие повторного тестирования и письменной процедуры авторизации, ссылки на стандарты без версий, обещание универсальных сроков, за соблюдение которых на деле отвечает заказчик.

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

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

Управление уязвимостями как сервис стоит покупать, если оно замыкает весь цикл: от подключения актива и спланированного тестирования через подтверждение и приоритизацию к проверенному исправлению. Охват должен выражаться в требованиях ASVS с версией, методы — в терминах WSTG и SP 800-115, приоритеты — через сочетание серьёзности, данных об эксплуатации, первопричин CWE и контекста ваших активов. Ответственность за решения о риске остаётся у вас, и договор должен это отражать.

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