Как безопасно принимать AI-сгенерированный код перед merge: практический diff-based чек-лист

Что смотреть в коде, конфиге, lock-файлах и служебных файлах — и когда достаточно комментария, а когда нужен жёсткий стоп

Рабочий PR — не значит безопасный

В 2025 году AI стал писать код быстрее, чем команды успевают его проверять. По данным GitHub, к середине 2025 года около 41% нового кода в больших репозиториях было сгенерировано с участием ИИ [5]. Это не тренд будущего — это уже сегодняшняя реальность для большинства команд.

Вместе с ростом скорости подтянулась и новая проблема: психологический эффект доверия к AI-коду. Исследования показывают — разработчики тратят на ревью AI-дифа меньше времени, чем на ревью человеческого [1]. Код «выглядит чисто», проходит синтаксическую проверку, иногда даже покрыт тестами. И его мержат.

Только вот Veracode в 2025 году протестировала более 100 LLM на четырёх языках программирования и выяснила: AI-сгенерированный код содержит уязвимостей в 2,74 раза больше, чем написанный вручную [1]. Apiiro исследовала Fortune 50 enterprise-кодовые базы и зафиксировала на 322% больше путей для privilege escalation и на 40% больше инцидентов с утечкой секретов в AI-помогаемом коде [3]. CodeRabbit в декабре 2025 проанализировал 470 open-source pull request'ов и обнаружил, что AI-коммиты содержат примерно в 1,7 раза больше серьёзных проблем [3].

Статистика убедительная, но сама по себе она не помогает. Помогает конкретный операционный подход: знать, где смотреть, что искать, и понимать, когда достаточно оставить комментарий, а когда — заблокировать merge.

Эта статья — практический diff-based чек-лист. Для тех, кто апрувит PR: Tech Lead, AppSec, DevSecOps, Senior Developer.

Часть 1. Почему AI-код требует отдельного стандарта ревью

Классическое ревью кода было устроено просто: ты знаешь автора, понимаешь контекст изменения, можешь спросить «почему ты это написал именно так». С AI-кодом этот контекст исчезает.

Модель не понимает архитектуры вашей системы. Она не знает, что у вас кастомный auth middleware. Она не понимает бизнес-логику. Она предсказывает следующий токен, опираясь на паттерны из обучающих данных — а в этих данных было огромное количество небезопасного кода [6]. Авторы 2025 GenAI Code Security Report прямо пишут: «простое увеличение размера модели не улучшает способность генерировать безопасный код» [6]. Процент безопасных сниппетов оставался практически неизменным по мере роста параметров.

Из этого следует практический вывод, который важно зафиксировать на уровне командной нормы: AI-сгенерированный код нужно относиться так же, как к коду от незнакомого стороннего разработчика — то есть считать потенциально небезопасным, пока не доказано обратное.

OWASP в редакции Top 10 за 2025 год впервые добавил специфические рекомендации по AI-сгенерированному коду, подчеркнув, что каждая строка должна проходить SAST-проверку без исключений [7]. Никаких привилегий за то, что «код написал Copilot».

Кроме того, у AI есть специфические точки провала, которых нет у людей:

1. Он уверенно называет несуществующие пакеты (package hallucinations).
2. Он воспроизводит паттерны с секретами прямо из обучающих данных.
3. Он генерирует конфиги и IaC без понимания принципа наименьших привилегий.
4. Он делает большие PR — исследования Apiiro показывают снижение общего объёма PR при росте размера каждого [3]. Это размывает внимание ревьюера.

Разберём каждую зону по очереди.

Часть 2. Зона 1: Сам код — что смотреть в диффе

Что AI делает неправильно чаще всего

Три категории уязвимостей встречаются в AI-коде значительно чаще, чем в человеческом:

Первое — SQL-инъекции и небезопасная работа с вводом. Модели воспроизводят конкатенацию строк в запросах вместо параметризованных запросов (CWE-89), пропускают санитизацию пользовательского ввода (CWE-80 — XSS) [6]. Это классические OWASP A03 паттерны, и именно они чаще всего встречаются в AI-диффах.

Второе — неправильная криптография. AI предлагает устаревшие алгоритмы: MD5 или SHA-1 для паролей, предсказуемые генераторы псевдослучайных чисел, жёстко прошитые ключи шифрования [8].

Третье — проблемы с авторизацией. AI часто генерирует код, который проверяет аутентификацию, но не авторизацию (OWASP A01:2025 — Broken Access Control). Он создаёт эндпоинты, не добавляя проверку прав на ресурс.

Чек-лист: что смотреть в диффе кода

Для каждого изменения проверь следующее.

По логике и безопасности ввода/вывода:

• Все пользовательские данные валидируются перед обработкой?
• Запросы к БД используют параметризацию, а не конкатенацию?
• Вывод данных в HTML/JS корректно экранируется?
• Нет ли path traversal при работе с файлами?

По аутентификации и авторизации:

• Каждый чувствительный эндпоинт защищён middleware аутентификации?
• Проверяется ли не только «ты залогинен», но и «ты имеешь право на этот конкретный ресурс»?
• Нет ли @AllowAnonymous или аналогов на местах, где они не должны быть?
• Сессионные токены генерируются криптостойким генератором с энтропией ≥128 бит? [7]

По криптографии:

• Используются ли только актуальные алгоритмы (SHA-256+, bcrypt/argon2 для паролей, AES-256)?
• Нет ли MD5, SHA-1, DES в новом коде?
• Ключи и соли — динамические, не хардкод?

По обработке ошибок:

• Стектрейсы и внутренние детали не возвращаются пользователю?
• Логируются ли ошибки безопасности (неудачные входы, отказы авторизации)?
• Нет ли пустых catch-блоков, которые заглушают ошибки?

Где достаточно комментария, где нужен стоп

Комментарий и запрос на доработку достаточны, если проблема локальная и не касается критической логики: неправильное экранирование в нечувствительном месте, отсутствие валидации длины поля, слабое логирование ошибки.

Жёсткий стоп нужен, если: проблема в аутентификации или авторизации; код затрагивает криптографию и использует устаревшие алгоритмы; есть инъекция в логику обработки пользовательского ввода; код открывает эндпоинт без проверки прав.

Отдельное правило: код, который AI сгенерировал для аутентификации, криптографии, платёжных систем и secrets management — требует обязательного ревью AppSec-специалистом, а не только peer review [3].

Часть 3. Зона 2: Зависимости и lock-файлы — самое опасное место

Package hallucinations и slopsquatting

Это, пожалуй, самый недооценённый риск AI-кодинга. Исследователи из трёх университетов (University of Texas at San Antonio, University of Oklahoma, Virginia Tech), которые опубликовали работу в рамках USENIX Security 2025, проанализировали 576 000 сгенерированных сниппетов на Python и JavaScript — и обнаружили, что около 20% рекомендуемых пакетов не существуют [2].

Это называется package hallucination. Модель уверенно называет пакет, которого нет на PyPI или npm. В открытых моделях (CodeLlama, DeepSeek, WizardCoder) частота галлюцинаций доходила до 21,7%. Коммерческие модели (ChatGPT-4 и аналоги) показывали около 5% [9] — меньше, но всё равно значимо при масштабе.

Опасность не просто в том, что несуществующий пакет вызовет ошибку сборки. Опасность в том, что атакующие мониторят AI-галлюцинации и регистрируют такие имена на PyPI и npm, заливая туда вредоносный код. Это называется slopsquatting — разновидность typosquatting, где вместо опечатки эксплуатируется ошибка модели [10].

В 2024 году исследователь из Lasso Security заметил, что модели стабильно галлюцинируют пакет huggingface-cli (правильная установка идёт через другую команду). Он зарегистрировал этот пакет на PyPI как пустой — чтобы проверить гипотезу. За три месяца пакет получил более 30 000 реальных загрузок. Alibaba успела скопировать команду установки в README своего публичного репозитория [10]. Пакет был безвредным — но только потому, что зарегистрировал его исследователь.

ENISA в Threat Landscape 2025 прямо называет slopsquatting одной из растущих угроз для supply chain и фиксирует атаки через троянизированные PyPI-пакеты и компрометацию конфигурационных файлов coding assistants [11].

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

Проверь по каждому новому пакету в PR:

Существование и легитимность:

• Пакет реально существует на PyPI/npm/crates.io?
• У него есть история скачиваний, не нулевая активность, живой maintainer?
• Имя не выглядит подозрительно похожим на популярный пакет (классический typosquatting)?
• Если пакет незнаком — проверь его на npmjs.com, PyPI, GitHub прежде чем принять PR.

Уязвимости:

• Нет ли известных CVE у новой версии пакета? (Dependabot, Snyk, npm audit, pip-audit)
• Транзитивные зависимости тоже проверены? (95% уязвимостей находятся именно в транзитивных зависимостях [12])

Лицензионная чистота:

• Лицензия пакета совместима с лицензией проекта?
• Нет ли GPL-пакета в коммерческом проекте?

Что смотреть в lock-файлах

Lock-файл — package-lock.json, yarn.lock, Pipfile.lock, Cargo.lock и их аналоги — это источник истины о реальных зависимостях. AI часто добавляет зависимость в package.json, не трогая lock-файл, или наоборот — lock-файл меняется «случайно» при регенерации.

Смотри в диффе lock-файла:

• Изменения lock-файла соответствуют изменениям в package.json/requirements.txt/Cargo.toml? Если lock-файл изменился, а манифест нет — это красный флаг.
• Нет ли неожиданных изменений версий существующих пакетов? AI может «случайно» обновить зависимости при регенерации.
• Хеши пакетов присутствуют и не изменены для неизменившихся пакетов?

Где достаточно комментария, где нужен стоп

Комментарий достаточен: патч-версия обновилась в patch-диапазоне у некритичной утилиты, добавлена зависимость с известной репутацией, аудит не выявил CVE.

Стоп нужен: в PR появился пакет, которого нет на официальном реестре или у которого нет истории; lock-файл изменился без понятной причины; у новой зависимости есть CVE с CVSS 7.0+; пакет не обновлялся более 12 месяцев и находится в критической части стека.

Часть 4. Зона 3: Секреты — 40% прирост при AI-кодинге

Почему AI «любит» хардкодить секреты

Модели обучены на публичных репозиториях, в которых разработчики годами коммитили API-ключи, пароли и токены. Для модели это паттерн «нормального» кода [8]. Она не понимает разницы между placeholder и реальным ключом — она просто воспроизводит то, что видела.

Данные Apiiro зафиксировали на 40% больше инцидентов с секретами в AI-assisted codebase [3]. GitGuardian State of Secrets Sprawl 2025 констатирует: «AI не создаёт новую проблему секретов — он ускоряет каждое условие, которое уже делало секреты опасными» [13].

Конкретные примеры того, что AI делает:

• Пишет const SECRET_KEY = "sk-proj-abc123..." — потому что видел такие примеры.
• Создаёт .env.example с реальными значениями, а не заглушками.
• Добавляет JWT secret прямо в конфиг: jwt.secret = "mysecretkey".
• Прописывает database password в коде миграции.

Чек-лист по секретам в диффе

Перед merge проверь:

• Нет ли строк, которые выглядят как API-ключи, токены или пароли, в самом коде?
• Конфигурационные файлы используют переменные окружения или ссылки на secret manager (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault)?
• .env-файлы с реальными значениями не попали в git? Проверь .gitignore.
• CI/CD-файлы (GitHub Actions, GitLab CI) используют секреты через ${{ secrets.NAME }}, а не хардкодят их?

Инструменты автоматизации: GitGuardian, Gitleaks, GitHub Secret Scanning, truffleHog — запускай на каждом PR, не только вручную.

Где комментарий, где стоп

Комментарий: в коде placeholder "YOUR_API_KEY_HERE" без реального значения — можно зафиксировать и попросить убедиться, что оно не попадёт при деплое.

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

Часть 5. Зона 4: Конфиги, IaC и CI/CD — читают хуже всего

Почему это особенно опасная зона

Конфиги, Terraform-манифесты, Kubernetes YAML, Dockerfile, GitHub Actions — это файлы, которые ревьюер листает по диагонали. Там нет «логики» в привычном смысле. Изменение в несколько строчек может открыть внешний доступ к базе данных, расширить CORS до *, дать роли слишком широкие права в облаке.

AI генерирует IaC с нарушением принципа наименьших привилегий систематически. Типичный пример — IAM-политика с "Action": "", "Resource": "", которую Terraform принимает без предупреждений [14]. Или EXPOSE 0.0.0.0:5432 в Dockerfile, который выставляет базу данных наружу.

OpenSSF Security-Focused Guide for AI Code Assistant Instructions (2025) прямо указывает: IaC-файлы нужно проверять с той же строгостью, что и код приложения, включая версии DevOps-зависимостей и закрепление SHA для GitHub Actions [15].

Чек-лист: конфиги и IaC

По правам доступа и сети:

• Принцип наименьших привилегий соблюдён? Нет * в Action или Resource IAM-политик?
• Security groups / firewall rules не открывают 0.0.0.0/0 на закрытые порты?
• Kubernetes RBAC: роли имеют только необходимые права?

По шифрованию:

• Шифрование данных at rest включено (S3 bucket, RDS, диски VM)?
• Трафик between services идёт по TLS?

По CORS и доступу:

• CORS не выставлен в * для чувствительных API?
• Нет AllowAllOrigins: true в конфигах веб-сервера?

По CI/CD и GitHub Actions:

• Версии actions закреплены через SHA-хеш, а не через плавающий тег (@v2 vs @abc123def456)?
• Секреты передаются через ${{ secrets.NAME }}, а не хардкодятся?
• Новые шаги в pipeline не выполняют shell-команды с необработанными переменными? (именно такой баг в NX build tool в 2025 году позволил украсть npm publishing tokens [16])

По Dockerfile:

• Базовый образ конкретной версии, а не :latest?
• Контейнер не запускается от root без явного обоснования?
• Нет ли ADD с URL (предпочитай COPY)?

Где комментарий, где стоп

Комментарий: плавающий тег :latest в некритичном dev-образе, CORS настроен широко для staging-среды с явным флагом «только для staging».

Стоп: IAM с -правами в production; открытый порт базы данных в security group; CORS: в production API; GitHub Actions без закреплённых SHA в критичном workflow.

Часть 6. Зона 5: Служебные файлы — миграции, internal tools, .cursorrules

Особый риск служебных файлов

Миграции баз данных, seed-скрипты, internal admin tools, .cursorrules (файлы инструкций для AI coding assistant) — это категория, которую ревьюируют наспех или не ревьюируют вовсе.

ENISA Threat Landscape 2025 зафиксировал новый вектор атаки — Rules File Backdoor: атакующие внедряют вредоносные инструкции в конфигурационные файлы coding assistants (.cursorrules, .github/copilot-instructions.md), фактически угоняя рабочий процесс разработчика [11]. Если такой файл попадёт в репозиторий через PR, следующая генерация кода будет идти с «отравленными» инструкциями.

Миграции — отдельная история. AI генерирует ALTER TABLE и DROP COLUMN без понимания контекста данных в production. Необратимые изменения схемы, удаление полей, которые ещё используются в другом сервисе — всё это реальные инциденты.

Чек-лист: служебные файлы

Для .cursorrules / .github/copilot-instructions.md и аналогов:

• Изменения в этих файлах должны проходить ревью отдельным AppSec-специалистом или Tech Lead.
• Нет ли инструкций типа «игнорируй security проверки», «не добавляй аутентификацию», «используй admin credentials»?

Для миграций БД:

• Миграция обратима? Есть ли down-метод?
• Удаляемые колонки не используются в production сервисах прямо сейчас?
• Есть ли план отката на случай ошибки?

Для seed-скриптов и internal tools:

• Нет ли хардкода production credentials?
• Tool не имеет прав, которые шире необходимого для его задачи?

Где комментарий, где стоп

Комментарий: миграция без down-метода для некритичного добавления nullable-колонки.

Стоп: любые изменения в .cursorrules или аналогах без явного объяснения; DROP TABLE или DROP COLUMN без проверки зависимостей; seed-скрипт с hardcoded production паролем.

Часть 7. Автоматизация: что делают инструменты, а что остаётся за человеком

Что автоматизировать обязательно

Автоматизация не заменяет ревью, но убирает механическую работу и ловит то, что человек пропускает при усталости.

Обязательный минимум в CI/CD:

• SAST (Semgrep, SonarQube, Checkmarx) — запускать на каждый PR, флаги на OWASP Top 10 паттерны.
• SCA (Snyk, Dependabot, npm audit, pip-audit) — проверка зависимостей на CVE, блокировка merge при CVSS 7.0+.
• Secret scanning (GitGuardian, Gitleaks, GitHub Secret Scanning) — блокировка коммита при обнаружении паттернов секретов.
• IaC scanning (Checkov, Terraform Sentinel, tfsec) — проверка Terraform/CloudFormation/Kubernetes на мисконфиги.

Важная оговорка: исследование 2024 года показало, что SAST на основе changed-function (а не всего файла) повышает точность на 12% и полноту на 5,6% [4]. Настраивай инструменты на анализ именно диффа, а не репозитория целиком — это снижает noise.

Что инструменты не поймают

Автоматика хуже справляется с:

• Бизнес-логическими ошибками (авторизация «по смыслу», а не по синтаксису).
• IDOR (Insecure Direct Object Reference) — только 22% истинных срабатываний у чистых AI-сканеров [17].
• Архитектурными уязвимостями — компонент сам по себе выглядит безопасно, но в контексте системы создаёт проблему.
• Поведенческими аномалиями — конфиг выглядит валидным, но в production-контексте открывает лишний доступ.

Именно здесь человек незаменим. Именно поэтому ревью AI-кода нельзя полностью делегировать другому AI.

Decision framework: что блокирует merge

Вот упрощённый фреймворк для принятия решения по итогам ревью.

Автоматический блок merge (CI должен блокировать):

• Найден секрет с паттерном реального ключа.
• SAST зафиксировал CVSS 7.0+ уязвимость в новом коде.
• SCA выявил CVE 7.0+ в новой прямой зависимости.
• Новый пакет не существует в реестре (hallucinated package).

Обязательный человеческий стоп:

• Код затрагивает аутентификацию, авторизацию или криптографию.
• Изменение в .cursorrules / конфигах coding assistant.
• Необратимая миграция БД без согласования.
• IaC с *-правами или открытыми портами в production.

Можно мержить с комментарием:

• Minor: стиль, нейминг, неоптимальная структура без security implications.
• Предупреждение: слабое место, которое не критично сейчас, но требует отдельного тикета.
• Техдолг: зафиксирован, создан issue, не блокирует выпуск.

Часть 8. Частые ошибки и как их избежать

Ошибка 1: «Код работает, значит безопасен»

Самая распространённая. Функциональная корректность и безопасность — это разные измерения. SQL-инъекция в коде Copilot не мешает юнит-тестам проходить зелёными.

Как избежать: разделить в PR-описании «функциональная проверка» и «security-проверка» как два разных чек-бокса.

Ошибка 2: Ревью только первого уровня зависимостей

Согласно исследованиям, 95% уязвимостей находятся в транзитивных зависимостях [12]. AI добавляет прямую зависимость, которая тянет за собой уязвимую transitive. Стандартный npm audit это поймает — но только если запускать его.

Как избежать: SCA-инструмент в CI как обязательный gate, а не опциональная проверка.

Ошибка 3: Игнорирование изменений в lock-файлах

Большие lock-файлы скучно ревьюировать. Но именно там бывают неожиданные апдейты, которые AI делает «попутно» при регенерации манифеста.

Как избежать: в PR-шаблон добавить чек-бокс «lock-файл проверен».

Ошибка 4: Доверять AI-комментарию «этот код безопасен»

Иногда AI добавляет в сгенерированный код комментарий // This is secure because... — и ревьюер его читает и успокаивается. Это фикция: модель не может верифицировать безопасность собственного вывода.

Как избежать: культурная норма — комментарии AI о безопасности в коде не считаются валидацией.

Ошибка 5: Один ревьюер на весь большой AI-диф

Apiiro зафиксировал, что AI-assisted разработчики создают меньше, но значительно более крупные PR [3]. Большой диф при одном ревьюере — это гарантия пропущенных проблем. Microsoft Research показал, что при рецензировании более 400 строк за сессию качество значительно падает [18].

Как избежать: делить большие AI-PR на части; назначать разных ревьюеров на code, конфиги и зависимости.

Часть 9. Кейсы: что бывает, когда не смотрят

NX build tool, август 2025

Разработчики проекта NX в GitHub Actions использовали заголовок pull request напрямую в shell-команде без санитизации. Это — command injection (CWE-78), классика OWASP. Атакующий создал PR с вредоносным заголовком и украл npm publishing tokens. Пострадали более 1400 разработчиков, которые установили скомпрометированный update [16].

Чем мог помочь правильный ревью: явная проверка CI/CD-скрипта, использующего переменную из внешнего источника без кавычек.

Huggingface-cli и slopsquatting, 2024

Как описано выше — исследователь зарегистрировал галлюцинируемый пакет huggingface-cli на PyPI и получил 30 000 загрузок за три месяца, включая Alibaba. Это не атака, но proof of concept: если бы пакет зарегистрировал атакующий, последствия были бы серьёзными [10].

Чем мог помочь правильный ревью: проверка существования пакета на PyPI перед merge.

Rules File Backdoor (атаки на coding assistants)

ENISA Threat Landscape 2025 фиксирует: атакующие модифицируют .cursorrules и аналогичные конфигурационные файлы, внедряя инструкции, которые заставляют AI coding assistant генерировать небезопасный код в будущем [11]. Если такой файл попадает через PR — следующий разработчик, не читая конфиг, будет получать «отравленные» советы.

Чем мог помочь правильный ревью: обязательный security ревью любых изменений в конфигах AI-ассистента.

Часть 10. Будущее: автономные AI-агенты и ещё большая скорость

В 2025–2026 году рынок выходит за пределы «автодополнения» в IDE. Появляются автономные coding agents: они сами создают PR, сами пишут тесты, сами назначают ревьюеров. GitHub Copilot Workspace, Claude Code, Cursor Composer — всё это уже в production у многих команд.

Это поднимает ставки для ревью ещё выше. Если раньше разработчик хотя бы понимал, что именно он просил у AI, то теперь агент может принять промежуточные архитектурные решения самостоятельно. Человек получает на ревью диф, в котором не был ни на одном из шагов создания.

По данным исследования Laura Tacho (февраль 2026), 92,6% разработчиков используют AI coding assistant хотя бы раз в месяц, около 75% — еженедельно [19]. AI ускоряет ряд задач до 80%. Это реальный productivity gain — и реальное ускорение появления рисков.

Вывод из этого не «запретить AI», а «адаптировать процессы контроля к новой скорости».

Несколько трендов, которые стоит учитывать при планировании:

Перенос проверки на более раннюю стадию. IDE-based security scanning (например, Checkmarx ASCA) ловит проблемы ещё до коммита. Это быстрее и дешевле, чем находить то же самое в PR [2].

PR-native автоматизация. Инструменты, которые работают прямо внутри PR (как review-боты), дают сигнал за секунды, без переключения контекста.

Автономные security agents. Ранние эксперименты показывают, что AI-агенты могут создавать PR с назначенными ответственными и автоматически отслеживать исправления. Но даже это не снимает необходимость человека на финальном gate.

Заключение: что делать прямо сейчас

Если после прочтения статьи нужно взять три действия — вот они.

Первое — зафиксировать командную норму: AI-код = потенциально небезопасный код до ревью. Не строже, чем человеческий, но и не мягче. Без исключений для «маленьких» PR.

Второе — закрыть автоматикой самое механическое: secret scanning, SCA, базовый SAST, IaC lint. Это снизит шум на ревью и позволит человеческому вниманию сосредоточиться на логике и архитектуре.

Третье — добавить в PR-шаблон явные зоны проверки: код, зависимости, lock-файлы, конфиги/IaC, служебные файлы. Не как формальность, а как чек-лист, который ревьюер проходит по очереди.

Масштаб AI-кодинга будет только расти. Контроль изменений должен расти вместе с ним — не как барьер, а как инфраструктура качества.

Команды, которые ищут дополнительный слой контроля именно на этапе PR и релиза, могут посмотреть на HighVibe — инструмент анализирует конкретный диф (код, зависимости, конфиги), объясняет риск и предлагает следующий шаг: комментарий, исправление или стоп. Не замена SAST и SCA, а надстройка над ними — для того, чтобы на merge попадало только то, что действительно безопасно принимать сейчас.

Источники

[1] Veracode — 2025 GenAI Code Security Report: https://www.veracode.com/blog/secure-ai-code-generation-in-practice/

[2] Spracklen et al. — We Have a Package for You! (USENIX Security 2025): https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code

[3] Apiiro — AI-Generated Code Security Research (Fortune 50 Enterprise Study):https://apiiro.com/blog/ai-generated-code-security/

[4] Knostic.ai — How to Secure AI Coding Assistants (2026): https://www.knostic.ai/blog/ai-coding-assistant-security

[5] Ranger — Version Control Best Practices for AI Code: https://www.ranger.net/post/version-control-best-practices-ai-code

[6] Veracode — Secure AI Code Generation in Practice: https://www.veracode.com/blog/secure-ai-code-generation-in-practice/

[7] OWASP — Secure Code Review Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Secure_Code_Review_Cheat_Sheet.html

[8] Apiiro — AI-Generated Code Security Risks: https://apiiro.com/blog/ai-generated-code-security/

[9] Bleeping Computer — 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/

[10] Aikido Security — Slopsquatting: AI Package Hallucination Attacks (2026): https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks

[11] Socket.dev — ENISA's 2025 Threat Landscape: AI Reshapes Cyber Attacks: https://socket.dev/blog/enisa-s-2025-threat-landscape-ai-reshapes-cyber-attacks

[12] Endor Labs — How to Detect IaC Misconfigurations with AI Security Code Review: https://www.endorlabs.com/learn/how-to-detect-infrastructure-as-code-iac-misconfigurations-with-ai-security-code-review

[13] GitGuardian — Shifting Security Left for AI Agents (2026): https://blog.gitguardian.com/shifting-security-left-for-ai-agents-enforcing-ai-generated-code-security-with-gitguardian-mcp/

[14] Gomboc — 5 Common IaC Misconfigurations to Avoid in 2026: https://www.gomboc.ai/blog/5-common-iac-misconfigurations-to-avoid-in-2026

[15] OpenSSF — Security-Focused Guide for AI Code Assistant Instructions: https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions.html

[16] ClackyAI — Code Review Checklist for AI-Generated Code: https://clacky.ai/blog/code-review-checklist-ai-generated-code

[17] Augment Code — How to Set Up AI Code Review in CI/CD Pipeline: https://www.augmentcode.com/guides/ai-code-review-ci-cd-pipeline

[18] Augment Code — Code Review Checklist: 40 Questions Before You Approve: https://www.augmentcode.com/guides/code-review-checklist-40-questions-before-you-approve

[19] Infosecurity Magazine — How Security Leaders Can Safeguard Against Vibe Coding Security Risks: https://www.infosecurity-magazine.com/news-features/how-safeguard-vibe-coding-security/