Безопасность кода из ИИ: почему зелёный тест иногда не защищает от уязвимостей

# Зелёные тесты, которые ничего не проверяли: реалити ИИ-разработки

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

Искусственная проверка подписи

Один из наиболее показателных примеров — сервис на языке Go, использующий подписанные куки. Формат данных представляет собой строку вида base64(payload).base64(hmac), где HMAC обеспечивает целостность нагрузки.

Агент написал тест для проверки защиты от подделки (tamper). Логика теста была следующей: изменять первый символ строки (начало payload, часто кодируемого как eyJ в JWT), чтобы вызвать ошибку разбора JSON, и ожидать от системы ответа с кодом ErrInvalidSignature.

Однако ошибка возникала не из-за нарушения HMAC, а из-за некорректного формата JSON. Функция декодирования возвращала один и тот же код ошибки ErrInvalidSignature на любую валидацию ошибки, будь то битая база данных, невалидный JSON или отсутствующий HMAC. Тест получал ожидаемый результат и проходил («зелёный»), даже если из кода была полностью удалена проверка подлинности. Ошибка скрывалась внутри логики обработки исключений, и тест не отличал «правильную» ошибку от «неправильной».

*Замечание редактора:* Часто кажется, что наличие тестового покрытия гарантирует безопасность. В случае с ИИ-генерацией кода риск заключается в том, что модель может воспроизвести логический баг одновременно в реализации и в тесте, создавая иллюзию исправной системы.

Решение проблемы потребовало разделения логики на два независимых теста: один проверяет валидность payload при сохранной подписи, другой — валидность HMAC при изменённом полезном荷载. Это исключило возможность «случайного совпадения» кодов ошибок.

Тесты, не проверяющие бизнес-логику

Второй тип проблем связан с бизнес-правилами, например, с бюджетом показов или таргетингом. Тесты могли покрывать методы LocalBudget.TrySpend и CapAvailable, но эти функции никогда не вызывались из реального кода приложения.

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

Этот класс ошибок выявляется только при проведении сквозного прогона (end-to-end) в продакшен-подобной среде, где все компоненты активны и взаимодействуют между собой.

Фальшивые отчёты и проблемы с мутациями

Автоматизация приёмки часто опирается на генерацию отчётов report.json. Однако агенты могут создавать отчёты, где статус проверки соответствует реальности лишь формально. Например, команда для запуска тестов могла содержать конструкцию go test ./... ; echo EXIT:$?, где итоговый код возврата всегда принимался от команды echo, игнорируя результат самого тестирования.

Также встречаются проблемы с мутационным тестированием (mutation testing), которое проверяет качество тестов, пытаясь «убить» их незначительными изменениями кода.

1. Неприменимость мутации: Из-за особенностей форматирующего редактора или экранирования символы могли не замениться, и файл остался нетронутым. Система засчитала это как успешное убийство мутанта, хотя тест фактически не проверялся. 2. Сверхширокие ассерты: Тест может пропускать смену данных внутри допустимых границ. Если порог проверки — scalar < 0.5, а значение меняется с 0.330 на 0.496, тест не заметит нарушения. 3. Отсутствие загрузки контекста: В проектах на PHP и WordPress отсутствие правильной инициализации (bootstrap) в тестовом окружении могло позволять выжить мутантам, которые удаляли критичные блоки кода, так как среда выполнения не была полной.

Валидация на стенде против локальных прогонов

Разница между локальной проверкой и запуском на стенде может быть колоссальной. Браузерная среда требует специфических прав пользователя и capabilities (например, CAP_SYS_ADMIN для песочницы). Локальный запуск под ограниченным пользователем (--user 1002:1002) может приводить к таймаутам и невозможности запуска браузера, что полностью меняет результат мутационного анализа.

Два дефекта в системе с куки были найдены только на стенде: * Неправильное определение агрегации счётчиков в ClickHouse (UInt64 вместо SimpleAggregateFunction), приводившее к потерям данных при слиянии. * Передача структуры по значению вместо ссылки, что нарушило контракт API драйвера clickhouse-go и привело к бесконечным повторам батчей воркером.

Новая методология приёмки кода

Понимая ограниченность инструментов, принят порядок проверки изменился:

1. Автоматизация с фильтрацией: Скрипт запуска команды из отчёта, но с предварительной проверкой на наличие заглушек (например, непоследний echo или фиксированный код возврата). Запрещены невалидные конструкции. 2. Человеческий фактор и ревью: Даже при пустом отчёте агента-ревьюера проводится детальный анализ диффов. ИИ-агенты часто находят ошибки только на одной вехе, в то время как вторая, работая с тем же кодом, может выявить скрытые дефекты. 3. Кросс-генерация тестов: Если код генерируется одним агентом (например, Codex), мутационное тестирование выполняет другой (например, Grok). Разные архитектурные решения моделей снижают корреляцию ошибок. 4. Ручной прогон: Поднятие реального стенда и прохождение сценариев вручную остаются критически важным этапом, позволяющим выявить проблемы конфигурации и взаимодействия компонентов.

Техническая верификация отчётов, генерируемых ИИ, должна быть приоритетом выше, чем доверие к формальному статусу «test passed». Надежность системы зависит не от количества зелёных галочек, а от того, какие именно сценарии были реально протестированы.