Что проверить перед релизом, если часть кода написана ИИ

Рабочая программа безопасности для команд, которые уже ускорили разработку с AI-ассистентами

Почему это важно именно сейчас

По данным опроса Checkmarx и Censuswide, в 2024 году уже около 70% респондентов (CISO, AppSec-менеджеры, разработчики) оценили долю AI-сгенерированного кода в своих организациях на уровне более 40% [4]. Согласно Stack Overflow Developer Survey 2024, 76% разработчиков применяют AI-инструменты в работе [4].

Это не будущее — это настоящее. И контроль изменений за скоростью не успел.

Проблема не в том, что AI пишет «плохой» код в грамматическом смысле. Синтаксических ошибок стало меньше на 76%, логических багов — на 60% [3]. AI хорошо справляется с тем, что легко проверяется автоматически. Но именно там, где проверка требует понимания архитектурного контекста, — там и накапливается долг. По данным исследования Apiiro по Fortune 50-компаниям, архитектурные дефекты в AI-коде выросли на 153%, а пути до эскалации привилегий — на 322% [3]. The Register процитировал исследователей точно: «AI исправляет опечатки, но создаёт бомбы замедленного действия» [5].

Добавьте к этому то, что AI-сгенерированный код получает менее тщательный ревью, чем написанный людьми: разработчик чувствует меньше ответственности за него и сначала проверяет, работает ли, а не безопасен ли [4]. По данным Checkmarx, 58% разработчиков доверяют выводам AI без дополнительного тестирования [4].

Результат: к июню 2025 года AI-код добавлял более 10 000 новых security-находок в месяц в репозиториях, которые мониторила Apiiro — это рост в 10 раз по сравнению с декабрём 2024 года [6].

Ниже — семь направлений, которые нужно проверить до нажатия кнопки релиза, если часть кода написана с помощью AI.

Слой 1. Секреты и учётные данные

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

AI-ассистенты систематически генерируют захардкоженные API-ключи, токены, пароли и строки подключения к базам данных — особенно когда разработчик передаёт в промпт реальные значения «для контекста». По данным Apiiro, разработчики, использующие AI, в 1,4 раза чаще оставляли чувствительные учётные данные в коде по сравнению с теми, кто писал вручную [3]. Исследование по открытым репозиториям GitHub показало, что только в 2025 году было обнаружено более 28 миллионов скомпрометированных учётных данных [7]. Показательна статистика из другого источника: 82% обнаруженных секретов остаются активными даже после публичного раскрытия [8].

Что делать:

1. Запустить сканер секретов по всей git-истории — не только по HEAD: инструменты типа Gitleaks, TruffleHog или GitGuardian ggshield просматривают каждый коммит и каждую ветку, в том числе те, из которых уже удалили секрет. Удалённый из кода секрет по-прежнему живёт в git-объектах и может быть восстановлен [7].
2. Проверить .env-файлы, переменные в CI/CD-пайплайне и конфигурационные файлы ассистента — именно там разработчики нередко оставляют реальные значения.
3. Ротировать все секреты, которые когда-либо были скоммичены, даже если они уже удалены.
4. Стандартный SAST не заменяет сканер секретов: это разные инструменты с разной областью охвата [7].

Отдельный риск — конфигурации MCP-серверов. Официальная документация экосистемы MCP долгое время рекомендовала примеры с API-ключами прямо в конфигах. Разработчики копировали паттерн — и коммитили реальные ключи вместе с плейсхолдерами [7]. Если в вашей разработке используются AI-агенты или MCP, проверьте их конфигурационные файлы отдельно.

Слой 2. Зависимости: slopsquatting и supply chain

Это новый класс риска, специфичный именно для AI-кода.

LLM систематически галлюцинируют несуществующие пакеты. Исследование, опубликованное в марте 2025 года командами университетов Техаса, Оклахомы и Вирджинии и презентованное на USENIX Security 2025, проверило 16 моделей на 576 000 образцах Python- и JavaScript-кода. Примерно в 20% случаев рекомендованные пакеты не существовали в публичных репозиториях [9, 10]. Даже у коммерческих моделей вроде ChatGPT-4 ставка галлюцинаций составляла около 5% — масштаб делает это значимым [10].

Атака получила название slopsquatting (термин ввёл Сет Ларсон, Developer-in-Residence Python Software Foundation): злоумышленники изучают, какие несуществующие пакеты регулярно генерируют разные модели, и заблаговременно публикуют в npm или PyPI пакеты с теми же именами — с вредоносной нагрузкой [11]. Когда разработчик устанавливает «рекомендованный» пакет, цепочка зависимостей оказывается скомпрометированной.

Показательный пример: исследователь Бар Ланьядо в начале 2024 года заметил, что модели регулярно галлюцинируют пакет huggingface-cli. Он зарегистрировал безобидную заглушку — и за три месяца получил более 30 000 реальных загрузок. Alibaba скопировала галлюцинированную команду установки в README своего публичного репозитория [12].

Что делать:

1. Запустить SCA-анализ (Software Composition Analysis) по всем прямым и транзитивным зависимостям с верификацией существования пакета в реестре до установки — не после [13].
2. Проверить lock-файлы: они должны быть актуальными и зафиксированными (pinned) до точного digest/hash, а не только по версии.
3. Проверить наличие CVE для каждой добавленной зависимости по NVD и OSV.dev.
4. Оценить лицензии: AI нередко предлагает компоненты с GPL/AGPL, что создаёт юридические риски при коммерческой разработке [14].
5. Проверить файлы CI/CD-пайплайна отдельно — в марте 2025 года атака на tj-actions/changed-files (популярный GitHub Action) затронула более 23 000 репозиториев через подмену тегов: злоумышленник перенаправил существующие теги на вредоносный коммит, который сбрасывал секреты CI/CD в публичные логи [15].

Отдельно: AI генерирует приложения с избыточным деревом зависимостей. По данным Endor Labs, простой промпт «напиши to-do list app» производил от 2 до 5 бэкенд-зависимостей в зависимости от модели [16]. Каждая новая зависимость — это потенциальная поверхность атаки.

Слой 3. SAST: статический анализ, но с правильными правилами

SAST-инструменты (Static Application Security Testing) — это стандарт, но для AI-кода их надо настраивать дополнительно.

Классические SAST хорошо находят синтаксически детерминированные уязвимости: SQL-инъекции, XSS, insecure deserialization, небезопасные алгоритмы шифрования. Именно они покрывают большую часть OWASP Top 10 для веб-приложений [17].

Проблема: AI производит ошибки, которые синтаксически корректны, но семантически опасны. Архитектурный дрейф — это когда модель незаметно меняет дизайн: например, заменяет криптографическую библиотеку или убирает проверку прав доступа. Код компилируется и запускается. SAST не видит проблемы. Но security-инвариант нарушен [16].

Что делать:

1. Не снижать покрытие SAST только потому, что код пришёл от AI — поступайте ровно наоборот [13].
2. Настроить severity-пороги специально под типичные провалы AI-кода: missing authentication/authorization, SSRF, CSRF, insecure deserialization, hardcoded credentials — эти классы не всегда получают критический CVSS, но регулярно эксплуатируются [13].
3. Добавить кастомные правила для паттернов, специфичных для вашего стека. OpenSSF в своём руководстве по безопасному AI-кодингу рекомендует симулировать запуск инструментов типа CodeQL, Bandit, Semgrep и OWASP Dependency-Check прямо во время ревью [18].
4. Настроить автоблокировку merge/deploy при появлении новых критических или высоких SAST-находок выше заданного порога [13].

Особое внимание — Java: в исследовании Veracode именно Java показала наибольший failure rate — 72% при тестировании на secure coding benchmarks [1].

Слой 4. DAST и тестирование бизнес-логики в runtime

Статического анализа недостаточно, потому что часть уязвимостей AI-кода проявляется только в runtime: сломанные authentication-флоу, обходы авторизации, race conditions.

DAST (Dynamic Application Security Testing) запускается против работающего экземпляра приложения и проверяет то, что SAST в принципе не может увидеть. Стандартный инструмент — OWASP ZAP, который умеет делать как baseline-сканирование, так и аутентифицированные проверки с импортом OpenAPI-спецификации [17].

Особый риск для AI-кода: prompt injection. В 2026 году CVE-2025-53773 показала, что скрытая инъекция промпта в описании pull request позволяла выполнить произвольный код через GitHub Copilot — CVSS 9.6 [19]. Prompt injection с 2025 года занимает позицию LLM01 в OWASP Top 10 for LLM Applications [20].

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

1. Запустить DAST против staging-окружения, не продакшена. Используйте ephemeral environments через Docker Compose или PR preview для изоляции [17].
2. Проверить аутентификацию и авторизацию вручную. Это нельзя делегировать автоматике: Apiiro обнаружила, что 30% путей privilege escalation не обнаруживаются автоматическими инструментами и требуют архитектурного анализа человеком [3].
3. Проверить input validation: AI инструменты стабильно не справляются с защитой от XSS — инструмент не предотвращал XSS в 86% тестовых случаев по данным из одного крупного сравнительного исследования [8].
4. Проверить error paths, concurrency primitives и boundary conditions — AI нередко генерирует happy-path-код без обработки исключений.

Отдельная точка внимания: если в приложении есть интеграция с LLM-моделями (RAG-пайплайны, агенты, инструменты с доступом к внешним данным), нужно проверить защиту от prompt injection на уровне самого приложения — система-промпты не являются security controls по определению OWASP [20].

Слой 5. Архитектурный и логический ревью

Это самый дорогой слой, но при AI-разработке он становится обязательным, а не опциональным.

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

• удаляются или обходятся проверки прав доступа;
• меняется криптографическая библиотека или параметры шифрования;
• появляются новые API-эндпоинты без авторизации;
• изменяется логика работы с сессиями или токенами.

Исследование CodeRabbit, опубликованное в декабре 2025 года, проанализировало 470 open-source GitHub pull requests и зафиксировало, что AI-co-authored код содержит примерно в 1,7 раза больше major issues по сравнению с кодом, написанным людьми [21].

Практический подход:

1. Мандатный человеческий ревью всех изменений в authentication и authorization логике — без исключений [16].
2. Проверить, не изменила ли AI что-то в конфигурации CORS. Слишком широкий CORS — типичный артефакт AI-кода, который хочет «решить проблему» быстро.
3. Проверить, не добавлены ли debug-режимы, verbose logging, или временные bypass в флагах и конфигурации. AI часто оставляет их «для разработки».
4. Отдельно просмотреть служебный код, конфигурационные файлы, скрипты миграции БД и internal tools — их читают хуже всего и при ревью, и при AI-кодинге.
5. Для критичных зон (платежи, аутентификация, криптография) установить запрет на AI-генерацию вообще и требовать написания и ревью кода человеком — это рекомендация ряда CISO-гайдлайнов 2025 года [3].

Именно здесь инструменты, анализирующие конкретное изменение в контексте системы, — а не весь репозиторий целиком — дают наиболее точный сигнал. HighVibe, например, работает именно на этом слое: он анализирует конкретный diff в контексте релиза и даёт короткий ответ — что именно блокирует выпуск, а не длинный список всех находок [highvibe.dev].

Слой 6. Конфигурация и Infrastructure as Code

Конфигурационные файлы и IaC-скрипты — отдельная поверхность атаки, которую AI генерирует активно, но которую ревьюят хуже всего.

Apiiro зафиксировала, что 41% AI-сгенерированного backend-кода содержит слишком широкие разрешения, а в 33% cloud-скриптов обнаруживаются пути до privilege escalation [8]. В области IAM (Identity and Access Management) misconfigured роли встречаются примерно в 50% AI-assisted cloud deployments [8].

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

1. IAM-роли и permissions: принцип least privilege — каждый сервис, функция или контейнер должны иметь минимально необходимые права. Проверить, не выдал ли AI дефолтный admin-level доступ.
2. Network security groups и CORS: проверить, что открыты только необходимые порты и origins.
3. Секреты в CI/CD-пайплайне: убедиться, что они не захардкожены в yaml/json-файлах пайплайна и используют механизмы secrets management платформы (GitHub Secrets, HashiCorp Vault, AWS Secrets Manager и т.д.) [24].
4. IaC-скрипты (Terraform, Pulumi, Helm charts, Kubernetes manifests): запустить специализированные IaC-сканеры (tfsec, Checkov, Trivy для конфигов) — они ищут типичные паттерны небезопасной конфигурации, которые SAST для кода не видит.
5. Dockerfile и container images: убедиться, что базовый образ актуален, нет флага --privileged без обоснования, и секреты не встроены в image [24].

Слой 7. SBOM и трассировка состава релиза

Последний слой, но один из самых стратегически важных — особенно для команд, работающих в регулируемых отраслях или с enterprise-клиентами.

SBOM (Software Bill of Materials) — это машиночитаемый инвентарь всех компонентов, зависимостей и метаданных программного продукта. В 2025 году CISA вместе с партнёрами G7 опубликовала «Software Bill of Materials for AI: Minimum Elements» — первый международный документ, определяющий минимальный состав SBOM применительно к AI-системам [22]. EU AI Act уже требует технической документации для high-risk AI-систем, а практические требования по AIBOM (AI Bill of Materials) начали появляться в контрактах enterprise-клиентов в 2026 году [23].

Зачем это нужно до релиза:

• Если после релиза появится CVE в зависимости, вы сможете определить, затронуты ли ваши системы, за минуты, а не дни.
• SBOM позволяет командам AppSec приоритизировать устранение реальных рисков, а не делать паническое ручное сканирование.
• При инциденте вроде Log4Shell наличие SBOM у компании принципиально меняло скорость реакции.

Что делать:

1. Автоматизировать генерацию SBOM в CI/CD-пайплайне — стандартные форматы CycloneDX и SPDX поддерживаются инструментами Syft, Trivy, и рядом других [43].
2. Версионировать SBOM вместе с каждым релизом — это аудиторский след.
3. Для AI-сгенерированного кода отслеживать не только зависимости, но и какие модели и конфигурации AI-ассистентов использовались. Концепция AIBOM включает информацию о моделях, датасетах, prompt-конфигурациях и ML-фреймворках [23].

Типичные ошибки перед релизом

Ниже — наиболее частые провалы, которые команды допускают именно при AI-разработке.

Ошибка 1: «Код прошёл ревью, значит, он безопасен». Исследование показывает, что код ревьюируется менее тщательно, когда он сгенерирован AI: функциональная корректность проверяется в первую очередь, security — во вторую или не проверяется вообще [4]. Сам факт прохождения ревью не является security-gate.

Ошибка 2: «Мы используем SAST, нам достаточно». SAST не видит архитектурный дрейф, не верифицирует существование пакетов, не сканирует git-историю на секреты и не тестирует runtime-поведение. Нужна комбинация слоёв [13].

Ошибка 3: «AI сам позаботится о безопасности, если попросить». Prompting снижает вероятность уязвимостей, но не устраняет её: даже при явных инструкциях модели стабильно генерируют захардкоженные учётные данные и пропускают input validation [16]. Нельзя строить security-модель на поведении стохастической системы.

Ошибка 4: «Lock-файлы зафиксированы, supply chain в порядке». Если пакет существует в реестре и не содержит известных CVE — это ещё не означает, что он безопасен. Slopsquatting позволяет атакующим заранее зарегистрировать пакет с именем, которое AI постоянно галлюцинирует [11]. Необходима поведенческая проверка пакетов, а не только сверка с CVE-базами.

Ошибка 5: «Конфиги и скрипты миграции — не код, их не надо проверять». Это распространённое упущение. AI активно генерирует IaC, CI/CD-конфиги и скрипты миграции — и именно там концентрируется часть архитектурных рисков: избыточные IAM-роли, небезопасные открытые порты, debug-флаги, незафиксированные зависимости пайплайна [3, 13].

Практический decision framework: что блокирует релиз, а что нет

Не все находки одинаково критичны. Ниже — ориентиры для принятия решения.

Жёсткий блок релиза (никакой merge/deploy до устранения):

1. Обнаруженный активный секрет или учётные данные в коде или git-истории.
2. Подтверждённая уязвимость в прямой зависимости с CVSS 9.0+ и доступным эксплойтом.
3. Обнаруженное изменение в authentication или authorization логике без явного мандатного ревью.
4. Hallucinated пакет, установленный из реестра без верификации.
5. Критическая SAST-находка в коде, обрабатывающем пользовательский ввод или платёжные данные.

Требует human review перед релизом:

1. Изменения в конфигурации CORS, IAM-ролях, network policies.
2. Новые API-эндпоинты без явной документации и authorization.
3. Любые изменения в cryptographic primitives или алгоритмах хеширования.
4. Добавление новых зависимостей с неизвестной или короткой историей в реестре.
5. Изменения в CI/CD-конфигурации или IaC-скриптах.

Можно логировать и мониторить без блока:

1. Low/medium SAST-находки в коде без обработки внешнего ввода.
2. Устаревшие (но без критических CVE) версии транзитивных зависимостей.
3. Minor code quality issues — технический долг, не security.

Кейсы и сценарии: где это уже пошло не так

Теория подтверждается реальными инцидентами.

Атака на tj-actions (март 2025): злоумышленник подменил теги популярного GitHub Action, перенаправив их на вредоносный коммит. Скрипт дампил секреты CI/CD в публичные логи воркфлоу — это затронуло более 23 000 репозиториев [15]. Этот сценарий стал возможным именно потому, что зависимости пайплайна не были закреплены по digest.

Huggingface-cli (2024): AI-модели регулярно галлюцинировали команду pip install huggingface-cli — несуществующий пакет. Исследователь Ланьядо зарегистрировал заглушку — и Alibaba скопировала команду прямо в README своего публичного репо [12]. Пакет скачали более 30 000 раз. Атакующий мог разместить вредонос.

CurXecute (CVE-2025-54135): RCE-уязвимость в IDE Cursor AI, раскрытая в начале 2026 года, позволяла злоумышленнику выполнить произвольный код на машине разработчика без взаимодействия с пользователем [13]. Это напоминает: сам инструмент AI-кодирования является точкой риска.

EchoLeak (Microsoft 365 Copilot): zero-click prompt injection, которая позволяла без какого-либо действия со стороны пользователя получить доступ к корпоративным данным и тихо их экспортировать [19].

Что меняется с агентным AI

С выходом агентных инструментов — фоновых агентов Cursor, autonomous coding agents, MCP-серверов с прямым доступом к репозиторию — поверхность атаки расширяется.

Агент с доступом к репозиторию, триггерами пайплайна и секретами — это цель высокой ценности при компрометации. Основные новые риски:

1. Агент может установить зависимость без явного одобрения разработчика.
2. Prompt injection в pull request description теперь может быть вектором для RCE через coding assistant [19].
3. Skills и MCP-серверы легко поддаются tampering — если атакующий модифицирует skill, который команда использует для генерации кода, все последующие артефакты оказываются под вопросом [37].

NIST SP 800-207 (Zero Trust Architecture) требует рассматривать каждую агентную сессию как untrusted по умолчанию, с ограниченными и временными учётными данными [51]. OWASP LLM Top 10 v2025 прямо выделяет «Excessive Agency» (LLM06) как отдельный класс рисков [20].

Практический вывод: перед релизом нужно проверить, что агентные инструменты, участвовавшие в разработке этого релиза, имели только необходимый минимум разрешений, и что ни один skill или MCP-сервер не был изменён в процессе работы.

Для команд в России и СНГ

Дополнительный контекст для локального рынка.

По данным Positive Technologies, 42% российских компаний уже используют SAST/DAST, аудит кода и обновление зависимостей [35]. ФСТЭК проводит сертификацию процессов разработки, включая требования по SAST, SCA и SBOM. Эти требования закреплены в стандарте РБПО (Руководящий документ по безопасной разработке программного обеспечения) [35].

Для команд в государственном и финансовом секторе, работающих с данными, охраняемыми законодательно, локальный контур разработки и выбор AI-инструментов с контролируемой передачей данных — дополнительный фактор. Отечественные ассистенты вроде GigaCode и SourceCraft имеют иной profil с точки зрения данных по сравнению с глобальными аналогами — это важно учитывать при построении security-периметра [34].

Заключение

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

Перед каждым релизом, в котором есть AI-сгенерированный код, нужно пройти семь слоёв:

1. Секреты — полная проверка git-истории.
2. Зависимости — SCA с верификацией существования и проверкой CVE.
3. SAST — с правилами, откалиброванными под типичные провалы AI.
4. DAST и бизнес-логика — в runtime, включая аутентификацию и авторизацию.
5. Архитектурный ревью — мандатный для auth, crypto, новых endpoints.
6. Конфиги и IaC — IAM, CORS, секреты в пайплайне.
7. SBOM — инвентарь состава релиза.

Ни один из этих слоёв не заменяет другой. Их нужно комбинировать и встраивать в CI/CD как обязательные gates — иначе они становятся чек-боксами, которые заполняют задним числом.

Если вам нужен не ещё один длинный security-отчёт, а короткий и понятный сигнал прямо перед merge или деплоем — именно для этого создан HighVibe. Он анализирует конкретное изменение в контексте релиза и отвечает на вопрос, что именно критично сейчас. highvibe.dev

Источники

[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 and How to Prevent Them" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/

[3] The Register — "AI code assistants improve production of security problems" — https://www.theregister.com/2025/09/05/ai_code_assistants_security_problems/

[4] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/

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

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

[7] Snyk — "Why 28 million credentials leaked on GitHub in 2025" — https://snyk.io/articles/state-of-secrets/

[8] 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/

[9] SecurityWeek — "AI Hallucinations Create a New Software Supply Chain Threat" — https://www.securityweek.com/ai-hallucinations-create-a-new-software-supply-chain-threat/

[10] 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/

[11] Snyk — "Slopsquatting: New AI Hallucination Threats & Mitigation Strategies" — https://snyk.io/articles/slopsquatting-mitigation-strategies/

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

[13] Xygeni — "How to Secure AI-Generated Code in CI/CD" — https://xygeni.io/blog/how-to-secure-ai-generated-code-in-ci-cd/

[14] OpsMx — "AI-Generated Code Security Checklist: 7 Policies for CISOs" — https://www.opsmx.com/blog/ai-generated-code-security-checklist-7-policies-every-ciso-needs/

[15] Cycode — "OWASP Top 10 2025: Addressing Software Supply Chain and LLM Risks" — https://cycode.com/blog/the-2025-owasp-top-10-addressing-software-supply-chain-and-llm-risks-with-cycode/

[16] Endor Labs — "The Most Common Security Vulnerabilities in AI-Generated Code" — https://www.endorlabs.com/learn/the-most-common-security-vulnerabilities-in-ai-generated-code

[17] OX Security — "Application Vulnerability Assessment: A Practical Guide for Modern DevSecOps Teams" — https://www.ox.security/blog/application-vulnerability-assessment/

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

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

[20] OWASP — "Top 10 for LLM Applications 2025" — https://owasp.org/www-project-top-10-for-large-language-model-applications/

[21] Help Net Security — "AI code looks fine until the review starts" — https://www.helpnetsecurity.com/2025/12/23/coderabbit-ai-assisted-pull-requests-report/

[22] CISA — "Software Bill of Materials for AI: Minimum Elements" — https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements

[23] Kognitos — "The 'AI Bill of Materials' (AIBOM): What It Is and Why Your Procurement Team Will Ask for It" — https://www.kognitos.com/blog/ai-bill-of-materials-aibom-procurement-guide/

[24] OWASP — "CI/CD Security Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html

[25] CSET Georgetown — "Cybersecurity Risks of AI-Generated Code" — https://cset.georgetown.edu/wp-content/uploads/CSET-Cybersecurity-Risks-of-AI-Generated-Code.pdf

[26] Habr / Positive Technologies — "Тренды кибербезопасности 2025 года" — https://habr.com/ru/companies/pt/articles/943256/

[27] RBC Компании — "Как выбрать AI-ассистент для разработки в 2026 году: реальные сценарии" — https://companies.rbc.ru/news/AsjfEOrdOi/kak-vyibrat-ai-assistent-dlya-razrabotki-v-2026-godu-realnyie-stsenarii/

[28] Axiom JDK — "Безопасная разработка (РБПО)" — https://axiomjdk.ru/announcements/2025/11/13/bezopasnaya-razrabotka/