ASPM в эпоху ИИ, часть 2: приоритизация эксплуатируемых рисков с помощью контекста «от кода до облака»

Источник: wiz.io•

ASPM в эпоху ИИ, часть 2: приоритизация эксплуатируемых рисков с помощью контекста «от кода до облака»

Сократите время на сортировку и сосредоточьтесь на наиболее важных рисках, объединив контекст кода, инфраструктуры и среды выполнения.

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

Как отмечалось в нашем недавнем отчете «Состояние безопасности SDLC 2026», основное влияние ИИ заключается не столько в появлении принципиально новых рисков, сколько в усилении существующих из-за ускоренной генерации кода, что ведет к расширению поверхности атаки при меньшем времени на проверку человеком.

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

Чтобы превратить необработанные результаты сканирования в действия по устранению рисков, Wiz Code выполняет приоритизацию на двух разных уровнях:

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

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

  • Приоритизация путей атаки: использование Wiz Security Graph для связи находок на уровне кода с контекстом работающей облачной среды, что превращает изолированные недостатки в полностью подтвержденные пути атаки.

Приоритизация путей атаки: использование Wiz Security Graph для связи находок на уровне кода с контекстом работающей облачной среды, что превращает изолированные недостатки в полностью подтвержденные пути атаки.

Давайте рассмотрим, как внедрить оба уровня в вашей среде.

Обогащение, дедупликация и приоритизация отдельных находок

Находки от подключенных сканеров попадают в соответствующие домены на платформе Wiz. Например, результаты SAST поступают на вкладку SAST Findings, результаты SCA — на вкладку Vulnerability Findings, а результаты поиска секретов — на страницу Secret Findings. Вы можете легко отфильтровать любую таблицу по «источнику» (origin), чтобы выделить оповещения от конкретного инструмента. В примере ниже мы фильтруем находки уязвимостей, полученные в результате сканирования Snyk SCA.

На основе этой унифицированной базы Wiz выполняет несколько уровней приоритизации, чтобы помочь командам AppSec сосредоточиться на важном.

Обогащение

Импортированные находки обогащаются контекстом конкретного домена, превращая общие оповещения в приоритизированные находки. Например:

  • SCA: находки на основе CVE обогащаются контекстом из каталога уязвимостей NVD, показателями вероятности EPSS (Exploit Prediction Scoring System) в реальном времени, доступностью активных эксплойтов и статусом CISA KEV. Наша команда Threat Research также помечает находки с активными угрозами и пишет полные рекомендации, чтобы команды безопасности имели самую актуальную информацию о «нулевых днях».

SCA: находки на основе CVE обогащаются контекстом из каталога уязвимостей NVD, показателями вероятности EPSS (Exploit Prediction Scoring System) в реальном времени, доступностью активных эксплойтов и статусом CISA KEV. Наша команда Threat Research также помечает находки с активными угрозами и пишет полные рекомендации, чтобы команды безопасности имели самую актуальную информацию о «нулевых днях».

  • SAST: находки CWE включают фрагменты кода, чтобы команды безопасности имели представление о расположении и контексте уязвимостей.

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

  • DAST: Wiz независимо проверяет сетевую доступность веб-приложений с находками DAST, используя модуль Attack Surface Management (ASM). Механизм ASM можно настроить для выполнения других проверок, таких как поиск секретов или утечек конфиденциальных данных с периметра на этих вновь созданных конечных точках. Адреса, доступные только из внутренней сети, помечаются иначе, чтобы команды могли приоритизировать находки с реальной внешней поверхностью атаки.

DAST: Wiz независимо проверяет сетевую доступность веб-приложений с находками DAST, используя модуль Attack Surface Management (ASM). Механизм ASM можно настроить для выполнения других проверок, таких как поиск секретов или утечек конфиденциальных данных с периметра на этих вновь созданных конечных точках. Адреса, доступные только из внутренней сети, помечаются иначе, чтобы команды могли приоритизировать находки с реальной внешней поверхностью атаки.

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

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

Дедупликация

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

Wiz помечает одну находку как «Representative» (представительную), а дубликаты — как «Duplicate». Команды могут применять автоматизированные правила игнорирования (Ignore Rules) к дубликатам, мгновенно устраняя избыточный шум в отчетах без потери аудиторского следа сканера. Таким образом, вместо создания отдельных тикетов для каждой находки, команды могут создать один тикет для консолидации находок.

Приоритизация эксплуатируемых путей атаки

Традиционно ASPM фокусировался на агрегации находок и приоритизации рисков с использованием простого скоринга. Wiz использует другой подход, сопоставляя находки с дополнительными рисками в Wiz Security Graph. Именно здесь платформа переходит от управления уязвимостями к управлению эксплуатируемыми путями атаки.

Wiz Security Graph сопоставляет несколько факторов риска в единую проблему Wiz Issue (выявляя опасные комбинации рисков). Важно отметить, что эти элементы управления работают с вашими сторонними находками точно так же, как и с собственными находками Wiz. Если вы подключаете сканер, его данные мгновенно становятся частью вашего анализа путей атаки «от кода до облака».

Как это выглядит на практике

Давайте посмотрим, как этот контекст превращает стандартное оповещение в приоритизированную проблему Wiz Issue. Представьте, что ваша интеграция с Snyk помечает находку SAST высокой степени серьезности (например, удаленное выполнение кода или внедрение команд) в ветке репозитория. В отрыве от контекста разработчик может посчитать это срочным приоритетом или проигнорировать, если решит, что это внутренний инструмент.

Wiz Security Graph оценивает весь жизненный цикл развертывания, чтобы выявить реальный риск. Одна проблема Wiz Issue может показать:

  • Недостаток кода: находка SAST от Snyk и собственная находка SAST от Wiz, обе возникшие в одной и той же ветке репозитория.

Уязвимость в коде: результат SAST от Snyk и собственный результат SAST от Wiz, оба из которых возникли в одной и той же ветке репозитория.

  • Артефакт сборки: эта конкретная ветка была собрана в образ контейнера, который в настоящее время работает в производственном кластере Kubernetes.

Артефакт сборки: эта конкретная ветка была собрана в образ контейнера, который в настоящее время работает в производственном кластере Kubernetes.

  • Воздействие: кластер Kubernetes открыт для интернета через общедоступную конечную точку приложения.

Воздействие: кластер Kubernetes открыт для интернета через общедоступную конечную точку приложения.

  • Активная проверка: результат управления поверхностью атаки (ASM) подтверждает, что конечная точка активно доступна извне.

Активная проверка: результат управления поверхностью атаки (ASM) подтверждает, что конечная точка активно доступна извне.

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

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

Управление техническим долгом в масштабе

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

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

Далее: устранение и автоматизация на машинной скорости

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

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

О чём эта статья

Ещё в разделе «Кибербезопасность»

Все →

Ещё от Wiz