Почему ИИ пишет рабочий, но небезопасный код

Скорость без безопасности: как AI-ассистенты масштабируют уязвимости быстрее, чем команды успевают их закрывать

Введение: рабочий — не значит безопасный

Разработка с AI-ассистентами ускорилась. GitHub подтверждает, что 97% разработчиков уже используют AI-инструменты [7]. Google заявил, что 25% корпоративного кода компании генерируется с участием ИИ [8]. Команды сообщают о росте производительности на 30–50% [8].

Но есть проблема, которую цифры продуктивности не отражают: рабочий код и безопасный код — не синонимы.

LLM превосходно справляются с синтаксической корректностью. Они плохо справляются с безопасностью. Модели обучены на публичных репозиториях, где небезопасные паттерны встречаются повсеместно; они не знают архитектуры вашего приложения; они оптимизируют «принятый PR», а не «безопасный PR». Результат: pull request, который выглядит отлично, но несёт уязвимости, утечки секретов или несуществующие зависимости.

Эта статья разбирает механизмы того, почему так происходит, — и что с этим делать до merge и релиза.

Масштаб проблемы: что говорят данные

45% задач — уязвимый код

Veracode в своём отчёте 2025 GenAI Code Security Report протестировала более 100 LLM на 80 реальных задачах в Java, Python, C# и JavaScript [1]. Вывод: 45% кода содержали уязвимости из OWASP Top 10 — SQL injection, cross-site scripting, log injection, слабая криптография. Java оказалась самым рискованным языком: 72% задач привели к провалу security-тестов.

Важно: более новые и более крупные модели не показали значимого улучшения по безопасности [1]. Масштабирование или обновление данных для обучения само по себе не решает проблему.

2,74× больше уязвимостей по сравнению с кодом от людей

Независимое исследование Apiiro по Fortune 50 предприятиям показало, что AI-генерируемый код содержит в 2,74 раза больше уязвимостей, чем написанный людьми [2]. Это означает: на 10 000 строк, которые человек написал бы с 10 уязвимостями, AI-ассистент добавляет около 27. Кроме того, Apiiro зафиксировала рост количества путей для privilege escalation на 322%, design flaws — на 153%, exposure of secrets — на 40% [2].

10× рост находок за шесть месяцев

К июню 2025 года AI-код добавлял более 10 000 новых security-находок в месяц [3]. По сравнению с декабрем 2024 года это рост в 10 раз. Кривая не выравнивается — она ускоряется.

Вместе с тем исследование Apiiro зафиксировало, что PR на основе AI-кода стали крупнее и затрагивают больше файлов и сервисов, рассеивая внимание ревьюеров [3]. Incidents per pull request вырос на 23,5% при росте числа PR per author лишь на 20%.

Почему это происходит: корневые причины

1. Обучение на небезопасных паттернах

LLM учатся на публичных репозиториях, Stack Overflow и документации [9]. Этот массив включает:

• устаревшие API и deprecated-практики;
• небезопасные примеры без явной пометки «не делайте так»;
• hard-coded credentials в учебных примерах;
• MD5-хэши и другие слабые криптографические примитивы, которые 10 лет назад были нормой.

Если небезопасные паттерны доминируют в обучающих данных, модель воспроизводит их как статистическую норму [9]. Академическое исследование на датасете FormAI (112 тысяч программ) показало, что 51% кода GPT-3.5 содержит уязвимости; репликация на девяти моделях в 2024 году подняла эту цифру до 62% [10].

2. Отсутствие архитектурного контекста

Когда разработчик пишет код вручную, он понимает: какие данные чувствительны, какие API открыты наружу, какие требования по compliance применимы. AI-ассистент ничего этого не знает [11].

Типичный запрос «подключись к базе и покажи баллы пользователей» часто приводит к коду без аутентификации и авторизации — потому что их не было в промпте, а добавлять их по умолчанию модель не обязана [9].

3. Оптимизация функциональности, а не безопасности

Алгоритмы генерации кода у Copilot и аналогов стимулируют принятие предложения разработчиком — а не другие свойства качества [12]. Безопасность не является явным критерием, который модель максимизирует. Дополнительные проверки увеличивают сложность и могут снижать читаемость, поэтому модель их пропускает, если явно не попросить.

Исследование на университетской выборке подтвердило: при базовых промптах без security-требований некоторые LLM изначально генерируют до 65% небезопасного кода. При усиленном ручном сопровождении квалифицированного инженера этот показатель снижается почти до нуля [13]. Вывод: безопасность в AI-кодинге зависит от человека в цикле, а не от модели.

4. Эффект «ложного чувства безопасности»

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

Этот эффект прямо влияет на code review: дифы в AI-PR дочитывают не до конца, а сам факт «код работает» воспринимается как достаточный сигнал безопасности.

5. Устаревшие данные обучения

Модели имеют дату среза обучения. Они могут рекомендовать версии библиотек, у которых на момент обучения не было известных CVE — но которые были добавлены в advisories позднее [11]. Это создаёт скрытый supply chain-риск, невидимый ни для разработчика, ни для самой модели.

Три специфических класса риска AI-кода

Утечки секретов

GitGuardian в пятом ежегодном отчёте State of Secrets Sprawl (март 2026) зафиксировала 28,65 млн новых hard-coded секретов в публичных репозиториях GitHub за 2025 год — рост 34% год к году и наибольший за всю историю отчёта [4].

Коммиты с участием AI-ассистентов утекали секреты примерно вдвое чаще базового уровня: 3,2% против 1,5% для кода без AI [4]. Одна из причин: AI генерирует «рабочий прототип», в котором интеграции с API аутентифицируются через hard-coded ключи — потому что так быстро и потому что именно так сделано в обучающих примерах.

Ещё один новый вектор — MCP-конфигурационные файлы. Документация MCP-серверов нередко предлагает хранить credentials напрямую в конфиг-файлах; GitGuardian обнаружила 24 008 уникальных секретов, утёкших именно таким образом [4].

Slopsquatting: галлюцинированные зависимости как вектор атаки

Академическое исследование трёх университетов (UT San Antonio, Virginia Tech, University of Oklahoma, 576 000 сгенерированных образцов Python и JavaScript, 16 LLM) показало: около 20% рекомендованных пакетов не существовало ни в одном публичном реестре [5].

Атакующие воспользовались этим паттерном через механизм, который security-исследователь Сет Ларсон назвал slopsquatting [5]: регистрируй пакеты с именами, которые LLM галлюцинирует чаще всего, — и жди, когда разработчик установит их без проверки. 43% галлюцинированных имён повторяются при похожих запросах [5], что делает их предсказуемыми и привлекательными мишенями.

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

Архитектурные уязвимости: большой и незаметный риск

Самая сложная для обнаружения категория — не SQL injection, которую поймает SAST, а архитектурные недостатки: отсутствие CSRF-защиты, слишком широкий CORS, неправильно реализованная аутентификация, privilege escalation через недостаточно ограниченные endpoint.

Исследование Tenzai (декабрь 2025) проанализировало 15 production-приложений, собранных пятью крупными AI-инструментами: во всех 15 отсутствовала CSRF-защита, ни одно не имело security headers, каждое содержало SSRF-уязвимости [15]. Проверка API-security платформы Escape.tech на более чем 1400 vibe-coded production-приложениях показала: 65% имели security-проблемы, 58% — хотя бы одну критическую уязвимость [15].

Итеративное ухудшение: парадокс «улучшаем и делаем хуже»

Особого внимания заслуживает исследование, принятое в IEEE-ISTAS 2025: систематический анализ того, как security-свойства кода меняются при многораундовых «улучшениях» через LLM без участия человека [16].

Вывод: после пяти итераций автоматизированного AI-рефайнинга количество критических уязвимостей выросло на 37,6%. Иными словами, чем больше AI «полирует» код без human-in-the-loop, тем менее безопасным он становится — вне зависимости от намерений промпта.

Это особенно важно для vibe coding и agentic-сценариев, где модели работают в цикле автономно.

Проблема pull request: дифы не читают до конца

Помимо технических уязвимостей, есть операционный риск: как PR с AI-кодом проходят review.

AI-ассистированные PR в среднем крупнее. Они затрагивают больше файлов и сервисов одновременно [3]. Ревьюер сталкивается с большим объёмом изменений, часть из которых выглядит бесспорно корректной. Внимание рассеивается — и именно там, где код небезопасен, ревью становится менее тщательным.

CodeRabbit в анализе 470 open-source PR декабря 2025 года зафиксировала, что AI-соавторский код имел в 1,7 раза больше серьёзных проблем по сравнению с кодом, написанным человеком [17].

Проблема не только в качестве генерации — она в том, что контроль изменений не успел вырасти с той же скоростью, что и скорость генерации.

Что делать: практический чек-лист

До merge

1. Запускать SAST на каждый PR, включая AI-сгенерированные изменения — без исключений.
2. Проводить SCA на новые и обновлённые зависимости: проверять существование пакетов в официальных реестрах, сверять с advisories.
3. Сканировать на наличие hard-coded секретов (GitHub Secret Scanning, Gitleaks или аналоги) — до коммита, не после.
4. Проверять конфиги: CORS-политики, аутентификационные настройки, debug-режимы.
5. Для всего, что касается аутентификации, криптографии и авторизации — требовать ревью от специалиста, а не доверяться AI-сгенерированной реализации.

В зависимостях

1. Никогда не устанавливать пакет из AI-рекомендации без верификации его существования в официальном реестре (PyPI, npm, Maven и т.д.).
2. Поддерживать SBOM и отслеживать транзитивные зависимости.
3. Включить pinning версий и lock-файлы в процесс контроля.

Перед релизом

1. Определить, какие изменения действительно блокируют выпуск — не генерировать длинный отчёт на 200 находок, где 5 реально критичных теряются в шуме.
2. Проверять, не появились ли в коде debug-настройки, временные credentials или тестовые ключи, которые не должны попасть в production.
3. Выполнять DAST на staging перед каждым релизом.

В промпт-культуре команды

1. Явно включать security-требования в промпты: «реализуй с валидацией входных данных», «не используй hard-coded credentials», «применяй параметризованные запросы».
2. Обучать разработчиков тому, что «код работает» ≠ «код безопасен».
3. Запретить unsafe-промпты: «пропусти аутентификацию», «игнорируй проверки безопасности».

Почему масштабирование моделей не решает проблему

Данные Veracode по обновлению октября 2025 года: модели Anthropic, Google, Qwen и xAI, выпущенные между июлем и октябрем 2025, не показали значимого улучшения по безопасности [1]. Просто сделать модель больше или обновить обучающие данные недостаточно.

Одно исключение зафиксировано у reasoning-моделей OpenAI (GPT-5): они продемонстрировали 70–72% показателя прохождения security-тестов — против типичных 50–60% [1]. Исследователи связывают это с тем, что reasoning-процесс напоминает внутренний code review перед выводом.

Но даже 70–72% — это не «безопасный код». Это «28–30% вероятность уязвимости при каждой задаче».

Вывод: полагаться только на улучшение моделей нельзя. Нужны процессные и инструментальные контроли на стороне команды.

Роль человека в цикле: то, что нельзя делегировать

Академические данные единодушны: как только в цикл добавляется квалифицированный инженер с security-экспертизой, качество резко улучшается [13]. Проблема не в том, что AI не умеет генерировать безопасный код вообще — он умеет при правильных входных данных и обратной связи. Проблема в том, что без human-in-the-loop безопасность деградирует.

Это означает, что задача security-команды — не запретить AI-кодинг, а выстроить контрольные точки, где человек видит реальный риск, а не тонет в шуме из 200 низкоприоритетных предупреждений.

Именно здесь работает HighVibe: как дополнительный слой контроля до merge и релиза, который анализирует конкретное изменение, объясняет проблему понятным языком и помогает команде принять решение — «принять это изменение», «переработать», «остановить merge» — не заменяя SAST/SCA, а помогая сосредоточиться на том, что действительно критично прямо сейчас HighVibe.

Регуляторный контекст: что говорят агентства

NSA, CISA и международные партнёры (NCSC-UK, ASD ACSC, FBI и другие) выпустили в апреле 2024 года совместное руководство по безопасному развёртыванию AI-систем [18], а в мае 2025 — обновлённое руководство по защите данных, используемых для обучения и эксплуатации AI [19].

Ключевые сигналы от регуляторов:

• AI-генерируемый код требует тех же security-проверок, что и любой другой код.
• Supply chain AI-систем — обучающие данные, pre-trained модели, зависимости — подвержена специфическим рискам компрометации.
• Организации должны встраивать secure-by-design практики в AI-assisted разработку до того, как инструменты станут неотъемлемой частью workflow.

OWASP фиксирует Prompt Injection как риск №1 для LLM-приложений [14]: вредоносные инструкции в комментариях к коду, README или user story могут заставить AI-агента сгенерировать backdoor или обойти проверки. При использовании agentic-инструментов (Cursor, Windsurf, Claude Code) это превращается в supply chain-атаку нового поколения.

Ошибки, которые команды совершают чаще всего

1. Считают, что SAST-правила для человеческого кода покрывают AI-специфические паттерны — и не адаптируют проверки.
2. Не верифицируют пакеты из AI-рекомендаций; устанавливают без проверки существования в реестре.
3. Игнорируют конфиги: security headers, CORS, debug-режим, MCP-конфиги с credentials.
4. Не сканируют внутренние репозитории, считая их «безопасными по умолчанию» — хотя они в 6 раз чаще содержат hard-coded секреты [4].
5. Обнаруживают утёкшие секреты, но не отзывают их: 64% credentials, обнаруженных в 2022 году, оставались активными в 2025 году [4].
6. Доверяют «код работает» как достаточному критерию для merge в production.

Будущее: куда движется проблема

Тренды указывают на нарастание, а не на решение:

• Vibe coding и agentic-разработка (Cursor, Claude Code, Replit, Windsurf) расширяют автономию AI в генерации кода. Больше кода генерируется без явного ревью каждой строки.
• MCP-экосистема растёт быстрее, чем security-практики вокруг неё: конфиги с credentials, широкий доступ агентов к внешним системам.
• Число разработчиков без формального security-образования, использующих AI, увеличивается — это расширяет категорию «наивного доверия» модели.
• Atacking tooling также использует AI: злоумышленники быстрее находят паттерны галлюцинаций и регистрируют пакеты.

CISA и NSA уже рассматривают AI-in-OT как отдельный risk domain [18]. Это сигнал: регуляторное давление на security AI-кода будет расти.

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

ИИ изменил скорость разработки. Контроль изменений пока не успел вырасти с той же скоростью.

«Рабочий» pull request не обязательно безопасен. Синтаксически корректный код не гарантирует отсутствия уязвимостей. Новая или транзитивная зависимость может прийти незаметно — и быть либо несуществующей, либо вредоносной. Служебный код, конфиги, миграции и CI/CD-файлы проверяют хуже всего.

Практические шаги прямо сейчас:

1. Включить secret scanning в CI/CD — до merge, не после.
2. Верифицировать все пакеты из AI-рекомендаций в официальных реестрах.
3. Не доверять «код работает» как достаточному критерию для релиза.
4. Добавить explicit security-требования в промпты и стандарты команды.
5. Рассмотреть дополнительный слой контроля на уровне PR и релиза — чтобы критичные находки были видны до того, как они попадут в production.

Источники

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

[2] Apiiro — "4x Velocity, 10x Vulnerabilities: AI Coding Assistants Are Shipping More Risks" — https://apiiro.com/blog/4x-velocity-10x-vulnerabilities-ai-coding-assistants-are-shipping-more-risks/

[3] SoftwareSeni — "Why 45 Percent of AI Generated Code Contains Security Vulnerabilities" — https://www.softwareseni.com/why-45-percent-of-ai-generated-code-contains-security-vulnerabilities/

[4] GitGuardian — "State of Secrets Sprawl 2026" — https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026-pr/

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

[6] DEV Community / DryRun Security — "GitHub Copilot Security Flaws: Why AI Code Is Insecure" — https://dev.to/roymorken/github-copilot-security-flaws-why-ai-code-is-insecure-2026-data-264j

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

[8] Splyce AI — "Beyond The SDLC: The Future of Security in the Age of Agentic Development" — https://splyce.ai/Beyond-The-SDLC-Agentic-Security-Report%20(1).pdf.pdf)

[9] 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

[10] Medium / Derek Wang — "Security Pitfalls of AI Code Generation Tools — 2025 Update" — https://medium.com/@derekdw/security-pitfalls-of-ai-code-generation-tools-2025-update-8ded7e50244d

[11] Kusari.dev — "Vibe Coding Is Shipping Vulnerabilities: A Security Team's Guide" — https://www.kusari.dev/blog/vibe-coding-is-shipping-vulnerabilities-a-security-teams-guide-to-ai-generated-code-risks

[12] ACM — "Security Weaknesses of Copilot-Generated Code in GitHub Projects: An Empirical Study" — https://dl.acm.org/doi/10.1145/3716848

[13] arXiv — "'You still have to study' — On the Security of LLM Generated Code" — https://arxiv.org/pdf/2408.07106

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

[15] CSA Labs — "Vibe Coding Security Crisis: Credential Sprawl and SDLC Debt" — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-security-vibe-coding-202/

[16] arXiv / IEEE-ISTAS 2025 — "Security Degradation in Iterative AI Code Generation" — https://arxiv.org/html/2506.11022v2

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

[18] CISA / NSA — "Joint Guidance on Deploying AI Systems Securely" (апрель 2024) — https://www.cisa.gov/news-events/alerts/2024/04/15/joint-guidance-deploying-ai-systems-securely

[19] NSA / CISA / FBI — "Joint Guidance on AI Data Security" (май 2025) — https://www.alston.com/en/insights/publications/2025/06/joint-guidance-ai-data-security

[20] Kaspersky Blog — "Security Risks of Vibe Coding and LLM Assistants for Developers" — https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584/