10 признаков опасной AI-правки в pull request

Рабочий код — не значит безопасный: как распознать скрытый риск до merge

Почему PR с AI-кодом опаснее, чем кажется

К 2025 году более 90% разработчиков используют AI-инструменты хотя бы для части своей работы [5]. Microsoft заявила, что 30% кода в ряде её репозиториев написано ИИ [6]. GitHub Copilot, Cursor и аналоги стали нормой, а не экспериментом.

Проблема не в том, что AI пишет плохой код. Как раз наоборот: синтаксических ошибок стало меньше на 76%, а логических багов — на 60% [4]. Проблема в том, что безопасность движется в противоположном направлении: архитектурных уязвимостей стало больше на 153%, а путей для privilege escalation — на 322% [2].

Декабрьский анализ CodeRabbit 470 реальных pull request'ов зафиксировал: AI-соавторский код имеет примерно в 1,7 раза больше серьёзных проблем, чем человеческий [1]. Veracode протестировали более 100 LLM на 80 кодовых задачах в четырёх языках — 45% образцов провалили тесты безопасности и принесли уязвимости из OWASP Top 10 [5].

Ключевой парадокс: именно то, за что мы ценим AI-код (чистота, идиоматичность, отсутствие очевидных ошибок), делает его опаснее при ревью. Код выглядит правильным, тесты проходят, CI зелёный — и проблема оказывается в production.

Корень — в природе LLM. Модели обучаются на миллионах публичных репозиториев, где устаревшие паттерны, учебные упрощения и небезопасные дефолты присутствуют не как исключения, а как норма. Модель не рассуждает об угрозах — она воспроизводит то, что видела чаще всего [7]. Как формулирует Cloud Security Alliance: «AI-кодинг-ассистент не понимает risk-модель вашего приложения, внутренних стандартов или threat landscape» [7].

Ниже — 10 типовых паттернов, которые ревьюер видит как обычную рабочую правку, а security-специалист — как сигнал остановиться.

Признак 1. Лишние права — код «работает», но RBAC сломан

Apiiro исследовали Fortune 50-компании и обнаружили: AI-генерированный код создаёт на 322% больше путей для escalation привилегий [2]. Причина — AI обучен на публичных репозиториях, где permissive access defaults встречаются повсеместно. Модель воспроизводит их без понимания границ доверия [2].

Типичный пример: AI генерирует обработчик admin-роута, который проверяет аутентификацию, но пропускает проверку авторизации. Код проверяет, что вы залогинены. Не проверяет, что у вас должен быть admin-доступ. В итоге любой аутентифицированный пользователь получает доступ к admin-функциям [2].

Что искать в diff:

• Новые роуты или методы без явной проверки роли (role check) на стороне сервера
• Паттерн if (user.isAuthenticated) без if (user.hasRole('admin'))
• Wildcard-разрешения в IAM-конфигах ("Action": "*")
• Поднятие прав сервисного аккаунта без объяснения в описании PR

По данным OWASP Top 10:2025, Broken Access Control сохраняет первое место: 100% протестированных приложений содержат ту или иную форму этой проблемы [8].

Признак 2. Debug-логика, оставленная как «временная»

AI охотно добавляет debug-режимы, verbose logging и тестовые обходы, если разработчик хоть раз попросил «упростить для отладки» или «показать детали ошибки». Проблема в том, что модель не знает, в каком окружении будет работать код.

В production это означает:

• Stack traces, уходящие во внешний ответ (CWE-209: Information Exposure Through an Error Message)
• Включённые debug-консоли Flask или Django, дающие удалённое выполнение кода [9]
• Логирование паролей, токенов и PII в стандартный вывод
• Тестовые bypass-флаги вроде if (DEBUG_SKIP_AUTH), которые в какой-то момент забывают убрать

OpenSSF в своём Security-Focused Guide для AI Code Assistant Instructions прямо указывает: AI должен «обрабатывать ошибки без раскрытия внутренних деталей или секретов в сообщениях об ошибках» [10]. Но без явного промпта с этим ограничением модель делает обратное.

Что искать: условия if DEBUG, if ENV == 'development', verbose error middleware без флага среды, console.log или print() рядом с объектами, содержащими credentials.

Признак 3. Слабая валидация — или её отсутствие

AI-генерированные эндпоинты нередко принимают и обрабатывают пользовательский ввод без какой-либо валидации [11]. Почему: модель оптимизирует для минимально работающего решения. В training data миллионы примеров кода с конкатенацией строк в SQL-запросы, потому что так проще и так делали до того, как сообщество осознало риски [7].

По данным Veracode, CWE-80 (Cross-Site Scripting) — ставший следствием отсутствия валидации — демонстрирует 86%-й failure rate в AI-генерированном коде [5].

Типичные паттерны:

• SQL через конкатенацию строк вместо параметризованных запросов
• eval(expression) как решение для вычисления пользовательских выражений — однострочник, открывающий RCE [7]
• Отсутствие санитизации при передаче input в shell-команды
• Только client-side валидация форм без дублирования на сервере
• Чтение path-параметров без проверки на path traversal

Cloud Security Alliance подчёркивает: «Многие уязвимости возникают не из-за "плохого кода", а из-за отсутствующих защитных мер — шагов валидации, проверок доступа или кодирования вывода» [7].

Признак 4. Небезопасные default-настройки

OWASP Top 10:2025 переместил Security Misconfiguration с пятого места на второе: каждое протестированное приложение содержит хоть одну мисконфигурацию [8]. AI резко ускорил появление этого класса проблем в коде.

Механизм: AI training data включает миллионы примеров с небезопасными настройками по умолчанию — они не нарушают синтаксис, работают в development-среде и проходят тесты.

Конкретные случаи:

• Широкий CORS: Access-Control-Allow-Origin: * вместо явного whitelist-а [8]
• Отключённые security headers (Content-Security-Policy, X-Frame-Options, HSTS)
• HTTP вместо HTTPS в конфигах, если в промпте не было явного требования
• Дефолтные credentials (admin:admin, root:password) в конфиг-файлах для «тестовой» среды
• Публично доступные cloud buckets или открытые management-интерфейсы

OpenSSF рекомендует явно указывать в инструкциях к AI: «Предпочитай безопасные defaults в конфигурациях — например, HTTPS по умолчанию, сильные алгоритмы шифрования, отключение небезопасных протоколов» [10].

Признак 5. Секреты прямо в коде

GitHub зафиксировал утечку 39 миллионов секретов в публичных репозиториях в 2024 году [12]. AI-код усугубляет проблему: 40% AI-генерированных проектов содержат повышенный уровень secret exposure — захардкоженные API-ключи, пароли, токены, сертификаты [1].

Почему это происходит: LLM обучены на репозиториях, где разработчики коммитили credentials. Для модели это «нормальный» код. Особенно опасен следующий сценарий: AI добавляет placeholder-секрет вроде API_KEY = "your-api-key-here", разработчик заменяет его реальным значением — и забывает перенести в environment variable перед merge.

Дополнительный риск: секреты в AI-генерированном коде нередко обходят стандартное сканирование, потому что используют нестандартные форматы именования [13].

Что контролировать: любые строковые литералы рядом с ключевыми словами key, token, password, secret, credential; параметры конструкторов API-клиентов; конфигурационные файлы, попавшие в diff.

Признак 6. Слабая аутентификация: код «работает для логина»

AI генерирует код аутентификации, который функционирует в happy path — и разваливается под adversarial условиями [11]. Распространённые паттерны:

• Использование MD5 или SHA-1 для хэширования паролей (вместо bcrypt/Argon2)
• JWT-реализации, проверяющие формат токена, но не верифицирующие подпись
• Отсутствие rate limiting на login-эндпоинтах
• Только client-side проверка сессии без server-side валидации
• Missing MFA при работе с sensitive данными

Особая хитрость: AI не пишет «плохой» auth-код намеренно. Он пишет код, который проходит все юнит-тесты на корректность, но провалится под реальной атакой. Authentication Failures сохраняют #7 в OWASP Top 10:2025 с 36 задокументированными CWE [14].

Конкретный пример из исследований: AI легко генерирует реализацию JWT, которая декодирует и принимает любой токен с "alg": "none" — известная уязвимость, позволяющая полностью обойти проверку подписи [11].

Признак 7. Скрытые изменения в конфиге и CI/CD

Это один из самых недооценённых классов риска. Конфигурационные файлы, CI/CD-пайплайны, IaC-шаблоны и .env-примеры читают значительно хуже, чем бизнес-логику.

В реальных инцидентах 2025 года:

• CVE-2025-30066: уязвимость в GitHub Action tj-actions/changed-files привела к утечке CI/CD-секретов более чем из 23 000 репозиториев [15]. Атакующие внедрили вредоносный код в workflow-логи и похитили API-токены.
• Изменения в docker-compose.yml, terraform.tf, .github/workflows/*.yml нередко проходят ревью без глубокого разбора, потому что «это же не production-код»

Что вызывает тревогу в diff:

• Новые permissions в GitHub Actions workflow (contents: write, id-token: write) без объяснения
• Изменение runs-on с ephemeral-runner на self-hosted без обоснования
• Появление новых environment variables без соответствующего секрета в vault
• Расширение прав сервисных аккаунтов в IaC
• Изменения в CORS-политике или security headers в nginx/ingress-конфигах

Признак 8. Неожиданные зависимости — и галлюцинации пакетов

Исследование, опубликованное в марте 2025 года, показало: в ~20% случаев (из 576 000 проанализированных Python и JavaScript кодовых примеров) рекомендованные AI пакеты не существовали [3]. Этот феномен получил название slopsquatting — злоумышленники заранее регистрируют названия, которые AI обычно галлюцинирует, и размещают под ними вредоносный код.

Один такой «несуществующий» пакет — huggingface-cli — был загружен более 30 000 раз за три месяца [3].

Помимо несуществующих пакетов, есть и другие зависимостные риски:

• AI предлагает устаревшие версии пакетов из своих training data, которые уже содержат CVE
• Новая прямая зависимость тянет за собой десятки транзитивных пакетов без ревью [16]
• AI может рекомендовать пакеты с похожими названиями, но из другого namespace (typosquatting-adjacent)
• 86% организаций используют open-source компоненты с известными уязвимостями в AI-воркфлоу [13]

По данным IBM X-Force 2026, supply chain компрометации выросли почти в 4 раза с 2020 года [17].

Что контролировать: любой новый пакет в diff — проверить его существование, версию, дату последнего релиза, количество загрузок и open issues с тегом «security».

Признак 9. Излишняя функциональность и «добрые самаритяне»

AI склонен к overengineering в сторону «а вдруг понадобится». Это выражается в:

• Новых endpoint-ах или методах, которых не было в задаче
• Fallback-механизмах с расширенными правами («если не работает, попробуй с admin-токеном»)
• Debug-интерфейсах, добавленных «для удобства разработчика»
• Utility-функциях с широким доступом к файловой системе или сети, которые по задаче должны были быть узкими

OWASP LLM Top 10 2025 выделяет Excessive Agency (#LLM06) как отдельную категорию риска для AI-ассистентов: избыточная функциональность, избыточные разрешения, избыточная автономность [18]. 41% AI-генерированного backend-кода содержит overly broad permission settings [13].

Признак 10. Нарушение целостности: что изменилось «под капотом»

AI-правки нередко затрагивают больше файлов, чем требует задача. CodeRabbit фиксирует: AI-генерированные изменения концентрируются в более крупных pull request-ах, затрагивая несколько файлов и сервисов сразу [1]. Это рассеивает внимание ревьюера.

Конкретные красные флаги:

• PR решает задачу в трёх строках, но в diff — изменения в 15 файлах
• Изменения в lock-файлах (package-lock.json, poetry.lock) без очевидной причины
• Обновление зависимостей вместе с основным кодом в одном коммите (трудно ревьювить отдельно)
• Изменения в migration-файлах без соответствующего task в описании

Эту проблему усугубляет то, что описание PR зачастую пишет тот же AI — и оно выглядит убедительно, даже если не отражает реального scope изменений.

Практический чек-лист: что смотреть до approve

На что смотреть в коде

1. Новые роуты/методы: есть ли явный role check на сервере?
2. Любые операции с пользовательским вводом: параметризованы ли запросы, есть ли санитизация?
3. Auth-логика: проверяется ли подпись, есть ли rate limiting, корректно ли истекают сессии?
4. Error handling: что именно возвращается клиенту при ошибке?
5. Строковые литералы рядом с key, token, password: не захардкожены ли credentials?

На что смотреть в зависимостях

1. Каждый новый пакет: существует ли, какая версия, есть ли открытые CVE?
2. Lock-файлы: изменились ли — и почему?
3. Транзитивные зависимости: какой реальный scope изменений supply chain?

На что смотреть в конфигах и CI

1. Новые permissions в workflow или IaC: минимально необходимые ли?
2. Конфигурационные дефолты: CORS, security headers, debug-флаги, credential policies

Инструменты и слои контроля

Стандартный стек для контроля AI-правок включает SAST (Semgrep, SonarQube, Snyk Code), SCA (Dependabot, Snyk, npm audit), secret scanning (TruffleHog, GitLeaks) и policy-as-code для IaC (Checkov, Terrascan). OpenSSF Scorecard позволяет оценить security-posture зависимостей до их добавления [19].

Важно понимать ограничение: большинство инструментов ловят синтаксические и известные паттерны уязвимостей. Но, как показывают исследования, AI-код может содержать логически корректные уязвимости — например, JWT-реализацию, проверяющую формат, но не проверяющую подпись. Такое проходит SAST, но открывает полный обход аутентификации [11].

Именно для этого разрыва и существует дополнительный слой контроля до merge. HighVibe анализирует конкретное изменение в контексте: что именно изменилось в коде, конфигурации, зависимостях и как это соотносится с релизным контекстом. Вместо длинного отчёта команда получает короткий ответ — можно ли безопасно принять именно это изменение прямо сейчас, и что нужно исправить, если нет. Такой подход не заменяет SAST/SCA/SBOM-проверки, но закрывает слой, который они не покрывают: архитектурный контекст, скрытые изменения в конфигах и неочевидные dependency-риски внутри одного PR.

Почему ревьюеры пропускают эти признаки

Стэнфордское исследование зафиксировало: разработчики, использующие AI-ассистентов, пишут код с большим количеством уязвимостей — и при этом более уверены в его безопасности, чем те, кто не использует AI [11]. Эта уверенность — отдельная уязвимость.

Есть и структурные причины:

• AI-правки выглядят аккуратнее и «профессиональнее», чем среднестатистический человеческий код — когнитивно это снижает бдительность
• Крупные PR с множеством изменённых файлов физически сложнее читать полностью
• Debug-правки, конфиги и lock-файлы воспринимаются как «технические детали», а не как security surface
• Описание PR, написанное тем же AI, выглядит убедительно и не вызывает вопросов

CodeRabbit в своём декабрьском отчёте 2025 года сформулировал итог: «AI-кодинг-инструменты резко увеличивают output, но вводят предсказуемые, измеримые слабости, которые организации должны активно снижать» [1].

Заключение: «работает» ≠ «безопасно для merge»

10 признаков, разобранных выше, объединяет одна логика: AI оптимизирует для правильности, не для безопасности. Код компилируется, тесты проходят, логика выглядит разумно. Но именно за этим фасадом прячутся лишние права, широкий CORS, слабая валидация, отсутствие проверки подписи и галлюцинированный пакет в зависимостях.

Практический ответ — не запрет AI и не тотальный аудит каждой строки. Это установка чётких gates: автоматизированные проверки в CI, явные правила для кода auth/authz/crypto, обязательное human review для конфигов и IaC, SCA для каждой новой зависимости. И — дополнительный слой анализа на уровне конкретного изменения, который даёт команде не отчёт о всех теоретических проблемах репозитория, а практический ответ перед каждым merge.

Подробнее о подходах к контролю AI-изменений до выкатки: highvibe.dev

Источники

[1] CodeRabbit, "State of AI vs Human Code Generation" (декабрь 2025) — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[2] Apiiro, "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks" (сентябрь 2025) — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/

[3] BleepingComputer, "AI-hallucinated code dependencies become new supply chain risk" (апрель 2025) — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[4] SoftwareSeni, "AI-Generated Code Security Risks – Why Vulnerabilities Increase 2.74x" (февраль 2026) — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[5] Veracode, "2025 GenAI Code Security Report" — https://www.veracode.com/blog/genai-code-security-report/

[6] Vibe Graveyard / CodeRabbit summary (январь 2026) — https://vibegraveyard.ai/story/coderabbit-ai-code-quality-study/

[7] Cloud Security Alliance, "Understanding Security Risks in AI-Generated Code" (июль 2025) — https://cloudsecurityalliance.org/blog/2025/07/09/understanding-security-risks-in-ai-generated-code

[8] OWASP Top 10:2025 — A01 Broken Access Control + A02 Security Misconfiguration — https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/

[9] OWASP Top 10:2025 (SecComply overview) — https://seccomply.net/resources/blog/owasp-top-10-2025

[10] OpenSSF Best Practices WG, "Security-Focused Guide for AI Code Assistant Instructions" — https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html

[11] Seclinq, "The Security Risks of AI-Generated Code: What Vibe Coding Really Costs You" — https://seclinq.com/security-risks-of-ai-generated-code/

[12] Knostic.ai, "How to Secure AI Coding Assistants and Protect Your Codebase" (январь 2026) — https://www.knostic.ai/blog/ai-coding-assistant-security

[13] SQ Magazine, "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[14] OWASP Top 10:2025 (Orca Security overview) — https://orca.security/resources/blog/owasp-top-10-2025-key-changes/

[15] CodeAnt.ai, "Secure Code Audits in 2025" (CVE-2025-30066) — https://www.codeant.ai/blogs/source-code-audit-checklist-best-practices-for-secure-code

[16] Security Review AI, "The New Reality of Threat Modeling in AI-Generated Systems" (октябрь 2025) — https://www.securityreview.ai/blog/the-new-reality-of-threat-modeling-in-ai-generated-systems

[17] Cycode, "Top AI Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/ai-security-vulnerabilities/

[18] Growexx, "AI-Generated Code Security Risks: How It Aligns with OWASP Top 10" — https://www.growexx.com/blog/ai-generated-code-owasp-top-10/

[19] OpenSSF Scorecard — https://scorecard.dev/