Может ли ИИ-тестирование безопасности заменить SAST, DAST и пентесты?

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

Проверка агентом - это интерпретация, а не новый класс тестирования

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

Это различие важно, когда поставщик говорит, что его агент «заменяет сканеры». Спросите, что система действительно может наблюдать. Получает ли она весь репозиторий, сгенерированный код, флаги сборки, инфраструктурные политики и lock-файлы зависимостей? Может ли она войти под несколькими пользователями и проверять состояние базы данных после каждого запроса? Знает ли она, какие действия запрещены политикой, а не просто отсутствуют в интерфейсе? Красивое объяснение не компенсирует отсутствующие входные данные.

Агенты действительно хорошо объединяют слабые сигналы. Обычное правило может отметить параметр запроса, который попадает в конструктор запроса. Агент способен проверить обертку, заметить, что в одном месте вызова пропущен предикат арендатора, подготовить тестовый запрос и объяснить, почему якобы безопасный помощник небезопасен в этом пути. Он также может отклонить кандидата, если значение проходит через настоящий параметризованный API. Это более качественный разбор, а не доказательство того, что статический или динамический анализ устарел.

Четкая граница проходит между проверкой и подтверждением. Проверка спрашивает: «Выглядит ли эта реализация небезопасной с учетом доступных мне материалов?» Подтверждение спрашивает: «Может ли этот субъект при заданных условиях вызвать запрещенный результат?» ИИ помогает в обоих случаях, но шлюз безопасности должен фиксировать, какое именно утверждение он делает. Команды страдают, когда красноречивое наблюдение при проверке выдают за подтвержденный эксплойт или когда одну неудачную попытку эксплуатации принимают за доказательство безопасности.

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

SAST по-прежнему дает воспроизводимое покрытие исходного кода

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

Агент добавляет контекст, которого часто не хватает движку правил. Он может проходить по специфичным для проекта оберткам, критически читать комментарии, сравнивать обработчик с соседними обработчиками и предлагать запрос для нового паттерна. Он замечает подозрительные пропуски: например, девять конечных точек вызывают authorizeProject(), а десятая напрямую загружает запись. Он полезен и тогда, когда сгенерированный код или незнакомый фреймворк побеждают стандартный набор правил.

Но охват исходного кода агентом обычно сложнее доказать. Окна контекста, ранжирование поиска, игнорируемые файлы, сгенерированные артефакты и тайм-ауты инструментов могут оставить часть кода непрочитанной. Запрос «проверь этот репозиторий на инъекции» не доказывает, что достигнут каждый приемник. Отчет SAST хотя бы может указать, какие файлы, правила и ревизия были проанализированы. Прежде чем агент заменит обязательный шлюз, ему нужен равноценный журнал покрытия.

NIST SP 800-218 дает здесь здравую рекомендацию: применяйте анализ кода на раннем этапе и вручную проверяйте функции безопасности и меры защиты. Ценность дает сочетание. Стабильные правила ловят известные формы дефектов в каждом коммите, а агент исследует исключения, пишет целевые регрессионные тесты и помогает настраивать правила, когда один и тот же паттерн повторяется. Отказ от SAST потому, что агент нашел несколько хитрых ошибок, меняет измеримую широту покрытия на впечатляющие истории.

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

Есть ограничения на то, что должно становиться блокирующим правилом SAST. Точный паттерн для запрещенного криптографического примитива можно блокировать сразу. Широкая эвристика, которая спрашивает, «достаточно ли похожа» проверка авторизации, обычно должна создать задачу на проверку, пока команда не измерит ее точность. Агенты могут помочь превратить эвристику в правило, собрав верные примеры, контрпримеры и распространенные функции-обертки в этой кодовой базе. Так шлюз останется строгим, а разработчики не привыкнут его игнорировать.

Сгенерированные исправления требуют такой же внимательной проверки, как и находки. Модель может заглушить след taint-анализа, добавив проверку в неправильном слое, поймать исключение и открыть доступ при ошибке либо заменить опасный вызов, изменив поведение. Запустите исходное доказательство на патче, обычные функциональные тесты и проверьте новый контроль в месте, где устанавливается доверие. Чистое повторное сканирование доказывает только, что исходное правило больше не совпадает.

DAST подтверждает поведение, которое репозиторий не покажет

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

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

Агенту все равно нужны строгие рабочие ограничения. Сканер не знает, безопасно ли отправить письмо, создать отправку или вызвать платную интеграцию. Даже тестовая среда может подключаться к реальным сервисам. Определите допустимые хосты, учетные записи, частоту запросов, разрушительные действия и условия остановки вне промпта модели, затем обеспечьте их соблюдение в средстве запуска. Фраза «избегай опасных действий» не служит контролем.

Сохраняйте обычную динамическую базу для понятных проверок: заголовков безопасности, открытых файлов, отраженного ввода, типовых проб инъекций и конфигурации TLS. Эти проверки недороги, сопоставимы между релизами и по ним легко отслеживать тенденции. Пусть агент тратит ресурсы на аутентифицированные пути и связанные действия. Если обе системы покрывают одну простую пробу, оставьте ту, у которой яснее доказательства и ниже разброс результатов.

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

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

Динамическое повторное тестирование должно начинаться с сохраненной последовательности запросов, а не с нового автономного обхода. Повторите подтвержденное доказательство на сборке с исправлением, убедитесь, что запрещенный эффект прекратился, затем меняйте соседние входные данные, чтобы выявить слишком узкий фильтр. После этого дайте агенту исследовать дальше. Такой порядок отделяет утверждение «исправление блокирует известный эксплойт» от более широкого утверждения, что класс дефектов устранен.

Для тестов авторизации нужны учетные записи и запрещенные результаты

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

OWASP ASVS говорит, что приложения должны обеспечивать контроль доступа в доверенном сервисном слое и применять принцип наименьших привилегий к функциям и данным. Я согласен с требованием сервисного слоя, но команды часто проверяют его слишком узко. Они тестируют видимый HTTP-обработчик и забывают о фоновых задачах, экспортах, поисковых индексах, подписках websocket и прямых URL хранилища объектов. Одна и та же политика должна сохраняться на любом пути к объекту.

Небольшая исполняемая матрица показывает больше, чем расплывчатое указание «проверить IDOR». Следующий фрагмент shell предполагает изолированную среду, два bearer-токена и документ, принадлежащий пользователю A. Он проверяет и статус, и отсутствие секретного маркера A в ответе для B:

base_url="https://test.example.invalid"
doc_id="d_1042"

curl -sS -D /tmp/headers.txt \
  -H "Authorization: Bearer $TOKEN_B" \
  "$base_url/api/documents/$doc_id" \
  -o /tmp/body.json

status="$(awk 'NR==1 {print $2}' /tmp/headers.txt)"
test "$status" = "403" || test "$status" = "404"
! grep -q "A_ONLY_MARKER" /tmp/body.json

Ожидаемый результат - отсутствие вывода и код завершения ноль. При сбое CI должны сохраняться статус, очищенное тело ответа, действующая учетная запись, владелец целевого объекта, маршрут и ревизия сборки. Не сохраняйте действующие учетные данные или посторонние данные ответа.

Теперь меняйте по одному измерению: чтение или обновление, прямой идентификатор или поиск, активное или отозванное членство, обычный маршрут или экспорт, пользовательский токен или сервисный токен. Агент может эффективно создавать и запускать эти случаи. Человек должен проверить, соответствует ли матрица политике и будет ли правильным результатом 404, 403, пустой ответ или объект с вырезанными данными. Иначе агент может порадоваться поведению, которое бизнес считает нарушением.

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

Проверяйте и смену политики во время сессии. Удалите пользователя из проекта, передайте владение, отключите учетную запись или сузьте сервисную роль, затем повторно используйте старые токены и открытые подключения. Ожидаемое время отзыва должно следовать из политики продукта. «Когда-нибудь» нельзя протестировать, а немедленный отзыв может быть не нужен, но команда должна выбрать срок и проверить его для API-запросов, задач в очереди, скачиваний и активных подписок.

Изоляция арендаторов нарушается вне очевидного пути запроса

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

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

Агенты полезны, потому что могут проследить идентификатор через слои и создать утомительные для человека перестановки. Они могут заметить, что ключ кэша использует document_id, а запрос к базе данных использует и tenant_id, и document_id. Они могут сравнить обработчик экспорта с интерактивным обработчиком и спросить, почему только один из них задает контекст на уровне строк. Это ценные действия при проверке.

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

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

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

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

Бизнес-логике нужна история о злоупотреблении

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

OWASP Web Security Testing Guide предлагает тестировщикам пробовать пропускать шаги процесса, повторять функции, подделывать запросы, менять время и неправильно использовать допустимые возможности. В более старом введении о бизнес-логике прямо сказано, что автоматизация сканерами не может дать знания и творческий подход, зависящие от конкретного приложения. Современные агенты улучшают автоматизацию, но не устраняют нехватку знаний. Модель может предположить, что купон можно использовать повторно, но не знает, акция это или мошенничество, пока кто-то не задаст правило.

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

Самые трудные случаи связаны с последствиями за пределами HTTP-ответа. Два одновременных запроса на погашение могут оба вернуть успех, хотя последующая сверка отменит один из них. Отмена может остановить видимую задачу, но не отозвать подписанную ссылку на скачивание. Принятое приглашение после потери доступа пригласившим может создать членство без владельца. Тесты должны наблюдать журналы учета, очереди, разрешения объектов и позднее состояние, а не только коды статуса.

Тестировщики-люди ценны тем, что оспаривают заданную модель. Они спрашивают, могут ли сотрудники поддержки соединить безобидные функции, может ли оператор повлиять на собственный журнал аудита или остается ли «истекший» объект доступным по другому каналу. Агент работает внутри полученных целей и инструментов. Человек способен заметить, что в целях пропущена опасная часть бизнеса.

Риск зависимостей не сводится к уязвимой версии

Тестирование зависимостей состоит из четырех разных вопросов: какие пакеты присутствуют, имеют ли их известные версии заявленные уязвимости, получила ли сборка предусмотренные артефакты и действительно ли приложение открывает уязвимое поведение. Анализ состава программного обеспечения (SCA) и контроль происхождения надежнее отвечают на первые три вопроса, чем одна разговорная проверка.

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

Не просите модель вспоминать актуальные данные об уязвимостях. Передайте ей источник рекомендаций с меткой времени, разрешенный lock-файл и инвентарь собранных артефактов. Память модели не служит базой данных уязвимостей, а манифест пакета не доказывает, что именно попало в поставку. SLSA provenance проводит похожее различие: происхождение описывает, где, когда и как был создан артефакт. Оно не объявляет артефакт безопасным.

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

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

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

Ложные срабатывания - это проблема устройства доказательств

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

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

Затем применяйте простой словарь решений: подтверждено, вероятно, нужен контекст, не воспроизводится, принятый риск или исправлено. «Ложное срабатывание» должно означать, что утверждение о безопасности неверно, а не то, что команде не нравится серьезность или она решила отложить работу. Смешение этих решений разрушает обратную связь. Агент не может понять, какое правило не сработало, если каждой нежелательной задаче дают одну и ту же метку.

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

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

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

Конфиденциальность важна и при разборе. Исходный код, тела запросов, журналы и образцы базы данных могут содержать учетные данные или данные клиентов. Сокращайте объем данных, передаваемых агенту, очищайте сохраняемые расшифровки, отделяйте тестовые данные от производственных и применяйте утвержденные в организации правила обработки данных к поставщику модели и его инструментам. Более точное выявление не оправдывает копирование всего производственного инцидента в неконтролируемый промпт.

Пентестер-человек проверяет допущения вокруг теста

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

Люди также отвечают за суждения при неполных доказательствах. Они отличают технически возможное действие от правдоподобного пути атаки, объясняют составной сбой руководителям и инженерам и согласовывают безопасное доказательство, когда эксплуатация способна повредить данные. Автономный агент обязан остановиться на границе, заданной оператором. Если он молча расширяет эту границу, он сам становится риском безопасности.

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

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

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

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

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

Соберите один шлюз из нескольких видов доказательств

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

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

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

Для приложений, созданных через чат, действует то же разделение. Koder.ai может создавать веб-, серверные и мобильные приложения и экспортировать их исходный код, но сгенерированному ПО все равно нужны явные требования безопасности и независимые тесты развернутого результата. Быстрое создание делает четкий шлюз еще полезнее, потому что архитектура и код могут быстро меняться.

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

Не спрашивайте, какой один инструмент побеждает. Спросите, есть ли для каждого важного утверждения независимые доказательства: путь кода проверен, поведение развернутого приложения испытано, бизнес-правило получено от владельца и человек оспорил допущения там, где сбой причинит вред. Если хотя бы одна из этих строк пуста, созданное ИИ «все чисто» ее не заполнит.