Как контролировать код, если разработчики используют ИИ-помощников

Производительность выросла. Количество уязвимостей — тоже. Что делать с этим разрывом

Производительность выросла, а доверие к коду упало

Переломный момент случился незаметно. Сначала разработчики начали использовать GitHub Copilot для автодополнения. Потом — Cursor и Windsurf для генерации целых функций. Затем появился Claude Code, OpenAI Codex и агентный режим, где ИИ сам открывает PR. По данным опроса DX за февраль 2026 года, 92,6% разработчиков используют ИИ-помощника минимум раз в месяц, 75% — еженедельно [6]. Термин «vibe coding», введённый Андреем Карпатовым в феврале 2025 года, описывает этот сдвиг точно: разработчик описывает намерение, ИИ генерирует реализацию, разработчик принимает её, убедившись, что всё запускается.

Проблема не в том, что ИИ пишет плохой код. Проблема в том, что он пишет код, который выглядит хорошим, работает в тестах — и при этом содержит уязвимости, которые не видны при поверхностном review. Согласно Stack Overflow Developer Survey 2025, 66% разработчиков признают, что тратят больше времени на исправление «почти правильного» ИИ-кода [7]. При этом доверие к точности AI-кода за год упало с 40% до 29% у тех же респондентов.

Это статья для CTO, VP Engineering, Tech Lead и AppSec-инженеров, которым нужно разобраться: какие конкретно риски несёт AI-кодинг, почему привычные инструменты с ними не справляются и как выстроить контроль, не убив скорость разработки.

Откуда берутся уязвимости в ИИ-коде

Прежде чем строить контроль, важно понять природу проблемы. Уязвимости в ИИ-коде отличаются от уязвимостей, которые вносит человек.

Модели воспроизводят паттерны из обучающих данных

ИИ обучен на огромных объёмах публичного кода — в том числе на коде с уязвимостями. Модели не понимают, почему те или иные паттерны опасны: они распознают статистически частые решения и воспроизводят их. Именно поэтому ранние тесты GitHub Copilot фиксировали генерацию аутентификационного кода с хардкодными API-ключами и credentials — так было написано в обучающих данных [8].

Код оптимизирован под happy path

Исследование AppSecEngineer, опубликованное в марте 2026 года, констатирует принципиальную проблему: традиционные стандарты вроде OWASP Top 10 разработаны под человеческий код, который несёт в себе намерение и архитектурный контекст. ИИ генерирует вывод без трассировки: нет объяснения, почему выбрана та или иная библиотека, нет понимания бизнес-логики за пределами текущего промпта [5]. В результате код обрабатывает нормальный сценарий корректно, но проваливается под adversarial conditions.

Исследование Georgetown CSET, на которое ссылается MatrixTribe, показало: 68–73% ИИ-сгенерированного кода содержат уязвимости, проходящие unit-тесты, но не выдерживающие security-ревью [9]. Веб-уязвимости типа XSS (CWE-80) не блокировались ИИ-инструментами в 86% случаев согласно Veracode GenAI Code Security Report 2025 [2].

PR становятся больше и непрозрачнее

Apiiro зафиксировала ещё один эффект: ИИ-помощники упаковывают больше изменений в меньшее число pull requests, затрагивая больше частей кодовой базы [1]. Это делает review сложнее: стандартный диф в GitHub не предупредит, если небольшое изменение в auth-service сломает проверку JWT в gateway-service.

Три главных класса рисков

1. Секреты и credentials в коде

Данные GitGuardian за 2026 год: 28,65 миллиона новых хардкодных секретов добавлено в публичные репозитории GitHub в 2025 году — рост 34% год к году [4]. AI-assisted коммиты утекают секреты с частотой 3,2%, что вдвое выше базового показателя для человеческих коммитов [4]. Репозитории, использующие GitHub Copilot, на 40% чаще содержат утечки секретов [8].

Причина конструктивная: ИИ-модели обучены на коде, где credentials хардкодированы в примерах. Когда разработчик просит сгенерировать интеграцию с Stripe или AWS, модель воспроизводит знакомый паттерн. Ещё хуже — аналитики Truffle Security в январе 2025 года обнаружили почти 12 000 живых секретов (AWS, Mailchimp, Slack, GitHub) в 400 ТБ публичных данных Common Crawl, использовавшихся для обучения [10]. Это означает, что уязвимые паттерны могут быть буквально встроены в веса модели.

2. Галлюцинированные зависимости и slopsquatting

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

Атака slopsquatting использует это напрямую: злоумышленник регистрирует пакет с галлюцинированным именем в npm или PyPI и ждёт, когда разработчики установят его. Исследователь Charlie Eriksen в январе 2025 года зарегистрировал npm-пакет react-codeshift, который LLM многократно галлюцинировал. Пакет разошёлся в 237 репозиторий на GitHub и начал генерировать реальные загрузки — до того, как исследователь успел сделать его вредоносным [11]. Это был proof of concept. Следующий раз может быть не исследователь.

3. Структурные уязвимости и отсутствие security controls

Apiiro проанализировала кодовые базы крупных корпораций и выявила: AI-код даёт +322% путей эскалации привилегий, +153% архитектурных дефектов и +40% к частоте появления секретов в коде по сравнению с человеческим кодом [1]. CVSS 7.0+ уязвимости появляются в AI-коде в 2,5 раза чаще [12].

Характерный паттерн — endpoint, который функционально работает, но не имеет rate limiting, отсутствует проверка авторизации на уровне объекта (BOLA/IDOR), CORS настроен слишком широко, или входные данные не валидируются. ИИ генерирует логику обработки данных, игнорируя adversarial условия — потому что в промпте об этом не было.

Почему традиционные инструменты не справляются

Классические SAST-инструменты искали уязвимости в коде, написанном людьми. Они ищут паттерны — SQL-инъекции, неправильное использование криптографии, явное присвоение строки в поле пароля. Проблема: AI-код не несёт в себе трассировки намерений. Код синтаксически чист, семантически связен — и при этом структурно уязвим.

AppSecEngineer формулирует это прямо: стандартные OWASP-ориентированные чек-листы проверяют то, как думают разработчики-люди, а не то, как генерируют модели [5]. Ревьюер привычно ищет несоответствие паттернам человеческих ошибок — и пропускает системные слабости AI-кода.

Дополнительная проблема — скорость. Apiiro зафиксировала, что ИИ упаковывает больше кода в меньшее число PR. DORA Report 2025 зафиксировал рост времени review на 91% по мере увеличения доли AI-сгенерированных PR [13]. Ревьюеры не успевают читать такие дифы до конца — и перестают.

Архитектура контроля: что реально работает

Ни один инструмент не решает проблему целиком. Контроль строится слоями, каждый из которых закрывает свой класс рисков.

Слой 1. Политика и governance до написания кода

OpenSSF опубликовал руководство «Security-Focused Guide for AI Code Assistant Instructions» в августе 2025 года с рекомендацией создавать кастомные инструкции для ИИ-ассистентов в формате .cursorrules, .github/copilot-instructions.md и аналогичных файлов [14]. Цель — встроить security conscience прямо в инструмент: не предлагать deprecated алгоритмы, следовать OWASP Top 10, не отключать security features.

Palo Alto Networks Unit 42 в январе 2026 года предложил фреймворк SHIELD для governance AI-кодинга, включающий:

• разделение обязанностей: ИИ-агенты не имеют доступа к production-среде;
• human-in-the-loop: pull request approval обязателен для любого merge;
• валидацию промптов и output code через SAST до принятия;
• запрет самописных реализаций аутентификации и криптографии в пользу библиотек с аудитом [15].

Infosecurity Magazine дополняет этот список практикой «Prompt BoM» (Prompt Bill of Materials): каждый AI-генерированный артефакт трекает модель, промпт и параметры для аудитируемости [6].

Слой 2. Pre-commit и pre-push gates

Первый рубеж — до того как код попадает в репозиторий. Минимальный набор для команды, использующей ИИ:

• детекция секретов в pre-commit хуке (TruffleHog, detect-secrets, Gitleaks);
• проверка зависимостей на существование до установки (lock-файлы, проверка через npm audit, pip-audit или OSV Scanner);
• статический анализ с правилами, адаптированными под AI-паттерны.

По данным SQ Magazine, 70% организаций не имеют автоматического сканирования секретов для AI-сгенерированного кода — при том что AI-репозитории показывают коэффициент утечки секретов 6,4% [12]. Pre-commit gate с детекцией секретов — наименьшая стоимость при наибольшем покрытии этого класса рисков.

Слой 3. PR-level анализ

На уровне pull request автоматизация должна делать то, что ревьюер физически не успевает при большом дифе:

• SAST сканирование с результатами прямо в комментариях PR;
• SCA (Software Composition Analysis): проверка зависимостей на known vulnerabilities (OSV, NVD, GitHub Advisories), license compliance, существование пакета в реестре;
• детекция секретов в дифе;
• для IaC-файлов (Terraform, GitHub Actions, Kubernetes manifests) — специализированные правила.

Важный нюанс: ИИ упаковывает больше изменений в PR, а значит стандартный diff view GitHub не даст полной картины межсервисных взаимодействий. Зрелые команды добавляют анализ контекста изменения — как конкретный диф влияет на смежные компоненты.

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

Слой 4. CI/CD quality gate

Автоматизация, которую нельзя обойти вручную:

• запрет merge при наличии критических findings из SAST/SCA/secret scanning;
• обязательный апрув от security reviewer для файлов в высокорисковых зонах (auth, crypto, CI/CD pipeline definitions, database migrations);
• генерация SBOM (Software Bill of Materials) на каждый merge в main;
• проверка lock-файлов на соответствие package.json / requirements.txt.

CISA совместно с G7 в мае 2026 года опубликовала руководство «Software Bill of Materials for AI — Minimum Elements» [16] — первый международный консенсус о том, что должен содержать SBOM для систем, использующих AI. Это сигнал: регуляторное давление в сторону прозрачности зависимостей будет расти.

OpenSSF SLSA (Supply-chain Levels for Software Artifacts) предоставляет уровневую модель зрелости supply chain security, от базовой фиксации провенанса (уровень 1) до криптографически верифицированных сборок (уровень 3+) [17].

Слой 5. Release gate

Перед релизом нужен ответ на один вопрос: есть ли в этом изменении что-то, что блокирует выпуск прямо сейчас? Не список из 200 findings, сгруппированных по CWE, — а конкретный ответ.

Команды, которые внедрили этот подход, останавливают не всё подряд. Они останавливают только действительно критичное: exposed secret с активными правами, уязвимость в новой зависимости с доступным эксплойтом, критический CORS-мисконфигурейшн в продакшн-эндпоинте. Остальное — предупреждение с понятным следующим шагом.

Специфика AI-кода, которую нельзя игнорировать

Конфиги, CI/CD и служебный код читают хуже всего

Когда разработчик генерирует GitHub Actions workflow или Terraform-конфигурацию с помощью ИИ, ревьюеры склонны смотреть на неё беглее, чем на product code. Между тем именно CI/CD-файлы открывают доступ к секретам, production-среде и правам на merge. Исследование Aikido зафиксировало, что GitHub Actions misconfiguration были в числе главных причин supply chain атак в 2025 и 2026 году [11].

Database migrations и internal tools

ИИ охотно пишет миграции — и так же охотно добавляет в них overly permissive изменения схемы или обходит row-level security. Internal tools, написанные non-developers с помощью vibe coding, показывают особенно высокую частоту hardcoded credentials: RedHuntLabs выявила exposed secret минимум на одном из пяти vibe-coded сайтов [21].

Транзитивные зависимости

SCA сканирует прямые зависимости. ИИ-код часто приносит цепочки транзитивных зависимостей, среди которых могут быть пакеты с известными уязвимостями. 86% организаций используют open-source компоненты с известными уязвимостями в AI-воркфлоу [12]. Lock-файлы и автоматический advisory monitoring (через Dependabot, Renovate или аналоги) — не опциональная практика, а обязательная.

Практический чек-лист: что проверять на каждом этапе

До merge (в PR)

1. Нет ли в диффе секретов, токенов, паролей, connection strings? (автоматически)
2. Все ли новые зависимости существуют в реестре и не имеют known CVSS 7.0+ уязвимостей?
3. Если изменён CI/CD-файл или IaC — прошёл ли он специализированный scan?
4. Если добавлен auth/crypto код — написан ли он с использованием approved библиотек, а не самописно?
5. Есть ли в конфигурациях overly permissive CORS, отключённая аутентификация или debug-флаги?
6. Если это database migration — не снимает ли она row-level security или не расширяет ли права?

При ревью (человек)

1. Логика обработки edge cases и adversarial input — есть ли она вообще?
2. Авторизация проверяется на уровне объекта (BOLA/IDOR), а не только на уровне эндпоинта?
3. Rate limiting присутствует там, где он нужен (auth, payment, email sending)?
4. Ошибки не раскрывают внутренние детали системы (stack traces, DB queries) в HTTP-ответах?

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

1. Нет ли критических findings из SAST/SCA, открытых более N дней без принятого решения?
2. SBOM актуален и включает все зависимости этого релиза?
3. Новые или изменённые зависимости — проверены на advisory за последние 24 часа?
4. CI/CD pipeline для этого релиза не изменялся без security review?

Типичные ошибки при внедрении контроля

Запустить сканирование и утонуть в шуме

Классический SAST без настройки правил выдаёт сотни ложных срабатываний. Разработчики привыкают игнорировать findings. Эффективный подход — начать с минимального набора правил высокой точности (low false positive rate), обеспечить контекстуальные объяснения к каждому finding и постепенно расширять покрытие [19].

Добавить gate, но сделать его обходимым

Если разработчик может нажать «merge anyway» без апрува security reviewer, gate превращается в формальность. Infosecurity Magazine прямо формулирует: 97% AI-related breaches происходят в организациях, где нет должного контроля доступа [6]. Контроль эффективен только если он технически обязателен, а не рекомендателен.

Думать, что SAST решает всё

SAST не ловит проблемы в зависимостях (нужен SCA), не видит секреты в environment variables или конфигах за пределами кода (нужен secrets scanner), не анализирует runtime поведение (нужен DAST/RASP). HighVibe позиционирует себя как дополнительный слой контроля рядом с существующими инструментами, а не их замену. Это правильная рамка для любого нового инструмента в AppSec-стеке.

Игнорировать non-developer builders

JetBrains выявила в начале 2026 года, что более 35% enterprise-команд используют vibe coding для генерации больших блоков кода из natural language prompts [9]. Это не только senior инженеры — это product managers, аналитики и internal tool builders, которые никогда не проходили secure coding training. Governance должен распространяться и на них: pre-vetted security blocks, «paved roads» для типовых use cases (OAuth flow, secret management), short security checklist на language уровне.

Тренды и что будет дальше

Агентный режим: риски растут

Claude Code, OpenAI Codex и аналоги переходят в режим, где ИИ-агент самостоятельно открывает PR, редактирует файлы и запускает команды. При этом каждый агент требует credentials и OAuth-токенов. По данным GitGuardian, machine identities превышают human identities в 45:1 в большинстве enterprise-организаций, и AI ускоряет этот рост без соответствующей governance-зрелости [18]. Инцидент с Invariant Labs в мае 2025 года показал, как вредоносный GitHub Issue может перехватить AI-агент и эксфильтровать данные из приватных репозиториев через Personal Access Token [18].

PromptBOMs и провенанс

Идея Prompt Bill of Materials — трекать модель, промпт, параметры и дату генерации для каждого AI-артефакта — получает поддержку в enterprise. Это аналог SBOM, но для AI-процесса: аудитируемость того, как именно был сгенерирован код. Регуляторный импульс от CISA SBOM for AI (G7, май 2026) [16] усилит давление в эту сторону.

EU Cyber Resilience Act и SBOM как требование

Европейский CRA обязывает производителей ПО поставлять SBOM для продуктов на европейском рынке. Gartner прогнозировал, что к 2025 году 60% организаций, создающих критическую инфраструктуру, стандартизируют SBOM [20]. Для команд, работающих с европейскими клиентами или партнёрами, это уже не best practice, а compliance-требование.

OWASP Agentic AI Top 10

В 2026 году OWASP выпустил список из 10 критических рисков, специфичных для AI coding agents. Это формализация новой реальности: стандартный OWASP Top 10 не покрывает угрозы, связанные с автономными агентами, обладающими правами на запись в репозиторий [22].

Выводы: что делать прямо сейчас

ИИ-кодинг — это не эксперимент. По данным Checkmarx, около 70% опрошенных CISOs, AppSec-менеджеров и разработчиков оценивают долю AI-сгенерированного кода в своих организациях на уровне более 40% [1]. Игнорировать это означает накапливать security debt со скоростью, с которой традиционные remediation-процессы не справляются.

Три действия с высоким ROI, которые можно сделать немедленно:

• Развернуть pre-commit secret scanning на всех репозиториях, где работают ИИ-помощники. Это закрывает самый быстрорастущий класс рисков с минимальными затратами на внедрение.
• Настроить SCA с проверкой существования пакетов в реестре — защита от slopsquatting. Это не требует сложной интеграции: OSV Scanner, pip-audit и socket.dev решают задачу на уровне CI.
• Сформулировать и зафиксировать security instructions для каждого ИИ-инструмента в команде (.cursorrules, Copilot instructions, system prompt). OpenSSF опубликовал готовый шаблон в августе 2025 года [14].

Дальше — строить слои: PR-level SAST с низким false positive rate, обязательный апрув для файлов в высокорисковых зонах, SBOM на каждый релиз.

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

Источники

[1] 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/ — сентябрь 2025

[2] Veracode — "2025 GenAI Code Security Report" — https://www.veracode.com/blog/ai-generated-code-security-risks/ — сентябрь 2025

[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/ — апрель 2025

[4] Snyk — "State of Secrets 2026: Why 28 million credentials leaked on GitHub in 2025" — https://snyk.io/articles/state-of-secrets/ — март 2026

[5] AppSecEngineer — "AI-Generated Code Needs Its Own Secure Coding Guidelines" — https://www.appsecengineer.com/blog/ai-generated-code-needs-its-own-secure-coding-guidelines — март 2026

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

[7] Stack Overflow — "2025 Developer Survey" — https://stackoverflow.com/surveys/2025

[8] Blott — "Hidden Dangers: How Code Secrets Leak Through AI Models" — https://www.blott.com/blog/post/hidden-dangers-how-code-secrets-leak-through-ai-models — октябрь 2025

[9] MatrixTribe — "The Enterprise Risks of Vibe Coding: Security, Governance and Maintainability" — https://matrixtribe.ai/blog/the-enterprise-risks-of-vibe-coding-security-governance-and-maintainability/ — март 2026

[10] PointGuard AI — "AI Training Data Secret Leak 2025: 12,000 API Keys Exposed" — https://www.pointguardai.com/ai-security-incidents/12-000-api-keys-and-passwords-exposed-in-ai-training-data — январь 2026

[11] Aikido Security — "Slopsquatting: The AI Package Hallucination Attack Already Happening" — https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks — февраль 2026

[12] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/ — апрель 2026

[13] Git AutoReview — "AI-Powered Code Review for GitHub & GitLab" — https://gitautoreview.com/guides/ai-code-review — апрель 2026

[14] OpenSSF — "Security-Focused Guide for AI Code Assistant Instructions" — https://best.openssf.org/Security-Focused-Guide-for-AI-Code-Assistant-Instructions — август 2025

[15] Infosecurity Magazine — "Palo Alto Networks Introduces New Vibe Coding Security Framework" — https://www.infosecurity-magazine.com/news/palo-alto-networks-vibe-coding/ — февраль 2026

[16] CISA / G7 — "Software Bill of Materials for AI – Minimum Elements" — https://www.cisa.gov/resources-tools/resources/software-bill-materials-ai-minimum-elements — май 2026

[17] OpenSSF — "SBOM Everywhere SIG / SLSA" — https://github.com/ossf/sbom-everywhere

[18] Help Net Security — "29 million leaked secrets in 2025: Why AI agents credentials are out of control" — https://www.helpnetsecurity.com/2026/04/14/gitguardian-ai-agents-credentials-leak/ — апрель 2026

[19] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/ — ноябрь 2025

[20] Palo Alto Networks — "What Is a Software Bill of Materials (SBOM)?" — https://www.paloaltonetworks.com/cyberpedia/what-is-software-bill-materials-sbom

[21] DEV Community / 0x711 — "AI Agents Don't Understand Secrets. That's Your Problem." — https://dev.to/0x711/ai-agents-dont-understand-secrets-thats-your-problem-43n4 — март 2026

[22] OWASP — "Agentic AI Threats and Mitigations" — https://genai.owasp.org/ — 2026