Передовые модели ИИ и агентная разработка фундаментально изменили требования к безопасности приложений.
С одной стороны, модели ИИ могут автономно обнаруживать уязвимости и создавать рабочие эксплойты, сокращая время от обнаружения до эксплуатации с дней до минут. С другой стороны, разработка с поддержкой ИИ помогает командам выпускать код быстрее, чем когда-либо, усиливая существующие риски и расширяя поверхность атаки.
Это двойное ускорение разрушает традиционные рабочие процессы AppSec. Процесс, который когда-то позволял командам вручную просматривать оповещения сканеров, находить владельцев кода и назначать тикеты, больше не жизнеспособен в эпоху обнаружения и эксплуатации на машинной скорости.
Именно поэтому управление состоянием безопасности приложений (ASPM) сегодня важнее, чем когда-либо. Но это не может быть просто уровень, агрегирующий сигналы о рисках. Чтобы обеспечить реальные результаты в области безопасности, ASPM должен помогать командам приоритизировать эксплуатируемые риски, опираясь на контекст всего жизненного цикла приложения.
В этой серии блогов мы подробно рассмотрим, как организации могут внедрить ASPM с помощью Wiz Code. В ближайшие несколько недель мы расскажем о следующем:
- Часть 1: Видимость и покрытие: как подключить существующие сканеры, сопоставить и дедуплицировать ресурсы, а также выявить пробелы в покрытии ваших кодовых баз.
Часть 1: Видимость и покрытие: как подключить существующие сканеры, сопоставить и дедуплицировать ресурсы, а также выявить пробелы в покрытии ваших кодовых баз.
- Часть 2: Контекст и приоритизация: как Wiz обогащает сторонние результаты, удаляет дубликаты оповещений и использует граф безопасности (Security Graph) для выявления реальных путей атаки.
Часть 2: Контекст и приоритизация: как Wiz обогащает сторонние результаты, удаляет дубликаты оповещений и использует граф безопасности (Security Graph) для выявления реальных путей атаки.
- Часть 3: Устранение и автоматизация: как систематически группировать результаты для разработчиков с помощью политик состояния (Posture Policies) и использовать Green Agent для исправлений, созданных ИИ.
Часть 3: Устранение и автоматизация: как систематически группировать результаты для разработчиков с помощью политик состояния (Posture Policies) и использовать Green Agent для исправлений, созданных ИИ.
Почему контекст — это основа ASPM
Чтобы обеспечить результаты в области безопасности, ASPM нуждается в прочной основе из контекста.
Давайте рассмотрим практический пример с React2Shell (CVE-2025-55182), критической уязвимостью удаленного выполнения кода, затронувшей приложения Next.js в конце прошлого года. Для предприятия, активно использующего Next.js, ошибка в базовом компоненте вызывает не одно оповещение. Она каскадом распространяется на микро-фронтенды, внутренние инструменты и публичные приложения, мгновенно создавая тысячи изолированных находок в сотнях репозиториев и образов контейнеров.
Без контекста команды AppSec остались бы с огромным бэклогом уязвимых пакетов, не имея возможности определить, какие экземпляры действительно можно эксплуатировать.
Имея правильный контекст, организации могут обнаружить каждый экземпляр уязвимого компонента и немедленно приоритизировать те, которые связаны с приложениями, доступными из интернета, или рабочими нагрузками, имеющими доступ к конфиденциальным данным.
Wiz Code предоставляет именно эту возможность, связывая результаты ваших существующих сканеров AppSec с данными об облачной экспозиции, аналитикой среды выполнения и даже состязательным тестированием для приоритизации критических рисков. Основа из контекста — это также то, что позволяет командам безопасности получить широкую видимость рисков приложений во всей корпоративной инфраструктуре и дать разработчикам возможность устранять их на машинной скорости.
Давайте разберемся, как организации могут настроить ASPM в Wiz.
Максимизация инвестиций в существующие сканеры
Первый шаг — перенос ваших существующих инструментов AppSec в Wiz. Независимо от того, стандартизируете ли вы полностью использование собственных сканеров Wiz Code (для SAST, SCA, IaC и секретов) или используете гибридную экосистему, Wiz обеспечивает гибкость для приема и контекстуализации всех ваших результатов безопасности приложений без необходимости полной замены инструментов.
Традиционно создание единой панели мониторинга рисков для нескольких сторонних инструментов требует огромных затрат на интеграцию. Но с помощью Wiz Integration Network (WIN) мы обеспечиваем готовую поддержку популярных решений AppSec, таких как Snyk, Checkmarx, GitHub Advanced Security и других.
Вы можете развернуть эти управляемые Wiz коннекторы с доступом к API только для чтения и настроить их на автоматическое получение соответствующих результатов. Wiz берет на себя подключение к API, нормализацию данных и обогащение. Это дает вашей команде мгновенную видимость рисков SAST, SCA, DAST и секретов без написания или поддержки пользовательских скриптов интеграции.
Пользовательские интеграции
Если вы используете собственный сканер или инструмент без встроенного коннектора, вы все равно можете передать эти данные в Wiz через импорт файлов SARIF. Static Analysis Results Interchange Format, или сокращенно SARIF, — это стандартный формат файлов на основе JSON, используемый для хранения и обмена результатами работы инструментов статического анализа кода в нормализованной структуре. Поэтому, если ваша команда безопасности использует собственное решение для анализа кода, они все равно могут воспользоваться преимуществами обогащения, приоритизации и управления жизненным циклом в Wiz.
Сопоставление безопасности приложений с облачными ресурсами
Как только ваши коннекторы станут активными, Wiz начнет получать данные, генерируемые вашими сканерами. Вы можете просмотреть их на странице «Импортированные активы» (Imported Assets) в вашем инвентаре.
Каждая строка в этой таблице представляет взгляд вашего стороннего сканера на актив. Например, ветка репозитория, просканированная Semgrep или Checkmarx, или образ контейнера, просканированный Snyk. В таблице отображаются имя актива, исходный сканер, классификация и статус сопоставления.
Важно отметить, что инструменты AppSec часто используют совершенно разные соглашения об именовании для одного и того же репозитория. Именно здесь сопоставление активов Wiz служит первым уровнем дедупликации. Вместо создания разрозненных ресурсов для каждой ветки для каждого сканера, Wiz автоматически сопоставляет их с существующими ресурсами в Wiz и добавляет стороннюю информацию в качестве обогащения существующей сущности графа. Если Wiz еще не знает о ресурсе, из актива сканера создается новый ресурс графа. Это очищает ваш инвентарь и предотвращает ненужный шум, позволяя вам выполнять обычные действия с ресурсами графа, такие как добавление их в проекты Wiz или запуск рабочих процессов.
Этот механизм является основой для настоящего анализа «от кода до облака». Традиционные сканеры AppSec фокусируются на коде. Они не могут сказать вам, генерирует ли уязвимый репозиторий образ контейнера, развернутый в вашей среде и доступный из интернета.
Wiz развивает эту модель. Она берет изолированную находку в ветке репозитория, независимо от источника сканера, отслеживает ее до образа контейнера, в который она была собрана, и связывает ее с точной рабочей нагрузкой, где эта находка в данный момент выполняется. Команды безопасности получают мгновенный контекст о том, где уязвимый код находится в реальности, без какого-либо ручного поиска.
Критически важно, что эта корреляция является механизмом, позволяющим Wiz обогащать внешние результаты анализа контекстом облачной среды в реальном времени. Это создает основу для автоматизированной приоритизации и дедупликации на уровне находок, которые мы рассматриваем во второй части этой серии.
Отображение покрытия и устранение «слепых зон»
Корпоративные команды AppSec часто сталкиваются с фундаментальным вопросом: все ли наши репозитории действительно сканируются? В сложных средах с множеством команд разработки «слепые зоны» приводят к неустраненным рискам, а избыточное сканирование создает ненужный шум и тратит ресурсы впустую.
Как только ваши коннекторы активированы, а активы сопоставлены, инвентаризация репозиториев кода (Code Repositories) предоставляет вам единое представление о покрытии сканерами.
Вместо догадок вы получаете четкое представление по каждому репозиторию о том, что именно происходит в вашей кодовой базе.
Для каждого репозитория вы можете увидеть:
- Активные инструменты сканирования: какие инструменты AppSec активно сканируют каждый репозиторий (например, Snyk, SonarQube, Checkmarx, собственные сканеры Wiz Code или инструменты, встроенные в VCS).
Активные инструменты сканирования: какие инструменты AppSec активно сканируют каждый репозиторий (например, Snyk, SonarQube, Checkmarx, собственные сканеры Wiz Code или инструменты, встроенные в VCS).
- Покрытие и пробелы: какие типы находок охвачены (SAST, SCA, секреты, IaC) и где существуют критические пробелы.
Покрытие и пробелы: какие типы находок охвачены (SAST, SCA, секреты, IaC) и где существуют критические пробелы.
- Объем находок: точное количество открытых находок по каждой категории от каждого сканера.
Объем находок: точное количество открытых находок по каждой категории от каждого сканера.
Вы можете использовать этот обзор, чтобы выявить репозитории, где не ведется активное SAST-сканирование или где сканирование секретов выполняется одним инструментом, но отсутствует в других. Отобразив покрытие, ваша команда сможет устранить «слепые зоны», выявить избыточные инструменты в одном репозитории и обеспечить соблюдение единых стандартов безопасности во всех проектах разработки.
Далее: приоритизация критических рисков с учетом контекста
Сбор существующих данных AppSec на одной платформе и отображение покрытия — это важнейший первый шаг. Однако одной лишь видимости недостаточно для решения проблемы усталости от уязвимостей, вызванной ускоренной разработкой с помощью ИИ. Командам безопасности нужен контекст, чтобы понимать, что исправлять в первую очередь.
Во второй части этой серии мы подробно рассмотрим, как Wiz обогащает ваши сторонние результаты, автоматически удаляет дублирующиеся оповещения от разных сканеров и использует Security Graph для отслеживания изолированных недостатков до реальных, эксплуатируемых векторов атак.
