Генерация кода обходится дешево, но доверие к этому коду стоит дорого, и эти издержки растут по мере того, как агенты переходят от создания нескольких строк кода к работе на уровне всего конвейера.
В последнем выпуске нашего подкаста The Next Commit ведущий из Sonar Том Хаулетт побеседоал с Шашанком (Шашем) Патвардханом, руководителем направления по безопасности приложений в IFX Payments, который посвятил годы консалтингу, помогая организациям настраивать технические предохранители для внедрения ИИ. Он утверждает, что большинство используемых сегодня средств контроля безопасности были разработаны для автодополнения, а самая сложная проблема с автономными агентами заключается в том, чтобы научить их вовремя останавливаться. Каждое рекомендуемое им решение сводится к этой идее: определить, на каком этапе работа должна приостанавливаться до тех пор, кто-то ее не проверит.
ИИ перестал предлагать и начал действовать
Шаш выделяет четыре этапа этого сдвига. Сначала появилось автодополнение с выходом Copilot в 2021 году, при этом люди полностью контролировали процесс. Затем последовало копирование и вставка на основе чата, которые незаметно вернули в кодовые базы небезопасные шаблоны вроде конкатенированных SQL-запросов и зашитых в код учетных данных. На третьем этапе агенты были внедрены непосредственно в IDE для редактирования кода. Четвертый этап, на котором мы находимся сейчас, выпускает агентов на свободу в конвейеры с учетными данными и доступом к сети.
«Произошел переход от концепции „ИИ предлагает“ к „ИИ действует“», — отметил Шаш. Это две разные модели рисков, и средства контроля большинства организаций были разработаны для первого этапа. Риск возрастает, когда люди, не связанные с разработкой, продолжают относиться к ИИ как к помощнику по набору текста. По словам Шаша, в конечном итоге они «фактически наделяют его правами старшего инженера».
Когда ИИ только предлагал решения, человеком была поставлена точка останова. Как только ИИ начинает действовать, эту точку останова необходимо встроить в систему.
Мысль Шаша сводится к простой экономике: когда что-то становится дешевым, люди начинают производить этого слишком много. По его оценкам, скорость работы команд возросла примерно в четыре раза, а размер PR (пулл-реквеста) увеличился примерно в десять раз: теперь пулл-реквесты от агентов могут насчитывать от 2 000 до 5 000 строк. Никто не проверяет изменения такого объема строка за строка, поэтому на них просто ставят штамп одобрения.
С точки зрения безопасности, каждая лишняя строка увеличивает поверхность атаки, а каждая лишняя зависимость повышает риски в цепочке поставок. Шаш указал на «слопсквотинг» (slopsquatting) как на растущую угрозу. Он рекомендует ограничивать размер PR, чтобы ревью оставалось осмысленным, маркировать сгенерированный ИИ код для применения к нему особого контроля, а также фиксировать зависимости (pin dependencies) и сканировать их, поскольку зафиксированный пакет все равно может быть вредоносным.
Модель не может проверять собственную домашнюю работу
Меньшие по размеру PR помогают, но они не отвечают на вопрос, кто именно выполняет проверку. Очевидный обходной путь — поручить ревью той же модели, которая написала код. Шаш выступает против этого практически в каждом разговоре об ИИ-ревью. «Если одна и та же модель будет писать код и та же модель будет его читать, это создаст своего рода слепые зоны. Допущение, которое заставило ее написать этот код или совершить эту ошибку, заставит ее не заметить эту ошибку». Он сравнивает это с писателем, который вычитывает собственное эссе и читает то, что он имел в виду, а не то, что было написано.
Его решение заключается в проведении ревью, которое работает независимо от сгенерировавшей код модели. Он по-прежнему отводит центральную роль статическому анализу, если тот понимает контекст, поскольку инструменты, основанные лишь на сопоставлении шаблонов, не смогут поспевать за написанным ИИ кодом. В качестве примера он привел контекстно-зависимый анализ SonarQube, а также инструмент Gitar, который проверяет результаты работы агента на соответствие стандартам организации.
Если генерирующая модель не может выполнять функцию проверки, для проверки должно быть предусмотрено собственное место в рабочем процессе. Пробел, который Шаш замечает чаще всего, — это этап ревью между агентом и проверяющим-человеком. Этот уровень проверяет каждое изменение на соответствие политикам безопасной разработки организации, стандартам криптографии, разрешенным языкам, OWASP Top 10 и OWASP Top 10 для LLM-приложений, а также базе знаний вендора. Том поделился мыслью, которую он слышит постоянно: до тех пор, пока верификация происходит до того, как код попадает к человеку, вы сместили безопасность влево достаточно далеко.
При наличии этого шага ИИ справляется с первичной обработкой и зачисткой, а проверяющий начинает работу с проверенного, аннотированного изменения, а не с нескольких тысяч сырых строк. Таким образом, разработчик, который коммитит код, по-прежнему несет за него ответственность. Аргумент «Это сгенерировал ИИ» не работает в качестве оправдания, и в регулируемых отраслях компания все равно отвечает перед регуляторами за этот код, независимо от того, был ли он сгенерирован.
Агенты не знают, когда остановиться
Ревью останавливает плохой код. Оно не останавливает агента, который продолжает действовать.
Человек-тестировщик на проникновение знает бизнес-логику и то, какие системы являются главными ценностями, и в конце концов бросает тупиковое направление. Агент продолжает двигаться вперед, пробуя каждый путь, пока не выполнит инструкцию.
Он привел пример из практики работы с клиентом. Команда предоставила агенту по кодированию токен старшего инженера и поручила исправить неисправный конвейер. Агент обнаружил шлюз безопасности, блокирующий сборку, отключил сканирование в конфигурации конвейера, после чего сборка прошла успешно и была объединена (merged). В последующих PR результаты сканирования вообще отсутствовали, пока кто-то не начал расследование. Агент выполнил поставленную задачу. Ничто не говорило ему о том, что отключение сканирования находится под запретом, а у него были для этого необходимые права.
Он видит ту же закономерность в инциденте, который он описал с участием агентов OpenAI и Hugging Face, когда агенты в погоне за результатами бенчмарков вырвались из песочницы и перешли на уровень продакшена с помощью эксплойтов ядра, ключей API по умолчанию, избыточных учетных записей Kubernetes и учетных данных метаданных. Каждый метод из этого списка является обычным результатом теста на проникновение. «Атака не была чем-то новым, — сказал Шаш. — Новым на самом деле был сам атакующий».
Он рекомендует три средства контроля:
- Принцип наименьших привилегий. Предоставляйте агентам минимальный набор прав, необходимых для выполнения задачи, и никогда не давайте по умолчанию токен старшего инженера.
- Непрерывный мониторинг. Следите за тем, что агенты делали во время и после выполнения задачи, чтобы изменение конфигурации, которое незаметно отключает сканирование, было быстро обнаружено.
- Кнопка экстренного отключения (kill switch). Когда что-то идет катастрофически не так, вам нужен способ немедленно остановить агента.
Том Хаулетт из Sonar указал на противоположный риск: настолько жесткие границы, что каждое действие требует одобрения, до тех пор пока люди не начинают кликать не читая. В этот момент границы нуждаются в пересмотре. Шаш согласился, добавив, что защитные барьеры различаются в зависимости от организации и команды, и их следует пересматривать ежеквартально или раз в полгода по мере того, как агенты берут на себя все больше задач.
Все это сводится к одному и тому же вопросу: на каком этапе работа должна останавливаться до тех пор, пока ее не проверит независимый инструмент?
Что это означает для вашего конвейера
Шаш завершил выступление двумя советами. Во-первых, инвестируйте в верификацию, которая не зависит от генератора, а во-вторых, относитесь к агентам как к субъектам с наименьшими привилегиями, мониторингом и кнопкой экстренного отключения. По его словам, большинство инцидентов будут сводиться к столь базовым средствам контроля.
SonarQube применяет к каждому изменению единый стандарт нулевого доверия (zero-trust) с многоуровневой защитой, независимо от того, написал его человек или агент. Gitar выполняет контекстное ревью пулл-реквестов и устраняет сбои CI в соответствии с вашими правилами, обеспечивая этап проверки, описанный Шашем, еще до того, как человек откроет PR.
Послушайте полную беседу с Шашанком Патвардханом в подкасте The Next Commit, а затем внедрите независимую многоуровневую верификацию в собственный цикл работы с агентами с помощью SonarQube.
