Как продуктовой студии доказать клиенту, что AI-generated код проверен перед релизом

Когда "работает" не означает "безопасно": практический гид для команд, которые сдают проекты на AI-кодинге

Скорость без контроля — это новый технический долг

Продуктовые студии, которые уже перешли на AI-assisted разработку, выигрывают в скорости. Copilot, Cursor, Claude, Gemini Code Assist — сейчас это стандартная часть рабочего процесса. По данным опроса Checkmarx/Censuswide 2025 года, около 70% CISOs, AppSec-менеджеров и разработчиков оценивают долю AI-генерированного кода в своих командах выше 40% [4].

Но у этой скорости есть обратная сторона, которая всё чаще становится предметом разговора на стороне клиента: а как вы проверяете, что этот код безопасен?

Вопрос закономерный. Исследование Veracode 2025 года, охватившее более 100 LLM, показало: 45% AI-сгенерированного кода не прошло тесты безопасности, введя уязвимости из OWASP Top 10 [1]. Java-код оказался проблемнее всего — 72% отказов. Это не экзотика, это базовый паттерн поведения современных моделей.

Клиент, который это знает, спросит: "Что именно вы делаете, чтобы мой продукт не попал в эту статистику?" Эта статья — о том, как на этот вопрос ответить конкретно, с артефактами и процессом, а не декларациями.

Почему AI-код — отдельная категория риска

Разработчик, пишущий код вручную, понимает контекст, архитектуру, угрозы. AI-модель генерирует синтаксически корректный код, который часто выглядит нормально, проходит линтер и даже юнит-тесты — но содержит уязвимости, которые типичный code review не поймает.

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

Уязвимости класса OWASP, которые AI воспроизводит системно

Анализ 4 200+ задокументированных CWE-уязвимостей в AI-authored файлах на GitHub показал, что речь идёт о широком спектре из 77 категорий [5]. Наиболее критичные — SQL-инъекции (CWE-89), инъекции команд ОС (CWE-78), инъекции кода (CWE-94), hardcoded credentials (CWE-259/798). Четыре из них входят в MITRE Top 25 Most Dangerous Software Weaknesses 2024 [6].

Hardcoded credentials и утечка секретов

GitGuardian зафиксировал: репозитории с активным Copilot демонстрируют уровень утечки секретов 6,4% против 4,6% в обычных репозиториях — рост примерно на 40% [2]. AI-assisted коммиты в целом экспонируют секреты более чем вдвое чаще, чем коммиты без AI: 3,2% против 1,5% [7]. В 2025 году на публичный GitHub было залито 28,65 миллиона новых hardcoded secrets — рост 34% год к году [7].

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

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

Академическое исследование 2025 года (Virginia Tech, University of Texas at San Antonio, University of Oklahoma) проанализировало 576 000 Python и JavaScript примеров, сгенерированных 16 LLM [3]. Результат: в среднем каждый пятый рекомендованный пакет не существует ни в одном публичном реестре. При этом 43% галлюцинированных имён воспроизводятся при каждом повторном запросе того же промпта [3].

Атакующие уже используют это: регистрируют несуществующие имена в npm и PyPI как вредоносные пакеты. Разработчик запускает npm install, получает вредоносный код — и не подозревает об этом. Термин для этой атаки — slopsquatting, введён исследователем Seth Larson [8].

Архитектурные дефекты, которые не видит SAST

Apiiro, изучив Fortune 50-компании, обнаружила, что к июню 2025 года AI-генерированный код добавлял более 10 000 новых security-находок в месяц — 10-кратный рост за полгода [9]. При этом паттерн изменился: тривиальные синтаксические ошибки сократились на 76%, но пути privilege escalation выросли на 322%, архитектурные дефекты — на 153% [9]. Это значит, что классические SAST-инструменты, заточенные на синтаксические паттерны, стали видеть всё меньше реальных проблем.

IaC-мисконфигурации в масштабе

AI-модели активно используются для генерации Terraform, CloudFormation и других IaC-файлов. Gartner прогнозировал, что 99% облачных взломов до 2025 года будут результатом предотвратимых мисконфигураций [10]. Один неверный шаблон IaC, прошедший в CI/CD без проверки, может создать сотни или тысячи уязвимых ресурсов — в каждом регионе, в каждом энваэйронменте [10].

Что не работает как защита

Прежде чем говорить о том, что работает, важно разобрать типичные заблуждения.

"Мы делаем code review"

Исследование показало, что разработчики чувствуют меньшую ответственность за AI-сгенерированный код и тратят на его проверку меньше времени, чем на собственный [4]. Дифф читают не до конца. Служебный код, конфиги, миграции и CI/CD-файлы — читают хуже всего. Это не вопрос квалификации, это когнитивная нагрузка и иллюзия доверия к модели.

"Мы используем AI-инструмент, который сам проверяет безопасность"

Veracode протестировали 100+ LLM на написание безопасного кода. Показатель защищённости застыл около 55% — и практически не менялся с 2024 года, несмотря на выход новых версий моделей [1]. Copilot, Claude, GPT-4 — все они генерируют небезопасный код с предсказуемой частотой. Это не баг конкретного инструмента, это системное свойство класса технологий.

"Мы запускаем тесты"

Функциональные тесты не проверяют CORS-политику, не ловят hardcoded token, не видят транзитивную зависимость с CVE. Тест проверяет, работает ли функциональность — не то, безопасна ли она.

Что работает: слои контроля от PR до релиза

Продуктовая студия, которая хочет убедительно отвечать на вопрос о безопасности AI-кода, должна выстроить многоуровневый процесс и сохранять его артефакты. Ключевой принцип из практики DevSecOps: быстрые, дешёвые проверки — на PR; более тяжёлые — на merge и ночью [11].

Уровень 1. SAST на каждый pull request

SAST (Static Application Security Testing) анализирует исходный код без выполнения и ловит типовые уязвимости — SQL-инъекции, XSS, небезопасную работу с памятью, hardcoded секреты в коде. Современные SAST-инструменты (Semgrep, Checkmarx, GitHub Advanced Security) запускаются прямо в PR и оставляют inline-комментарии с находками [12].

Важный нюанс для AI-кода: классический SAST ловит синтаксические проблемы, но слабо справляется с архитектурными дефектами. Именно поэтому его недостаточно как единственного инструмента.

Что фиксировать для клиента: лог SAST-прохода по каждому PR, количество и критичность находок, подтверждение, что блокирующие находки устранены до merge.

Уровень 2. SCA для зависимостей и lock-файлов

SCA (Software Composition Analysis) проверяет, какие сторонние библиотеки и пакеты входят в проект, сравнивает их версии с базами CVE и отслеживает транзитивные зависимости. Это критически важно при AI-кодинге, потому что AI нередко предлагает обновить или добавить зависимости без проверки их актуальности.

SCA решает задачу slopsquatting: валидирует существование пакета в реестре до установки. По данным IBM, более 90% современных приложений содержат open-source зависимости, 74% из них — высокорисковые [13].

Что фиксировать для клиента: SCA-отчёт с перечнем зависимостей, версиями, выявленными CVE, статусом их устранения или принятия риска.

Уровень 3. Проверка секретов и IaC

Отдельный слой — поиск секретов (secret scanning) в коде, конфигах, CI/CD-файлах, env-файлах. GitHub Push Protection, GitGuardian, Trufflehog — инструменты, которые ловят API-ключи, токены, пароли и предотвращают их попадание в историю коммитов.

Параллельно — IaC-сканирование. Если AI генерировал Terraform или CloudFormation: проверка на избыточные права IAM, открытые порты, незашифрованные хранилища, публичный доступ к ресурсам [10]. Один неверный шаблон IaC в CI/CD без проверки создаёт уязвимость в масштабе всей инфраструктуры [61].

Что фиксировать для клиента: подтверждение прохода secret-сканирования без находок (или с задокументированным устранением); IaC-отчёт, если проект включал infrastructure code.

Уровень 4. Security gate перед merge

Security gate — автоматический блок на merge/release, если критические проверки не пройдены. Это не опциональный совет, это обязательный механизм. Подход GitPlumbers [11]: блокировать по severity с истекающими waivers, но не постоянными allowlist-исключениями; оставлять break-glass только с аудит-треилом.

Принципиально важно разделять уровни:

1. Критические (CVSS 9.0+) — жёсткий блок, merge невозможен.
2. Высокие (CVSS 7.0–8.9) — блок с возможностью ручного approval с обязательным комментарием.
3. Средние и низкие — видимость в отчёте, SLA на устранение, не блокируют.

Что фиксировать для клиента: логи security gate по каждому релизу с подтверждением прохода или задокументированными решениями по исключениям.

Уровень 5. SBOM как артефакт прозрачности

SBOM (Software Bill of Materials) — машиночитаемый инвентарь всех компонентов продукта: библиотеки, пакеты, их версии, лицензии, зависимости. CISA в 2025 году обновила минимальные требования к SBOM, обозначив его как ключевой инструмент прозрачности поставок ПО [14].

По определению NIST, SBOM — это "формальная запись, содержащая детали и цепочку поставок различных компонентов, используемых при создании программного обеспечения" [15]. Стандартные форматы — SPDX и CycloneDX.

Для продуктовой студии SBOM даёт несколько преимуществ в диалоге с клиентом. Клиент получает доказательство того, что команда знает, из чего состоит продукт. При появлении новой CVE (по образцу Log4j или XZ Utils) можно мгновенно ответить, затронута ли система. SBOM — это аудиторский след, который значительно упрощает compliance-проверки.

Что фиксировать для клиента: SBOM-файл в формате SPDX или CycloneDX, прикреплённый к каждому релизу; подтверждение его генерации в CI/CD на момент сборки.

Как это выглядит в реальном процессе

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

При открытии PR:

• Запуск SAST (Semgrep / GitHub Advanced Security / Checkmarx)
• Secret scanning (Trufflehog / GitGuardian Push Protection)
• Проверка зависимостей в diff (SCA-анализ изменённых lock-файлов)
• Inline-комментарии к коду с находками

При merge в main/production:

• Полный SCA-прогон по всему дереву зависимостей
• IaC-сканирование при наличии инфраструктурных изменений
• Security gate с блоком на критические/высокие CVE
• Генерация обновлённого SBOM

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

• Финальный security gate с подтверждением прохода
• Приложение отчёта: SAST, SCA, secret scan, IaC (при наличии)
• SBOM текущей версии

В сопроводительную документацию к релизу — Security Note: Краткое резюме: что проверялось, какие инструменты использовались, какие находки выявлены, как они устранены или приняты с обоснованием.

Этот документ не нужно делать сложным. Клиенту важно видеть не объём — а структуру и повторяемость.

Отдельный слой: контроль AI-изменений до merge

SAST, SCA и secret scanning — это проверенные инструменты, которые существовали до AI-кодинга. Но у них есть слепое пятно: они не анализируют контекст конкретного изменения в связке с тем, что генерировал AI в данном PR.

Именно здесь появляется дополнительный слой контроля — анализ конкретного diff'а с пониманием, что в нём изменилось: конфиги, миграции, зависимости, serve-файлы. Такой инструмент смотрит не на весь репозиторий, а на то, что именно приехало в этом PR — и объясняет понятным языком, есть ли риск, который стоит остановить до merge.

HighVibe работает именно как этот слой контроля: анализирует изменение и связанный контекст, помогает заметить риск до merge, предлагает следующий шаг или безопасный вариант правки и останавливает только действительно критичные изменения. Для продуктовой студии это возможность объяснить клиенту: каждый PR с AI-кодом прошёл дополнительную проверку перед тем, как ушёл в main.

Как выстроить коммуникацию с клиентом

Техническая база важна, но важен и формат подачи. Клиент — не AppSec-специалист. Ему не нужен 40-страничный отчёт со списком CVE. Ему нужно понять: моя система в безопасности?

Несколько принципов, которые работают в практике студий.

Принцип 1. Отделяйте "работает" от "безопасно"

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

Принцип 2. Показывайте артефакты, а не обещания

"Мы проверяем код перед релизом" — это декларация. "Вот SAST-лог, вот SCA-отчёт, вот SBOM версии 1.4.2" — это доказательство. Клиент должен видеть конкретный артефакт каждой проверки. Неважно, в каком формате — главное, что он существует и передаётся.

Принцип 3. Структурируйте Security Note к релизу

Краткий документ, 1–2 страницы, который сопровождает каждый релиз:

1. Что проверялось (инструменты, слои)
2. Что найдено (критические/высокие находки с кратким описанием)
3. Что сделано (устранено, принято с обоснованием, отложено с SLA)
4. Статус: релиз прошёл security gate или требует специального решения

Этот формат выполняет двойную функцию: он честен (признаёт, что находки бывают) и структурирован (показывает, что с ними происходит).

Принцип 4. Фиксируйте процесс, а не только результат

Клиент, который видит лог security gate — с датой, временем, статусами проверок — понимает, что процесс повторяемый. Это принципиально отличается от разового аудита. Повторяемый процесс — это доверие.

Принцип 5. Не обещайте нулевых уязвимостей

Veracode, Checkmarx, любой серьёзный AppSec-источник говорит одно: нулевой уязвимости не существует. Это не отговорка — это факт индустрии. Правильное обещание выглядит иначе: "Мы проверяем каждый релиз по установленному процессу. Критические блокируются. Высокие — устраняются в согласованные сроки. Мы передаём вам SBOM и отчёт."

Чек-лист: минимальный security-процесс для AI-assisted студии

До merge:

• SAST запущен на каждый PR автоматически
• Secret scanning включён в pre-commit или CI
• SCA проверяет изменённые зависимости в PR
• Критические находки блокируют merge автоматически

На merge в main:

• Полный SCA-прогон (включая транзитивные зависимости)
• IaC-сканирование при инфраструктурных изменениях
• Обновление SBOM

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

• Security gate — финальный прогон с подтверждением
• Security Note сформирована и передана клиенту
• SBOM текущей версии прилагается к релизу

Что хранится как артефакт:

• Логи SAST по каждому PR
• SCA-отчёт на момент релиза
• Secret scan — подтверждение чистоты
• IaC-отчёт (если применимо)
• SBOM в формате SPDX или CycloneDX
• Security Note с финальным статусом

Распространённые ошибки и как их избежать

Ошибка 1. Сканировать только при ревью, не при merge

Между открытием PR и merge могут пройти часы, в которые зависимости обновляются, появляются новые CVE. Финальная проверка должна быть именно в момент merge, а не только при создании PR.

Ошибка 2. Игнорировать транзитивные зависимости

По данным Endor Labs, 95% уязвимостей находятся в транзитивных зависимостях — тех, которые подключаются через прямые зависимости, но явно не указаны в package.json или requirements.txt [12]. SCA обязан проверять их тоже.

Ошибка 3. Полагаться только на SAST для AI-кода

SAST — необходимый инструмент, но недостаточный. Архитектурные дефекты, privilege escalation, проблемы с CORS-политикой или излишними правами IAM — это классы уязвимостей, которые SAST не видит. Нужен дополнительный слой анализа контекста изменения.

Ошибка 4. Не разделять severity при security gate

Блокировать все находки без исключения — это путь к тому, что gate отключают. Чёткая градация: критические блокируют всегда; высокие — с возможностью ручного решения и audit-треилом; средние и низкие — в видимость, не в блок.

Ошибка 5. Не передавать артефакты клиенту

Проверка, о которой клиент не знает, не создаёт доверие. Передача Security Note и SBOM — это не бюрократия, это часть продукта.

Ошибка 6. Хранить секреты в env-файлах, которые попадают в репозиторий

По данным GitGuardian, 35% просканированных приватных репозиториев содержат хотя бы один plaintext secret [7]. Приватность репозитория не защищает: один компрометированный аккаунт или неверно выставленные права — и секрет открыт.

Регуляторный контекст: SBOM становится требованием

В 2021 году американский Executive Order 14028 впервые потребовал от поставщиков ПО для государственных нужд предоставлять SBOM [15]. В январе 2025 года вышел EO 14144, добавивший конкретику по стандартам [14]. CISA в августе 2025 года опубликовала обновлённый драфт минимальных требований к SBOM, включая специальный раздел для SaaS и AI-контекста [14].

В Европе CRA (Cyber Resilience Act), вступающий в силу поэтапно с 2027 года, вводит требования к software composition transparency для широкого класса продуктов. Для продуктовой студии, работающей с клиентами в регулируемых отраслях — финтех, медтех, e-commerce с PCI DSS — эти требования становятся частью договорных обязательств раньше, чем закон вступит в силу.

Иными словами, SBOM и security attestation — это уже не "хорошая практика для зрелых команд". Это рыночное ожидание, которое будет только усиливаться.

Будущее: прозрачность как конкурентное преимущество

AI-assisted разработка продолжит ускоряться. Доля AI-генерированного кода в production будет расти. Это означает, что вопрос "как вы проверяете свой AI-код?" станет стандартным в любом RFP и в любом разговоре с enterprise-клиентом.

Студии, которые сейчас выстраивают воспроизводимый процесс и учатся объяснять его клиенту артефактами, получат устойчивое преимущество перед теми, кто ответит "мы проверяем". IBM предупреждает: 97% организаций в 2025 году столкнулись с AI-related security incident [9]. Это число будет только расти вместе с объёмом AI-кода.

Вопрос не в том, использовать AI или нет. Вопрос в том, есть ли у студии контроль над тем, что AI создаёт.

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

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

1. Включите SAST и secret scanning в CI/CD на уровне PR — это минимальный базис, который можно внедрить за несколько часов.
2. Подключите SCA к pipeline — Snyk, Dependabot, Black Duck или другой инструмент по выбору команды; убедитесь, что транзитивные зависимости тоже проверяются.
3. Настройте security gate на merge с блоком на критические находки — и зафиксируйте это в README или внутреннем регламенте.
4. Добавьте генерацию SBOM в build-pipeline — CycloneDX и SPDX поддерживаются большинством современных CI/CD.
5. Добавьте слой контроля AI-изменений до merge — это может быть HighVibe или аналогичный инструмент, который анализирует конкретный diff в контексте, а не просто репозиторий целиком.
6. Введите Security Note как стандартный артефакт релиза — передавайте его клиенту вместе с SBOM при каждой поставке.

Доверие строится не из обещаний, а из повторяемости. Каждый релиз с подтверждёнными артефактами — это кирпич в фундамент долгосрочных отношений с клиентом.

Источники

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

[2] GitGuardian / CSO Online — "AI programming copilots are worsening code security and leaking more secrets" — https://www.csoonline.com/article/3953927/ai-programming-copilots-are-worsening-code-security-and-leaking-more-secrets.html

[3] Infosecurity Magazine — "AI Hallucinations Create 'Slopsquatting' Supply Chain Threat" — https://www.infosecurity-magazine.com/news/ai-hallucinations-slopsquatting/

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

[5] OX Security — "SAST vs SCA in the Age of AI-Generated Code" — https://www.ox.security/blog/sast-vs-sca-2026/

[6] ResearchGate / Academia — "Security Vulnerabilities in AI-Generated Code: A Large-Scale Analysis of Public GitHub Repositories" — https://www.researchgate.net/publication/397089244_Security_Vulnerabilities_in_AI-Generated_Code_A_Large-Scale_Analysis_of_Public_GitHub_Repositories

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

[8] FOSSA Blog — "Slopsquatting: AI Hallucinations and the New Software Supply Chain Risk" — https://fossa.com/blog/slopsquatting-ai-hallucinations-new-software-supply-chain-risk/

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

[10] Wiz — "What is Infrastructure as Code Security?" — https://www.wiz.io/academy/application-security/iac-security

[11] GitPlumbers — "Your CI/CD Security Wiring Diagram: SAST, SCA, IaC, SBOM, and Signatures Without Killing Throughput" — https://gitplumbers.com/blog/your-cicd-security-wiring-diagram-sast-sca-iac-sbom-and-signatures-without-killi/

[12] Endor Labs — "Introducing AI Security Code Review" — https://www.endorlabs.com/learn/introducing-ai-security-code-review

[13] IBM — "What Is a Software Bill of Materials (SBOM)?" — https://www.ibm.com/think/topics/sbom

[14] CMS / CISA — "New cybersecurity guidance from CISA for Software Bill Of Materials (SBOM)" — https://security.cms.gov/posts/new-cybersecurity-guidance-cisa-software-bill-materials-sbom

[15] NIST — "Software Security in Supply Chains: Software Bill of Materials (SBOM)" — https://www.nist.gov/itl/executive-order-14028-improving-nations-cybersecurity/software-security-supply-chains-software-1

[16] Mend.io — "Best SAST Tools in 2025: Top 10 Solutions Reviewed" — https://www.mend.io/blog/best-sast-tools-top-10-solutions/

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

[18] CSO Online — "For application security: SCA, SAST, DAST and MAST. What next?" — https://www.csoonline.com/article/4115679/for-application-security-sca-sast-dast-and-mast-what-next.html

[19] Checkmarx — "AI DevOps: How AI Is Changing DevOps & The AI DevSecops Revolution" — https://checkmarx.com/learn/ai-security/ai-devops-how-ai-is-changing-devops-the-ai-devsecops-revolution/

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