38,9% ИИ-сгенерированных pull request'ов содержат security smell: как ловить их до мёржа
Исследование от июля 2026 года на 4022 реальных pull request, сгенерированных пятью разными кодовыми агентами, нашло security smell в 38,9% из них. Это не гипотетический риск из презентации вендора. Это измеренная частота на реальной активности в GitHub, и большая часть найденного это не тот экзотический класс уязвимостей, который обычно представляют, когда говорят «ИИ пишет небезопасный код».
Что именно измерило исследование
«Trust but Verify? Uncovering the Security Debt of Autonomous Coding Agents» проанализировало 4022 pull request по 16 112 файловым изменениям, взятым из датасета AIDev с PR от пяти разных кодовых агентов. Исследователи использовали две открытые LLM в роли судей (Qwen3.6-35B и Gemma-4-26B), а затем вручную проверили золотой стандарт из 376 файловых изменений с независимой сверкой, чтобы убедиться, что автоматическая оценка держится.
Главная цифра: 38,9% PR (1563 из 4022) содержали хотя бы один security smell. На уровне файловых изменений частота ниже, 23,6% (3807 из 16 112), и это важно для правильного прочтения цифры 38,9%: дело не в том, что два из пяти файлов, к которым прикасается агент, рискованны, а в том, что в двух из пяти PR есть хотя бы одно рискованное изменение, часто сконцентрированное, а не равномерно размазанное.
Какой именно security smell
Распределение это как раз то, что стоит усвоить, прежде чем предполагать, будто это значит «агенты пишут SQL-инъекции». Проблемы с целостностью цепочки поставок составили 82,3% всех найденных smell'ов: незафиксированные версии зависимостей, отсутствующие записи в lockfile, ссылки на пакеты, которые резолвятся по-разному в зависимости от момента установки. Это доминирующая категория с большим отрывом, а не длинный хвост рядом с более драматичными классами уязвимостей.
Исследование также нашло деталь, которая держит картину в правильных пропорциях: люди вносили больше реально утёкших credentials, чем агенты, 67,6% именно в этой конкретной категории. Агенты не уникально плохи в безопасности. Они достаточно продуктивны, чтобы какая бы ни была частота ошибок на PR, она проявлялась в объёме, которого раньше не производил ни один чисто человеческий воркфлоу, а сама частота ошибок концентрируется в гигиене зависимостей и цепочки поставок, а не в классических багах инъекции.
Чек-лист перед мёржем, который соответствует тому, где риск реально концентрируется
Учитывая, где реально сидят эти 82,3%, гейт ревью, нацеленный абстрактно на «это написал ИИ, проверь на уязвимости», в большинстве случаев проверяет не то. Гейт, нацеленный сначала на целостность цепочки поставок, ловит основную массу того, что нашло это исследование:
- Зафиксированные версии на каждой новой или изменённой зависимости. Не диапазон, а точная версия, сверенная с тем, что реально попало в lockfile.
- Изменения lockfile проверяются как отдельный дифф. Обновление зависимости, спрятанное внутри более крупного функционального изменения, это ровно тот паттерн, который позволяет незафиксированной или неожиданно зарезолвившейся версии проскочить незамеченной.
- Новые зависимости сверяются с allowlist или минимальным порогом по возрасту/распространённости, а не просто «чисто ли устанавливается», потому что свежая компрометация цепочки поставок часто устанавливается чисто вплоть до момента, пока не перестаёт.
- Сканирование credentials и секретов на каждом PR независимо от автора, человек это или агент, потому что находка про утёкшие credentials выше работает ровно в обратную сторону от популярного предположения. Откуда эти утёкшие credentials обычно берутся: чаще всего это общий, слишком широкий токен, а не сам пробел в сканировании.
- Отдельный проход именно по файловым изменениям вне заявленной области PR. Раз smell'ы концентрируются, а не размазываются равномерно (38,9% PR против 23,6% файлов), файл вне заявленной области, тронутый агентским PR, непропорционально стоит второго взгляда.
Где автоматическая тарификация риска реально помогает
Всё это не обязано навсегда оставаться ручным. Конкретная часть задачи, трогает ли дифф манифест зависимостей или lockfile против прикладной логики, это механическое различие, которое инструмент может пометить ещё до того, как человек откроет PR, разделяя «этот PR трогает только тестовые фикстуры» и «этот PR изменил package-lock.json». Что реально требуется от трекера задач для управляемой автономии разбирает этот слой тарификации риска подробнее: смысл не в том, чтобы блокировать каждый агентский PR для ревью человеком, а в том, чтобы направлять внимание ревью, которое и так уже занимает 24% недели разработчика, туда, где security smell статистически вероятен, вместо равномерного распределения по всем диффам независимо от того, что они реально затрагивают.
Цифра 38,9% это повод построить такую маршрутизацию, а не повод притормозить агентские PR по всему фронту. Большая часть найденного скучна, легко чинится и сконцентрирована в предсказуемом месте. Чтобы это ловить, не нужно вычитывать каждую строку, написанную агентом. Нужно сначала смотреть на правильные 20% строк.