Как проверять AI-сгенерированный код перед merge: чек-лист для Tech Lead

Когда "работает" — это ещё не значит "безопасно"

Введение: контроль изменений не успел за скоростью AI

По данным опроса разработчиков GitHub 2024 года, 97% из них используют или тестируют AI-инструменты [5]. По оценкам, в том же году около 70% организаций уже имели долю AI-сгенерированного кода свыше 40% от общего объёма [6]. Это означает, что большинство pull request'ов в современных командах содержат код, который никто не написал строчку за строчкой вручную.

Проблема не в том, что AI пишет плохо. Проблема в том, что скорость генерации кода опередила скорость роста культуры его проверки. Исследование Stanford показало парадоксальный эффект: разработчики, использующие AI-ассистентов, писали менее безопасный код — и при этом были более уверены в его безопасности [7]. Дифф дочитывают не до конца. Новая зависимость проходит незаметно. Конфигурационный файл обновляется без особого внимания.

Этот материал — прикладной порядок ревью для Tech Lead, CTO и AppSec-специалиста. Не теоретический обзор, а конкретный чек-лист: что проверять в логике, валидации, правах доступа, зависимостях, конфигурации и тестах, и когда правку можно принять, отправить на доработку или заблокировать.

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

Уязвимости не убывают — они меняют природу

Данные Apiiro за июнь 2025 года фиксируют рост числа новых security findings в AI-коде до 10 000 в месяц — это десятикратный рост относительно декабря 2024 [2]. При этом профиль уязвимостей изменился: синтаксические ошибки стали редкостью (–76%), логические баги сократились (–60%), но архитектурные дефекты — ошибки в дизайне, нарушения принципа наименьших привилегий, некорректные границы доступа — выросли кратно [2].

Veracode в своём GenAI Code Security Report 2025 протестировала более 100 LLM-моделей на четырёх языках программирования и обнаружила: 45% сгенерированных сниппетов содержат уязвимости из OWASP Top 10, причём Java показывает 72%-й провал security-тестов [1].

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

Архитектурный дрейф: SAST не поможет

Исследователи из Apiiro выявили специфическую категорию AI-рисков — "архитектурный дрейф" [2]. Модель вносит небольшие изменения, которые не нарушают синтаксис и не триггерят статические анализаторы, но ломают архитектурные предположения безопасности. SAST возвращает чистый скан, а код при этом открывает пути для эскалации привилегий или обхода аутентификации. Именно поэтому автоматизация покрывает около 70% проблем с эскалацией привилегий, а оставшиеся 30% требуют архитектурного анализа человеком [2].

Психологический эффект: уверенность без основания

Разработчики, принявшие 50 корректных AI-предложений подряд, начинают доверять 51-му автоматически [8]. Код выглядит профессионально, компилируется без ошибок и проходит базовые тесты — это создаёт ложное ощущение безопасности. Hardcoded API-ключ не вызывает синтаксической ошибки и не выглядит подозрительно в diff'е.

OpenSSF в своём Security-Focused Guide for AI Code Assistant Instructions (2025) прямо указывает: разработчик остаётся ответственным за любой вред, который может нанести код, и обязан критически оценивать AI-предложения так же строго, как код коллеги-человека [9].

Часть 2. Чек-лист ревью: шесть уровней проверки

Ниже — структурированный порядок проверки, расположенный от наиболее приоритетных блоков к менее критичным. Каждый уровень включает конкретные вопросы и указание, когда правку можно принять, когда отправить на доработку и когда заблокировать merge.

Уровень 1. Секреты и учётные данные

Это первое, что нужно проверить, — до того как смотреть на логику.

По данным GitGuardian State of Secrets Sprawl 2026, в 2025 году в публичные репозитории GitHub утекло 28,65 миллиона новых хардкоженых секретов [4]. Репозитории с активным Copilot демонстрируют уровень утечки 6,4% — против 4,6% в репозиториях без AI-ассистента [4]. Причина — не злой умысел, а скорость: разработчик принимает предложение AI, которое включает API-ключ из тренировочных данных, и не замечает этого.

Что проверять:

1. Нет ли хардкоженых токенов, паролей, API-ключей, сертификатов или connection string'ов в исходном коде.
2. Нет ли секретов в CI/CD-файлах (workflow YAML, Dockerfile, docker-compose).
3. Нет ли переменных с именами вроде API_KEY, SECRET, PASSWORD, TOKEN со значениями прямо в коде.
4. Используется ли безопасное хранилище (Vault, AWS Secrets Manager, переменные среды через secrets backend).
5. Нет ли debug-конфигураций с отключённой аутентификацией или расширенным логированием, которое пишет чувствительные данные.

Решение:

• Найдены секреты в коде → блокировать merge, отзывать учётные данные немедленно.
• Подозрительные имена переменных без явных значений → запросить пояснение.
• Секрет убран, но был в предыдущем коммите → потребовать rebase с очисткой git history перед merge.

Уровень 2. Зависимости и цепочка поставок (supply chain)

Это наиболее быстро развивающийся вектор угроз в AI-эпоху.

AI-модели рекомендуют пакеты из обучающих данных, которые могут быть устаревшими, уязвимыми или вовсе несуществующими. Исследование USENIX Security 2025, проведённое на 576 000 сэмплов кода для 16 моделей, показало: около 20% предложенных открытыми LLM пакетов не существуют в npm и PyPI [3]. Для коммерческих моделей вроде ChatGPT-4 этот показатель ниже, но составляет около 5% [3]. Атака slopsquatting — когда атакующий регистрирует пакет с именем, которое LLM стабильно галлюцинирует, — уже зафиксирована на практике: в 2024 году исследователь Lasso Security обнаружил несуществующий пакет huggingface-cli, который AI стабильно рекомендовал, и загрузил его-пустышку на PyPI; пакет набрал более 30 000 реальных скачиваний, причём Alibaba скопировала некорректную команду установки в README публичного репозитория [10].

Что проверять:

1. Все новые зависимости — известны ли они? Существуют ли они в официальном реестре?
2. Версии пакетов зафиксированы в lock-файле (package-lock.json, poetry.lock, Pipfile.lock).
3. Нет ли Known CVE в добавленных или обновлённых зависимостях (проверка через SCA: Snyk, Dependabot, OWASP Dependency-Check).
4. Нет ли транзитивных зависимостей с уязвимостями, которые пришли с новым прямым пакетом.
5. Версии пакетов актуальные или заброшенные (последний коммит более 12 месяцев назад)?
6. Если используется SBOM — обновлён ли он в рамках этого PR?
7. Для конкретного пакета: совпадает ли имя с тем, что существует на официальном registry? (Особенно для Python и JS.)

Решение:

• Несуществующий пакет → блокировать merge, выяснить намерение и заменить на верифицированную альтернативу.
• Найдены CVE критической или высокой степени тяжести → блокировать merge до патча или замены.
• Незафиксированные версии в lock-файле → отправить на доработку.
• Незнакомый пакет с малым числом скачиваний → запросить обоснование и провести ручную проверку.

Уровень 3. Права доступа и управление авторизацией

По данным Apiiro, AI-код создаёт на 322% больше путей для эскалации привилегий, чем код, написанный вручную [2]. Причина — "контекстная слепота": модель не видит вашей IAM-модели, конфигурации RBAC и архитектурных предположений о границах сервисов.

В OWASP Top 10:2025 Broken Access Control сохраняет позицию №1: 3,73% всех приложений имеют задокументированные нарушения контроля доступа [11]. По данным OWASP, 100% протестированных приложений имели хотя бы одну форму нарушения access control [12].

Что проверять:

1. Все новые endpoint'ы — требуют ли они аутентификации? Проверяется ли авторизация на стороне сервера?
2. Реализован ли принцип наименьших привилегий: нет ли получения данных шире, чем нужно текущему пользователю?
3. Нет ли IDOR (Insecure Direct Object Reference): может ли пользователь получить объект другого пользователя по прямой манипуляции ID?
4. Согласована ли RBAC-логика между сервисами (особенно в микросервисной архитектуре)?
5. Есть ли проверки авторизации перед административными функциями?
6. Нет ли закомментированного кода с @AllowAnonymous, @PermitAll или аналогами на чувствительных endpoint'ах?
7. Нет ли расширения IAM-ролей или scope'ов в инфраструктурном коде (Terraform, Helm charts, AWS CDK)?

Решение:

• Обнаружены IDOR или отсутствие проверки авторизации → блокировать merge.
• Новый admin endpoint без явной проверки роли → блокировать merge.
• Необоснованное расширение IAM-прав в IaC → блокировать merge, проводить архитектурное ревью.
• Незначительные несоответствия стилю проверок → отправить на доработку.

Уровень 4. Валидация входных данных и обработка ошибок

LLM стабильно генерирует код, который плохо обрабатывает граничные случаи. По данным исследования NCBI/Frontiers (2024), AI-инструменты не предотвращают XSS в 86% тестовых случаев, а log injection встречается в 88% AI-сгенерированных сценариев [13]. SQL injection в AI-коде имеет 80%-й pass rate — что значит: каждый пятый сгенерированный запрос к БД потенциально уязвим [1].

Что проверять:

1. Используются ли параметризованные запросы для всех обращений к БД (не конкатенация строк)?
2. Валидируются ли все пользовательские данные на стороне сервера (не только на клиенте)?
3. Нет ли прямой передачи raw user input в системные команды, file path'ы или шаблонизаторы?
4. Корректно ли обрабатываются ошибки: не раскрывают ли они stack trace, внутренние пути или структуру БД?
5. Логируются ли security-значимые события (неудачные попытки аутентификации, ошибки авторизации) без записи паролей, токенов или PII?
6. Обрабатываются ли граничные случаи: null, пустые строки, слишком длинные данные, неожиданные типы?
7. Для API-endpoint'ов: есть ли rate limiting, валидация MIME-типа загружаемых файлов, ограничение размера?

Решение:

• Конкатенация строк в SQL-запросах → блокировать merge.
• Необработанный user input в exec, subprocess, eval или аналогах → блокировать merge.
• Раскрытие внутренней информации в error response → отправить на доработку.
• Отсутствие валидации для некритичных полей → отправить на доработку с указанием приоритета.

Уровень 5. Криптография и конфигурация

AI-модели воспроизводят паттерны из обучающих данных, которые включают устаревшие алгоритмы и небезопасные реализации. Исследование Veracode зафиксировало 14%-й failure rate на задачах, связанных с криптографическими реализациями [1]. OWASP ASVS 5.0, выпущенный в 2025 году, добавил требования по post-quantum cryptography и явно запрещает MD5, SHA-1 и небезопасные алгоритмы симметричного шифрования в новом коде [11].

Инцидент 2025 года с GitHub Action tj-actions/changed-files (CVE-2025-30066) показал, как некорректная конфигурация CI/CD-файлов позволяет секретам попасть в workflow logs — в этом случае были затронуты более 23 000 репозиториев, CISA выпустила экстренное оповещение [14].

Что проверять:

1. Не используются ли устаревшие алгоритмы: MD5, SHA-1, DES, RC4, ранние версии TLS (< 1.2)?
2. Нет ли хардкоженых cryptographic keys или IV (initialization vector)?
3. Корректно ли настроены HTTP security headers: CORS (не *), CSP, HSTS, X-Content-Type-Options?
4. Корректна ли конфигурация окружения: debug-флаги выключены в production, нет избыточного логирования?
5. CI/CD-файлы: секреты получаются из secrets backend, а не вшиты в YAML?
6. Инфраструктурный код (Terraform, Helm, Kubernetes manifests): нет ли открытых портов, отключённой TLS, публично доступных bucket'ов?
7. Используются ли cryptographically secure random number generators для генерации токенов, session ID, nonce?

Решение:

• Устаревшие криптоалгоритмы в новом коде → отправить на доработку.
• CORS: Access-Control-Allow-Origin: * на эндпоинтах с авторизацией → блокировать merge.
• Debug-режим активен в production-конфигурации → блокировать merge.
• Секреты в CI/CD YAML → блокировать merge, немедленно ротировать.

Уровень 6. Логика, тесты и покрытие

Последний уровень — и единственный, где нет универсального автоматического решения.

AI-код часто корректен для happy path, но хрупок на граничных случаях. Логические уязвимости — нарушения business logic, некорректные предположения о состоянии, race conditions — инструменты автоматического анализа не видят. Согласно данным Habr (опыт команд, использующих AI-ревью), основная ценность человека на ревью — именно в архитектурных решениях и проверке бизнес-логики, а не в стилевых правках [15].

Что проверять:

1. Покрывают ли тесты негативные кейсы: неверный ввод, граничные значения, отказы зависимостей?
2. Проверяют ли тесты авторизацию: нет ли тестов, которые запускаются под admin и маскируют проблему с правами обычного пользователя?
3. Нет ли dead code, закомментированного legacy-кода или временных обходных решений, вошедших в PR?
4. Соответствует ли изменение описанию в PR (AI иногда вносит изменения за пределами заявленной области)?
5. Для изменений в бизнес-логике: понятен ли инварант, который обеспечивает код?
6. Для служебных компонентов (миграции БД, CI-скрипты, internal tools): прочитаны ли они так же тщательно, как прикладной код?

Решение:

• Нет тестов для новой функциональности → отправить на доработку.
• Логика конфликтует с требованиями в задаче, но не сломана технически → отправить на доработку с пояснением.
• Dead code или временный workaround без TODO → отправить на доработку.

Часть 3. Decision framework: принять, доработать или заблокировать

Когда принять PR с AI-кодом

1. Все шесть уровней проверки пройдены без замечаний критического уровня.
2. Новые зависимости верифицированы и проверены на CVE.
3. Тесты покрывают граничные случаи, включая авторизацию.
4. Конфигурационные файлы не содержат секретов и debug-настроек.
5. Изменение соответствует описанию в PR.

Когда отправить на доработку

1. Есть замечания по валидации или обработке ошибок без критического security-импакта.
2. Нет тестов или покрытие неполное.
3. Незафиксированные версии зависимостей или незнакомый пакет без обоснования.
4. Незначительные криптографические риски (устаревший алгоритм в некритичном контексте).
5. Стиль обработки ошибок раскрывает больше информации, чем нужно.

Когда блокировать merge

1. Обнаружены секреты или учётные данные в коде или CI/CD-файлах.
2. Несуществующий пакет в зависимостях.
3. CVE критического или высокого уровня в новых зависимостях.
4. SQL injection, IDOR, отсутствие проверки авторизации.
5. CORS * на endpoint'ах с авторизацией.
6. Debug-режим или избыточное логирование в production-конфигурации.
7. Необоснованное расширение IAM-прав.
8. Изменение CI/CD-файлов с риском утечки секретов (как в CVE-2025-30066).

Часть 4. Инструментальный стек: автоматизация и ручное ревью

Правильная комбинация инструментов позволяет смещать часть проверок влево — в IDE и CI — и не тратить время Tech Lead на то, что машина ловит надёжнее.

Что автоматизировать в CI

1. SAST (статический анализ кода): Semgrep, SonarQube, CodeQL. Находят синтаксические уязвимости, известные паттерны injection, небезопасные API. Важно понимать: SAST не видит архитектурные проблемы, поэтому не заменяет ручное ревью авторизационной логики [16].
2. SCA (анализ состава ПО): Snyk, Dependabot, OWASP Dependency-Check. Проверяют все зависимости на известные CVE, флагуют устаревшие пакеты [11].
3. Secret scanning: GitGuardian, GitHub Secret Scanning, truffleHog. Сканируют diff на паттерны секретов до merge [4].
4. IaC scanning: Checkov, Terrascan, tfsec. Проверяют Terraform, Helm charts, Kubernetes manifests на небезопасные конфигурации [17].

Важно: все перечисленные инструменты работают на уровне паттернов и известных уязвимостей. Они не заменяют контекстный анализ конкретного изменения в связке с архитектурой системы.

Что требует взгляда человека

В системном обзоре MIT/Frontiers (2024) авторы фиксируют: AI-инструменты улучшились в обнаружении уязвимостей (с ~50% до ~75–80% по данным 2025 года), но "LLM могут уверенно предоставлять неверную информацию, что создаёт риск для менее опытных разработчиков" [18].

Ручное ревью Tech Lead или AppSec-специалиста необходимо для:

1. Кода аутентификации и авторизации — любого.
2. Платёжных и финансовых операций.
3. Обработки PII и чувствительных данных.
4. Изменений в IaC, касающихся IAM-ролей.
5. Новых интеграций с внешними сервисами.
6. Служебного кода: миграций БД, CI/CD-скриптов, internal tools.
7. Любого изменения в security-контролях или middleware.

Практика ByteDance и Google показывает: эффективная схема — последовательный анализ (безопасность → производительность → стиль), где автоматика закрывает первую линию, а человек фокусируется на архитектурном контексте [15].

Часть 5. Специфика служебного кода и конфигураций

Практика показывает, что служебный код читают хуже всего. Инженер, внимательно изучающий бизнес-логику в Python, может пробежать глазами YAML CI-файл и не заметить критической проблемы.

Между тем CISA/NCSC Guidelines for Secure AI System Development (совместный документ 23 регуляторов, 2023/2024) прямо указывает: обеспечение безопасности supply chain, CI/CD-конфигураций и компонентного состава — обязательная часть secure development lifecycle [19].

CI/CD-файлы

1. GitHub Actions, GitLab CI, Jenkinsfile — это исполняемый код с доступом к secrets и production-окружению.
2. Проверяйте pinning actions по SHA-хешу, а не по тегу (атака tag poison).
3. Проверяйте, не выводятся ли секреты в logs (даже masked).
4. Ограничивайте permissions для GITHUB_TOKEN до минимально необходимых.

Migrations и схемы БД

1. Необратимые миграции (DROP, TRUNCATE) требуют явного подтверждения.
2. Проверяйте, не появляются ли поля, в которые AI-код будет писать PII без шифрования.
3. Убеждайтесь, что rollback-сценарий существует или документировано его отсутствие.

Internal tools и скрипты автоматизации

1. Часто работают с elevated privileges — проверяйте scope полномочий.
2. Нередко не покрыты тестами — требуйте хотя бы smoke-тестирования.
3. Проверяйте, не читают ли скрипты production-секреты из переменных среды без явной необходимости.

Часть 6. Типичные ошибки ревью AI-кода

Ошибка 1. Доверие к "чистому скану SAST"

SAST-инструменты эффективны для известных паттернов, но не для архитектурного дрейфа. Чистый отчёт SAST не означает отсутствие проблем с привилегиями или логикой.

Ошибка 2. Пропуск конфигурационных файлов

AI регулярно изменяет конфигурации за пределами заявленного scope PR. Всегда проверяйте полный список файлов в diff, не только изменённый прикладной код.

Ошибка 3. Принятие тестов без анализа покрытия

AI часто генерирует тесты, которые проверяют happy path под admin-пользователем. Это создаёт иллюзию покрытия, маскируя реальные authorization failures.

Ошибка 4. Игнорирование lock-файлов

package-lock.json, poetry.lock — критически важные артефакты безопасности. Незафиксированные или конфликтующие lock-файлы могут привести к установке неожиданной версии зависимости при сборке.

Ошибка 5. Не проверять, совпадает ли PR с его описанием

AI нередко делает изменения за пределами заявленного scope. Стандартная практика: сверяйте список файлов в diff с описанием задачи.

Ошибка 6. Пропуск служебного кода перед релизом

Именно там живут самые опасные незамеченные изменения. Скрипт деплоя, конфиг окружения, CI-workflow — их изменения требуют внимания не меньше, чем изменения в прикладном коде.

Часть 7. Тренды: куда движется ревью AI-кода

Agentic AI и новые риски

Gartner прогнозирует, что к концу 2026 года до 40% enterprise-приложений будут интегрированы с task-optimizing AI-агентами [20]. Агенты действуют с разрешениями сервисных аккаунтов — нередко избыточными. OWASP LLM06:2025 "Excessive Agency" фиксирует эту угрозу: агент с широкими правами, получив малicious инструкцию через prompt injection в PR-комментарии или issue, способен выполнить действия, которые никто не авторизовал [21].

В апреле 2026 года исследователь Aonan Guan опубликовал атаку "Comment and Control": вредоносные инструкции в GitHub issue body или PR title перехватывали Claude Code, Gemini CLI Action и GitHub Copilot Agent и заставляли их утекать CI-секреты через PR-комментарии [22]. Этот инцидент показывает: ревью PR теперь включает оценку того, что прочитают AI-агенты, работающие в вашем pipeline.

Рост вероятности slopsquatting

По данным исследования USENIX Security 2025: 43% галлюцинированных имён пакетов воспроизводятся стабильно при повторных запросах, 58% появляются более одного раза из десяти [3]. Это делает slopsquatting промышленно масштабируемой атакой: злоумышленнику достаточно нескольких запросов к LLM, чтобы составить список имён для регистрации на PyPI или npm.

OpenSSF рекомендует как минимум: явно требовать от AI использования проверенных, широко известных библиотек и формировать инструкции, запрещающие предлагать несуществующие или малоизвестные пакеты [9].

Shift-left и контроль до merge

Соноровский принцип "treat the PR as a gate" получает всё большее распространение. Данные 2024 года показывают: change-related failures были причиной 67% инцидентов с core-системами [16]. Инструменты, работающие непосредственно на уровне pull request — до merge — позволяют сократить этот риск, не создавая дополнительной нагрузки на команду.

Часть 8. Как HighVibe вписывается в этот workflow

HighVibe — дополнительный слой контроля, встроенный между написанием кода и merge. Он анализирует конкретное изменение в коде, конфигурации и зависимостях, оценивает его в контексте релиза и даёт короткий, понятный сигнал: можно ли безопасно принять именно это изменение сейчас.

Это не замена SAST, SCA или secret scanning — все эти инструменты решают свои задачи. HighVibe работает поверх них: там, где инструменты паттернов заканчиваются и начинается вопрос контекста конкретного PR. Он помогает Tech Lead'у или AppSec-инженеру не тонуть в длинных отчётах перед релизом, а получать практический ответ: что именно блокирует выпуск и какой следующий шаг.

Для команд, в которых AI-кодинг занял значительную долю разработки, это особенно актуально: скорость генерации кода опередила скорость роста культуры его проверки, и без явного gate между PR и main branch риск проходит незамеченным.

Подробнее о подходе: highvibe.dev

Заключение: что делать дальше

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

Практические шаги:

1. Внедрите структурированный чек-лист ревью по шести уровням выше — начните с уровней 1–3 (секреты, зависимости, права доступа): это даёт наибольший возврат на вложенное время.
2. Настройте автоматическое сканирование в CI: SAST, SCA, secret scanning, IaC-проверки. Это снимает рутину и освобождает внимание человека для архитектурного анализа.
3. Зафиксируйте, какие категории кода требуют обязательного ручного ревью специалиста по безопасности: аутентификация, авторизация, платежи, PII, служебный код.
4. Проверяйте lock-файлы и новые зависимости так же внимательно, как прикладной код.
5. Не доверяйте "чистому скану" без ручного просмотра кода авторизации.
6. Помните: "работает" не означает "безопасно для merge".

Источники

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

[2] SoftwareSeni — AI Generated Code Security Risks: Why Vulnerabilities Increase 2.74x — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[3] BleepingComputer — AI-hallucinated code dependencies become new supply chain risk — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[4] GitGuardian — Yes, GitHub Copilot Can Leak (Real) Secrets — https://blog.gitguardian.com/yes-github-copilot-can-leak-secrets/

[5] Veracode — AI-Generated Code Security Risks: What Developers Must Know — https://www.veracode.com/blog/ai-generated-code-security-risks/

[6] Medium / Michael Hannecke — AI Is Writing Your Code. Who's Checking for Vulnerabilities? — https://medium.com/@michael.hannecke/ai-is-writing-your-code-whos-checking-for-vulnerabilities-30377e98e0f2

[7] SoftwareSeni — Security Risks in AI-Generated Code and How to Mitigate Them — https://www.softwareseni.com/security-risks-in-ai-generated-code-and-how-to-mitigate-them/

[8] Vibe Owl — Why Your AI Copilot Keeps Leaking Secrets — https://vibeowl.dev/ai-copilot-leaking-secrets

[9] OpenSSF Best Practices Working Group — Security-Focused Guide for AI Code Assistant Instructions — https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions

[10] Aikido Security — Slopsquatting: The AI Package Hallucination Attack Already Happening — https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks

[11] Augment Code — Secure Code Review Checklist: OWASP-Aligned Framework — https://www.augmentcode.com/guides/secure-code-review-checklist-owasp-aligned-framework

[12] Blog Intelligence X — Broken Access Control (A01:2025): The #1 OWASP TOP 10 Vulnerability — https://blog.intelligencex.org/broken-access-control-owasp-a01-2025-complete-guide

[13] NCBI / Frontiers in Data Science — A systematic literature review on the impact of AI models on the security of code generation (2024) — https://www.ncbi.nlm.nih.gov/pmc/articles/PMC11128619/

[14] CodeAnt.ai — Secure Code Audits in 2025: Checklist and Best Practices — https://www.codeant.ai/blogs/source-code-audit-checklist-best-practices-for-secure-code

[15] Habr / MTS Tech — Первый шаг к кибернетическому тимлиду: автоматическое ревью кода на основе LLM — https://habr.com/ru/companies/ru_mts/articles/876482/

[16] Knostic — How to Secure AI Coding Assistants and Protect Your Codebase — https://www.knostic.ai/blog/ai-coding-assistant-security

[17] Beagle Security — Using AI-generated code safely (Vibe coding security) — https://beaglesecurity.com/blog/article/using-ai-generated-code-safely.html

[18] arXiv — Secure Coding with AI: From Detection to Repair (2025) — https://arxiv.org/pdf/2504.20814

[19] CISA / NCSC — Guidelines for Secure AI System Development — https://www.ncsc.gov.uk/collection/guidelines-secure-ai-system-development

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

[21] OWASP GenAI Security Project — OWASP Top 10 for LLM Applications 2025 — https://genai.owasp.org/llm-top-10/

[22] VPN Central — GitHub Comments Can Hijack Claude Code, Gemini CLI, and Copilot to Steal CI Secrets — https://vpncentral.com/github-comments-can-hijack-claude-code-gemini-cli-and-copilot-to-steal-ci-secrets/