Команды безопасности закрывают сотни уязвимостей в месяц. Графики становятся зелёными, отчёты выглядят опрятно, руководство кивает. А потом приходит вопрос: «Мы стали безопаснее?» — и в комнате повисает неловкая тишина. Никто не может ответить честно. И это не проблема конкретной команды — это системная ошибка в том, как большинство платформ управления уязвимостями устроены изнутри.
Счётчики патчей и баллы CVSS создавались совсем не для того, чтобы доказывать снижение реального риска. Они измеряют объём работы, а не её смысл. Именно для закрытия этого разрыва придумали exposure management — управление уязвимостями в контексте реальной среды. Но проблема в том, что большинство платформ, которые сегодня продаются под этим названием, справляются с задачей лишь частично.
Начать стоит с архитектуры. Существует четыре принципиально разных типа платформ. Первый — «сшитые» портфели, продукты серийных поглощений, где модули сканирования облака, сети и идентичностей работают каждый со своей моделью данных и лишь делят общий интерфейс. Общая консоль есть, корреляции между модулями почти нет. Второй тип — агрегаторы данных: они собирают находки из сторонних сканеров, нормализуют, показывают. Но они ограничены тем, что им дали на вход, и не могут связать разрозненные находки в цепочку. Третий тип — узкие специалисты: один инструмент уходит глубоко в облачные мисконфигурации или, допустим, только в идентичности. Глубина хорошая, но за пределами своего домена такой инструмент слеп. Четвёртый тип — интегрированные платформы, собранные с нуля в едином движке. Только они способны строить «цифрового двойника» среды и отслеживать, как атакующий движется через on-prem, облако и гибридные границы.
Теперь о цифрах, которые меняют картину. CVE — то, что большинство команд отслеживает в первую очередь — составляют примерно 25% реально эксплуатируемых векторов атак. Остальные 75% — это мисконфигурации, закешированные учётные данные, избыточные права, слабые места в идентичностях, AI-воркloады, машинные идентичности. Платформа, заточенная только под CVE, не видит большей части реальной поверхности атаки.
Оценивая любую платформу, первый вопрос звучит так: насколько широко она обнаруживает уязвимости и насколько глубоко анализирует каждую? Поверхностные метаданные из сторонних источников — это не анализ. Платформа должна контролировать каждый слой информации: от эксплуатируемости до способа исправления. И она должна нативно понимать новые категории угроз — те же машинные идентичности или риски AI-инфраструктуры.
Второй вопрос: умеет ли платформа строить пути атак через границы сред? Атакующие не уважают архитектурные разделы. Кража облачных учётных данных на on-prem машине, чтобы обойти защиту cloud-native — стандартная техника. Платформа, которая видит только сетевую топологию или только один домен, такую цепочку не обнаружит.
Третий — валидирует ли она эксплуатируемость? Большинство решений проверяют одно-два условия и строят выводы на предположениях. Нужны бинарные ответы, привязанные к реальной среде: уязвимость эксплуатируема или нет, актив достижим или нет, путь к критическому ресурсу существует или нет.
Четвёртый вопрос касается контроля безопасности. Уязвимость с CVSS 9.8, заблокированная файрволом — это совсем другая история, чем уязвимость идентичности с CVSS 5.5, у которой есть прямой путь к контроллеру домена. Разница принципиальная, и платформа обязана её учитывать. Анализ пути атаки должен включать активные контроли: файрволы, MFA, EDR, сегментацию. Без этого приоритизация не работает.
Пятый вопрос — как именно платформа расставляет приоритеты? Ранжирование по баллам, по тегам активов, по предполагаемым путям — всё это заваливает IT-команды задачами, большинство из которых реального риска не снижают. Правильная логика работает в обратном направлении: начать с критических активов и искать «узкие места» (choke points) — точки, где одно исправление перекрывает сразу несколько путей атаки. В крупных enterprise-средах такой подход сужает приоритетный список примерно до 2% от всех уязвимостей.
Разница в исходах между типами платформ вполне конкретна. Stitched и агрегирующие решения оставляют команды согласовывать находки между инструментами, спорить с IT о бессмысленных исправлениях и преследовать тупики. Узкие специалисты создают слепые зоны там, где цепочка атаки переходит из их домена в соседний. Интегрированные платформы — и только они — коррелируют уязвимости в валидированные пути атак, учитывают активные контроли и находят choke points. И если такая платформа ещё и обновляет граф в реальном времени, очередь приоритетов всегда отражает текущее состояние, а не снимок прошлой недели.
Изображение носит иллюстративный характер
Счётчики патчей и баллы CVSS создавались совсем не для того, чтобы доказывать снижение реального риска. Они измеряют объём работы, а не её смысл. Именно для закрытия этого разрыва придумали exposure management — управление уязвимостями в контексте реальной среды. Но проблема в том, что большинство платформ, которые сегодня продаются под этим названием, справляются с задачей лишь частично.
Начать стоит с архитектуры. Существует четыре принципиально разных типа платформ. Первый — «сшитые» портфели, продукты серийных поглощений, где модули сканирования облака, сети и идентичностей работают каждый со своей моделью данных и лишь делят общий интерфейс. Общая консоль есть, корреляции между модулями почти нет. Второй тип — агрегаторы данных: они собирают находки из сторонних сканеров, нормализуют, показывают. Но они ограничены тем, что им дали на вход, и не могут связать разрозненные находки в цепочку. Третий тип — узкие специалисты: один инструмент уходит глубоко в облачные мисконфигурации или, допустим, только в идентичности. Глубина хорошая, но за пределами своего домена такой инструмент слеп. Четвёртый тип — интегрированные платформы, собранные с нуля в едином движке. Только они способны строить «цифрового двойника» среды и отслеживать, как атакующий движется через on-prem, облако и гибридные границы.
Теперь о цифрах, которые меняют картину. CVE — то, что большинство команд отслеживает в первую очередь — составляют примерно 25% реально эксплуатируемых векторов атак. Остальные 75% — это мисконфигурации, закешированные учётные данные, избыточные права, слабые места в идентичностях, AI-воркloады, машинные идентичности. Платформа, заточенная только под CVE, не видит большей части реальной поверхности атаки.
Оценивая любую платформу, первый вопрос звучит так: насколько широко она обнаруживает уязвимости и насколько глубоко анализирует каждую? Поверхностные метаданные из сторонних источников — это не анализ. Платформа должна контролировать каждый слой информации: от эксплуатируемости до способа исправления. И она должна нативно понимать новые категории угроз — те же машинные идентичности или риски AI-инфраструктуры.
Второй вопрос: умеет ли платформа строить пути атак через границы сред? Атакующие не уважают архитектурные разделы. Кража облачных учётных данных на on-prem машине, чтобы обойти защиту cloud-native — стандартная техника. Платформа, которая видит только сетевую топологию или только один домен, такую цепочку не обнаружит.
Третий — валидирует ли она эксплуатируемость? Большинство решений проверяют одно-два условия и строят выводы на предположениях. Нужны бинарные ответы, привязанные к реальной среде: уязвимость эксплуатируема или нет, актив достижим или нет, путь к критическому ресурсу существует или нет.
Четвёртый вопрос касается контроля безопасности. Уязвимость с CVSS 9.8, заблокированная файрволом — это совсем другая история, чем уязвимость идентичности с CVSS 5.5, у которой есть прямой путь к контроллеру домена. Разница принципиальная, и платформа обязана её учитывать. Анализ пути атаки должен включать активные контроли: файрволы, MFA, EDR, сегментацию. Без этого приоритизация не работает.
Пятый вопрос — как именно платформа расставляет приоритеты? Ранжирование по баллам, по тегам активов, по предполагаемым путям — всё это заваливает IT-команды задачами, большинство из которых реального риска не снижают. Правильная логика работает в обратном направлении: начать с критических активов и искать «узкие места» (choke points) — точки, где одно исправление перекрывает сразу несколько путей атаки. В крупных enterprise-средах такой подход сужает приоритетный список примерно до 2% от всех уязвимостей.
Разница в исходах между типами платформ вполне конкретна. Stitched и агрегирующие решения оставляют команды согласовывать находки между инструментами, спорить с IT о бессмысленных исправлениях и преследовать тупики. Узкие специалисты создают слепые зоны там, где цепочка атаки переходит из их домена в соседний. Интегрированные платформы — и только они — коррелируют уязвимости в валидированные пути атак, учитывают активные контроли и находят choke points. И если такая платформа ещё и обновляет граф в реальном времени, очередь приоритетов всегда отражает текущее состояние, а не снимок прошлой недели.
