Классы решений по работе с уязвимостями: от сканеров до Bug Bounty

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

Это не признак слабости или ошибки конкретной команды — это реальность сложных ИТ-систем.

Если представить инфраструктуру как дом, то:

• уязвимости — это окна и щели,
• эксплойты — инструменты, с помощью которых в них пытаются проникнуть,
• payload — то, что злоумышленник заносит внутрь после взлома.

Ключевая проблема не в том, что «окон много», а в том, что:

• не всегда понятно, где они находятся,
• какие из них действительно опасны,
• и закрываются ли они вообще.

По сути, именно этим и должна заниматься работа с уязвимостями: нt поиском идеальной безопасности, а управлением рисками и приоритетами.

В вебинаре мы выделили три основные зоны, в которых чаще всего возникают уязвимости.

Внешний периметр
Это всё, что доступно из интернета: сайты, API, VPN-шлюзы, веб-кабинеты, панели администрирования.
Именно эта зона первой попадает в поле зрения атакующего и чаще всего становится точкой входа в инфраструктуру.

Внутренняя инфраструктура
Серверы, рабочие станции, филиалы, доменная среда.
Здесь работает модель внутреннего нарушителя — когда злоумышленник уже получил доступ и пытается развивать атаку дальше.

Отдельный вектор — собственная разработка, CI/CD, контейнеры Docker и Kubernetes.

Этот слой всё чаще становится источником уязвимостей, особенно при активном использовании подрядчиков и автоматической генерации кода.

Одна из причин путаницы — большое количество классов решений, которые частично пересекаются по функционалу.

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

Далее могут использоваться внешние сканеры, которые автоматически ищут уязвимости на ресурсах, доступных из интернета.

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

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

В наиболее зрелых организациях встречается и bug bounty, когда поиск уязвимостей выносится на внешнее сообщество исследователей.

Во внутренней инфраструктуре чаще всего начинают со сканеров уязвимостей, которые периодически проверяют ОС и ПО серверов и рабочих станций.

На небольших объёмах это работает, но по мере роста инфраструктуры появляются типичные проблемы:

• тысячи находок,
• отчёты, которые никто не читает,
• отсутствие приоритетов и сроков закрытия.

В этот момент возникает потребность в VM-платформах, которые добавляют процесс:
инвентарь активов, приоритизацию, задачи для ИТ, SLA и контроль динамики.

Дополнительно используются:

• внутренние пентесты — проверка модели внутреннего нарушителя;
• автопентесты — автоматизация рутинных этапов;
• BAS — имитация техник атак для проверки реальной эффективности настроек NGFW, EDR и почтовых шлюзов.

Уязвимости в коде и контейнерах не закрываются классическими сканерами инфраструктуры.

Здесь применяются:

• SAST и DAST для анализа кода и приложений,
• сканирование образов,
• контроль политик запуска и CI/CD.

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

Воспользуемся моделью «магического треугольника Журавлёва»: периметр, внутренняя сеть и разработка.

VM-платформа находится ближе к центру, потому что:

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

Но при этом VM не заменяет ни пентест, ни AppSec, ни контейнерную безопасность.

Она помогает не утонуть в объёмах, но не закрывает все классы рисков.

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

Например, bug bounty не имеет смысла, если в компании ещё нет сканера уязвимостей и процесса их закрытия.

Обычно путь выглядит так:

• базовый уровень — OSINT и сканирование;
• средний уровень — VM-платформа и контроль внешнего периметра;
• высокий уровень — BAS, red teaming, bug bounty и развитый AppSec.

Работа с уязвимостями — это не про количество инструментов и не про «закрыть всё».

Это про понимание:

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

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