Как выстроить безопасную разработку в эпоху ИИ-агентов: от SAST до DAST

Развитие ИИ меняет подходы к разработке ПО: агентский цикл разработки (ADLC) с использованием ИИ‑агентов постепенно вытесняет традиционные методологии (SDLC). Но вместе с возможностями появляются и новые риски — а значит, нужны эффективные меры кибербезопасности.

Как ИИ-агенты меняют цикл разработки

В традиционном SDLC центральным артефактом остаётся исходный код. Архитектурные документы и спецификации описывают намерения команды, но могут обновляться с задержкой. Код при этом должен оставаться рабочим, актуальным и протестированным.

ИИ-агенты меняют эту модель. В ADLC возрастает роль двух других элементов:

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

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

Агенты также проникают в смежные процессы: ревью, CI/CD, мониторинг, эксплуатацию и безопасность. Чем больше систем и инструментов доступно агенту, тем больше действий он способен выполнять самостоятельно — и тем шире потенциальная поверхность атаки.

Какие риски появляются в агентской разработке

Разработчики давно используют сторонние библиотеки, фреймворки, SDK и API. ИИ-агенты добавляют к ним новые точки взаимодействия: модели, базы знаний, плагины, MCP-серверы и другие инструменты.

Если сильно упрощать, ИИ-агент состоит из трёх компонентов:

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

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

Отдельную опасность представляют атаки на цепочку поставки. На вебинаре мы разбирали компрометацию пакетов Nx за август 2025 года. Вредоносные версии пакетов сканировали системы пользователей в поисках чувствительных данных, пытались задействовать локальные ИИ-инструменты и загружали найденную информацию в публичные репозитории GitHub.

Этот инцидент показал, что агентские инструменты могут использовать как разработчики, так и вредоносный код. Одновременно растут скорость разработки, количество зависимостей и объём автоматизации. Поэтому простой проверки перед релизом уже недостаточно.

Guardrail вместо блокирующего gateway

Безопасность часто воспринимают как gateway: пока команда не исправит все замечания, она не сможет продолжить разработку или выпустить новую версию.

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

В SourceCraft Security используется другой принцип — guardrail. Это система ограничений и подсказок, встроенная в повседневную работу команды. Она помогает двигаться по безопасному пути, но не требует превращать каждое предупреждение в немедленный блокер.

Особенно важен такой подход при первом подключении анализаторов. Команда может действовать постепенно:

• собирать результаты проверок;
• оценивать реальное количество проблем;
• определять их критичность и применимость;
• устанавливать блокирующие пороги для наиболее опасных находок.

Этот подход используют при внедрении динамического анализа: сначала сканирование можно запускать в информационном режиме, а затем постепенно усиливать политику.

Какие проверки объединяет SourceCraft Security

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

Базовый контур безопасной разработки состоит из четырёх частей:

• Сканирования секретов.
• Анализа зависимостей SCA.
• Статического анализа кода SAST.
• ИИ-триажа обнаруженных проблем.

Сканирование секретов

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

Сканирование секретов в SourceCraft проверяет коммиты в истории репозитория и помогает находить такие данные. Результаты доступны как для отдельного проекта, так и на уровне организации.

Проверки важно запускать не только для основной ветки, но и для пулл-реквестов. Тогда команда получает предупреждение до того, как секрет или небезопасное изменение попадёт в основную кодовую базу.

Анализ зависимостей SCA

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

Анализ зависимостей помогает определить:

• какие зависимости используют в проекте;
• какие известные уязвимости есть в этих компонентах;
• как зависимости связаны друг с другом;
• какие пакеты несут лицензионные риски;
• какие репозитории затрагивает проблемный компонент.

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

Так, на вебинаре SCA обнаружил в подключённых репозиториях 33 857 уникальных уязвимостей. Но не каждая из них обязательно доступна для эксплуатации. Такие проблемы всё равно требуют оценки: зависимости и способы их использования со временем меняются.

Статический анализ кода SAST

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

Статический анализ кода в SourceCraft поддерживает встроенные и пользовательские анализаторы. Результаты собираются в общем разделе безопасности и могут отображаться непосредственно в пулл-реквестах.

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

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

ИИ-триаж уязвимостей

Триаж — это разбор результатов сканирования. Команде нужно понять:

• действительно ли обнаружена уязвимость;
• насколько она применима к конкретному проекту;
• можно ли использовать её в текущем контексте;
• не ложное ли это срабатывание;
• как можно исправить код.

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

ИИ-триаж SourceCraft анализирует находку с учётом контекста репозитория, помогает оценить её применимость и предлагает рекомендации по исправлению.

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

Почему SAST и SCA недостаточно

Сканирование секретов, SCA и SAST работают с репозиторием, зависимостями и исходным кодом. Но часть проблем возникает только после запуска приложения.

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

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

Таким образом, SAST и DAST отвечают на разные вопросы и дополняют друг друга:

Как работает динамический анализ

DAST-сканирование можно разделить на два основных этапа.

1. Сбор и анализ поверхности атаки

Сканер ищет точки входа, через которые приложение принимает данные. Для этого SolidPoint DAST может использовать:

• статический и динамический краулеры;
• анализ клиентского JavaScript-кода;
• спецификации OpenAPI;
• сохранённый HTTP-трафик;
• другие источники информации об эндпоинтах.

Чем полнее описана поверхность атаки, тем больше потенциально уязвимых точек сможет проверить сканер.

2. Проверка обнаруженных эндпоинтов

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

Что важно для интеграции DAST в CI/CD

Чтобы динамический анализ стал частью процесса разработки, недостаточно периодически запускать сканер вручную. Инструмент должен работать в автоматизированном CI/CD-процессе.

Автоматический запуск

Сканирование должно запускаться из CI/CD-конфигурации через CLI, HTTP API или другой программный интерфейс.

Доступ к развёрнутому приложению

DAST отправляет реальные HTTP-запросы, поэтому проверять можно только работающую версию приложения. В CI/CD-пайплайне динамический анализ размещают после развёртывания свежей версии в тестовом или другом предназначенном для проверки окружении.

Настройка аутентификации

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

• куки;
• HTTP-заголовки;
• данные HTTP Basic Authentication;
• значения локального хранилища;
• клиентский TLS-сертификат.

Для длительного сканирования также важно проверять, остаётся ли сессия активной, и при необходимости обновлять её.

Ограничения сканирования

Команда должна контролировать количество запросов и исключать эндпоинты, обращение к которым может запустить нежелательную операцию или затронуть критичную интеграцию.

Отображение прогресса и результатов

Разработчику или DevOps-инженеру важно видеть статус проверки в CI/CD-интерфейсе. Итоговый отчёт можно использовать как самостоятельный документ или передавать в другую систему в машиночитаемом формате, например JSON.

Три способа настроить SolidPoint DAST

На вебинаре мы рассматривали три сценария — от минимальной конфигурации до расширенной проверки сложного приложения.

Базовое сканирование

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

Для постепенного внедрения предусмотрен неблокирующий режим. В нём сканирование находит и показывает проблемы, но не останавливает CI/CD-процесс. Команда сначала оценивает объём накопленных уязвимостей, а затем настраивает более строгие правила.

Сканирование заранее настроенной цели

Если приложению нужна аутентификация, цель можно создать и настроить через CLI. Она получает идентификатор, который затем используется при запуске проверки.

Такой подход позволяет один раз сохранить параметры приложения, а в CI/CD-процессе передавать только идентификатор цели.

Расширенная настройка

Для сложных сценариев цель можно подготовить через пользовательский интерфейс или REST API. К базовым возможностям добавляются спецификации OpenAPI, ограничения частоты запросов и исключение отдельных URL.

После предварительной настройки сканирование также запускается из CI/CD одной командой.

Как подключить SolidPoint DAST к CI/CD SourceCraft

Интеграция состоит из семи шагов. Необходимо:

1. Создать интеграционный токен SolidPoint.
2. Сохранить токен в секретах репозитория SourceCraft.
3. Выбрать сценарий и политику сканирования.
4. Описать запуск SolidPoint CLI в CI/CD-конфигурации.
5. Развернуть проверяемую версию приложения.
6. Запустить сканирование, а затем отслеживать прогресс в логах.
7. Получить результаты и провести триаж находок.

В конфигурации CI/CD используют образ SolidPoint, адрес инсталляции сканера и интеграционный токен из секретов SourceCraft.

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

Найденной уязвимости можно присвоить статус, подтвердить её, отметить регрессию или изменить уровень критичности. Результаты также можно получить в JSON и передать во внутреннюю систему управления уязвимостями.

Зачем анализаторам общий контекст

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

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

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

Как начать внедрение безопасного ADLC

Переход к безопасной агентской разработке можно разбить на несколько этапов:

1. Определите доступы агентов. Зафиксируйте, с какими репозиториями, инструментами, секретами и внешними системами они могут работать.
2. Включите проверки репозиториев. Начните с поиска секретов, анализа зависимостей и SAST.
3. Запускайте анализ в пулл-реквестах. Это поможет обнаруживать проблемы до попадания изменений в основную ветку.
4. Определите приоритеты. Разделите критичные находки и предупреждения, которые требуют дополнительного анализа.
5. Используйте ИИ-триаж как помощника. Он ускоряет разбор, но не заменяет решение разработчика.
6. Добавьте DAST после развёртывания. Проверяйте работающую версию приложения и доступные сканеру HTTP-интерфейсы.
7. Начните с неблокирующего режима. Соберите статистику и только затем вводите жёсткие пороги.
8. Регулярно пересматривайте политики. Учитывайте изменения кода, зависимостей, инфраструктуры и возможностей агентов.

Вопросы и ответы

Безопасность как часть среды разработки

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

SourceCraft Security помогает искать секреты, анализировать зависимости и исходный код, объединять результаты статических проверок и проводить ИИ-триаж. SolidPoint DAST можно подключить к CI/CD SourceCraft, чтобы после развёртывания проверить внешние HTTP-интерфейсы приложения.

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