? Это часть 5 серии “Управление уязвимостями для самых маленьких” - практического руководства по VM с нуля. Главы самостоятельны, но если хочется по порядку - оглавление и все части серии тут.

Строить все своими силами не обязательно. Многие задачи управления уязвимостями можно отдать на сторону - и иногда это разумнее, чем разворачивать собственную инфраструктуру. Разберем три сервисных модели: пентест как сервис, VM как сервис и багбаунти.

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

Пентест как сервис

Сначала разберемся, что такое пентест и каким он бывает.

Пентест (тестирование на проникновение) - это попытка найти в системе слабые места, через которые можно совершить непредусмотренные действия. Обычно под пентестом понимают поиск уязвимостей методом черного ящика: данные для подключения не предоставляются, и нужно найти дыры так, как это сделал бы внешний злоумышленник.

Пентест бывает ручным и автоматизированным. Ручной выполняет команда пентестеров. Автоматизированный использует инструменты: они определяют открытые порты, запускают безопасные проверки на известные уязвимости, ищут неизвестные уязвимости через фаззинг (подстановку произвольных данных) и пытаются определить версии систем, чтобы найти присущие им уязвимости.

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

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

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

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

Другой вариант - сторонний сервис, который снаружи проводит пентест вашего периметра и отдает данные о найденных уязвимостях. Эти данные можно автоматически импортировать в вашу VM-систему, трекер или передавать отчетами в ИТ, а можно работать прямо в интерфейсе сервиса.

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

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

Ограничения пентеста как сервиса:

• Ограниченная гибкость. Вы работаете в рамках того, что предлагает сервис: параметры, скорость сканирования.

• Чувствительность данных. Информация о ваших уязвимостях нужна для устранения, но она же крайне интересна злоумышленникам. Относитесь к ней как к секретной.

В целом пентест как сервис позволяет быстро получить результат и сосредоточиться на устранении. Им пользуются и небольшие компании, и крупный энтерпрайз, чтобы не возиться с поднятием собственной инфраструктуры снаружи организации. Спрос на это растет: мировой рынок пентеста как сервиса в 2024 году оценивали примерно в 1,6 млрд долларов, и он прибавляет около 20 процентов в год. Российский рынок пентеста скромнее по деньгам, но в 2025 году тоже рос на десятки процентов, а большую часть корпоративных проектов делят между собой несколько крупных игроков. Появляются и инструменты контролируемого автопентеста, которые имитируют действия атакующего в безопасном режиме - например, отечественный PT Dephaze.

VM как сервис

VM как сервис похож на пентест как сервис, но шире. Помимо сканирования методом черного ящика, выполняется еще и сканирование методом белого ящика: внутрь инфраструктуры ставится (или к нему пробрасывается доступ) агент, который сканирует активы изнутри с использованием учетных данных. Так собирается куда больше данных о том, что у вас реально установлено и каких версий. В режиме пентеста версия ПО или ОС может определиться неточно, и вы рискуете либо пропустить реальные уязвимости, либо получить ложные.

Результат, как и у пентеста-сервиса - отчет об уязвимостях или структурированные данные через API.

Но даже с сервисом у вас должен быть налажен процесс с ИТ-департаментом, который реагирует на отчеты и устраняет уязвимости в срок. VM как сервис закрывает только часть работы безопасника - саму работу по устранению с ИТ никто не снимал. Можно построить интеграции с системой патч-менеджмента (например, с Microsoft SCCM или его российскими аналогами), но это все равно держится на договоренностях и контроле со стороны ИТ.

При аудитном сканировании вы, как и в обычном процессе VM, можете задавать важность активов и устанавливать SLA на сроки устранения - так же, как при on-premise установке.

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

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

Сервис уместен и когда не хватает своих ресурсов на организацию процесса, и когда нет квалифицированного безопасника для приоритизации уязвимостей. Можно попытаться переложить приоритизацию на ИТ, но обычно у ИТ нет экспертизы в конкретных уязвимостях и эксплойтах. Тут лучше полагаться на инструменты сервиса: в самом базовом виде смотреть на метрику CVSS и критичность актива, а еще лучше - использовать оценку по методике ФСТЭК или современные метрики вроде EPSS (вероятность эксплуатации) и каталоги активно эксплуатируемых уязвимостей (CISA KEV, трендовые уязвимости БДУ ФСТЭК). К слову, обе метрики за последнее время заметно повзрослели: в 2025 году вышла четвертая версия EPSS, которая учитывает в том числе данные телеметрии с конечных точек, а каталог CISA KEV перевалил за полторы тысячи уязвимостей, под которые есть подтвержденная эксплуатация. Обновилась и методика ФСТЭК (редакция от 30 июня 2025 года): теперь в основе только базовый вектор CVSS 3.1, к которому добавили два своих параметра - наличие эксплойта и категорию последствий. Подробно об этом - в главе про приоритизацию.

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

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

Багбаунти

Что это такое

Багбаунти (bug bounty) - это возможность выставить свою инфраструктуру, продукты или сервисы на проверку внешним независимым исследователям. Помимо стандартного пентеста, багбаунти привлекает множество экспертов с разноплановым опытом: то, что не заметит один, найдет другой.

Есть специализированные платформы, на которых регистрируются исследователи безопасности (“белые хакеры”), готовые участвовать в программах. Можно запустить программу и без платформы, но тогда компании придется самой искать исследователей, готовить регламенты, проводить триаж и организовывать выплаты. Платформа берет все это на себя.

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

Триаж (triage) - процесс верификации отчетов багхантеров и выдачи рекомендаций по устранению. Команда триажеров проверяет, действительно ли найденное является уязвимостью, и помогает безопасникам быстро привести активы в порядок. Это фильтр между потоком отчетов и вашей командой.

Как выглядит процесс на платформе

1. Компания определяет список активов (скоуп), которые можно исследовать.

2. Компания определяет бюджет программы и выбирает формат публикации:

   • публичный - программу видят все зарегистрированные исследователи;

   • приватный - программу видит ограниченный круг приглашенных багхантеров.

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

4. Компания выбирает формат работы с отчетами (самостоятельно или через триаж).

5. Компания приоритизирует найденные уязвимости и устраняет их.

6. Компания выплачивает вознаграждения исследователям.

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

• Прием отчета. Вы получили баг-репорт от исследователя

• Первичная проверка. Действительно ли это уязвимость? Воспроизводите ее

• Классификация. Определяете тип, например SQL-инъекция, дающая доступ к базе данных

• Приоритизация. Это высококритичная уязвимость, потому что грозит утечкой данных

• Передача разработчикам. Немедленно отправляете информацию на исправление

• Выплата. Выплачиваете вознаграждение за отчет

Кому стоит использовать багбаунти

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

Несколько практических советов:

• Начинайте с приватного режима. Так вы не утонете в потоке отчетов и сможете регулировать нагрузку на команду

• Начинайте с умеренных вознаграждений и повышайте их по мере роста бюджета и зрелости процесса

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

Чем багбаунти ценен? Исследователи ищут действительно важные уязвимости. Им интересен не взлом ради взлома. Им важно найти дыру и помочь расставить правильные акценты. Багбаунти симулирует реальные атаки силами множества людей и находит то, что не под силу автоматическим сканерам.

Про багбаунти есть выпуск подкаста #Кибердуршлаг ссоветую к прослушиванию.

Выгода обоюдная: компании повышают защищенность и снижают риск убытков, а исследователи легально применяют навыки, получая деньги и признание в сообществе. Деньги, к слову, бывают серьезные. На российских площадках сильнейшие багхантеры за 2025 год заработали по нескольку миллионов рублей каждый, а один восемнадцатилетний исследователь поднял больше 7 миллионов всего за полтора месяца - помогая себе AI-инструментами для разведки. Это уже не хобби, а полноценная профессия.

Платформы и российская специфика

Мировые платформы: HackerOne, Bugcrowd, Synack. Багбаунти-программы есть у Google, Microsoft, Meta (запрещена в РФ) и сотен других компаний. Масштаб глобального рынка проще оценить в цифрах: за год (середина 2024 - середина 2025) через одну только HackerOne белым хакерам выплатили около 81 млн долларов, а суммарно за все время платформа перевалила за 300 млн. Google за 2025 год раздал исследователям рекордные 17 млн долларов. То есть багбаунти давно перестал быть экзотикой - это устоявшийся рынок.

В России он за последние годы вырос взрывными темпами. Две крупнейшие отечественные платформы - Standoff Bug Bounty (Positive Technologies) и BI.ZONE Bug Bounty. Цифры за 2025 год говорят сами за себя: на двух площадках белые хакеры прислали почти 14 тысяч отчетов об уязвимостях в российских компаниях и госструктурах, а суммарные выплаты составили около 260 млн рублей - примерно 160 млн на Standoff и 100 млн на BI.ZONE [1]. Количество программ на Standoff Bug Bounty за год выросло в 2,2 раза, до 233, число зарегистрированных исследователей подскочило почти на три четверти и перевалило за 32 тысячи, а средняя выплата прибавила около 12 процентов и поднялась выше 65 тысяч рублей. Максимальное единовременное вознаграждение там превысило 4,9 млн рублей. BI.ZONE за год нарастил выплаты в полтора раза и тоже добрался до сотни миллионов.

Отдельно стоит сказать про государство. Площадки госкомпаний и даже отдельные госорганы выходят на багбаунти - то, что еще пять лет назад казалось немыслимым. Минцифры в 2025 году запустило уже третий этап своей программы, выставив на проверку девять государственных систем, включая Госуслуги, с выплатами до миллиона рублей. На багбаунти потянулись и регионы - программы запускали власти Камчатки, Перми, Тюмени, Новосибирска, - и крупный бизнес вроде Сбербанка. Госсектор второй год подряд оказывается самым быстрорастущим сегментом. Показательна и история мессенджера Max: за первые месяцы программы исследователи нашли там сотни уязвимостей, а выплаты подобрались к 22 млн рублей.

Есть, правда, и юридическая загвоздка: деятельность белых хакеров в России до сих пор законодательно не урегулирована. Первый вариант законопроекта Госдума в июле 2025 года отклонила - причем целиком, а не отправила на доработку отдельную редакцию. Взамен депутаты и сенаторы вместе с отраслью собрали новый пакет сразу из трех законопроектов: поправки в Гражданский кодекс (право искать уязвимости без согласия правообладателя), правила тестирования и требования к платформам, а также поправки в Уголовный кодекс - вплоть до отдельной статьи за неправомерную передачу данных об уязвимостях [2]. К середине 2026 года этот пакет все еще дорабатывается в правительстве и пока не принят. Так что исследователи и компании работают, опираясь на оферты багбаунти-платформ. Система функционирует, но всем участникам спокойнее было бы с нормальным законом.

А как у вас?

Что выбрали вы - строить VM внутри или брать как сервис? И пробовал ли кто-то багбаунти: каково это с точки зрения нагрузки на команду, когда отчеты реально пошли?

Навигация по серии: ⬅️ Предыдущая: Гл. 4. Купили сканер - но процесса нет · ? Оглавление серии · Следующая: Гл. 6. VM ломается не на сканере, а на людях ➡️

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