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

«Работает» — не значит «готово к продакшену». Чек-лист для команд, которые строят на скорости

Скорость без контроля — открытая дверь для атакующих

С середины 2024 года произошёл качественный сдвиг в том, как строятся приложения. Cursor, Claude Code, Bolt, Lovable, Replit — инструменты, которые позволяют описать фичу словами и получить работающий прототип за часы. Это реально меняет скорость вывода продуктов на рынок.

Но «работает» и «готово к продакшену» — по-прежнему два разных утверждения.

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

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

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

Человек, допустивший баг, обычно неправильно понял требование или сделал опечатку. ИИ ошибается по-другому.

Исследователи из Veracode протестировали более 100 языковых моделей на 80 задачах в Java, Python, C# и JavaScript. Результат: 45% сгенерированных образцов кода не прошли security-тесты. По XSS провал составил 86%, по log injection — 88% [1]. Компания опубликовала обновление в марте 2026 года с заголовком «Despite Claims, AI Models Are Still Failing Security» — показатели не улучшились [1].

Параллельно Apiiro проанализировала проекты Fortune 50: AI-assisted разработчики генерируют коммиты в 3–4 раза быстрее, но вводят security-находки с темпом, который создаёт 322% больше путей эскалации привилегий и 153% больше дефектов проектирования по сравнению с baseline [2].

Специфика AI-кода — это не просто «больше багов». Это другие паттерны дефектов:

• Галлюцинированные API — вызовы методов, которых не существует.
• Логический дрейф — реализация правдоподобна, но не соответствует спецификации.
• Тавтологические тесты — AI проверяет собственные предположения, а не требования.
• Небезопасные дефолты — конфигурации, которые работают в dev, но опасны в prod.
• Уязвимости из обучающих данных — модель воспроизводит небезопасные паттерны из миллионов публичных репозиториев.

Традиционный code review не масштабируется на такой поток. Ни одна команда физически не может дочитывать до конца все PR, если AI генерирует десятки тысяч строк в день [3].

Шесть слоёв проверки перед запуском

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

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

GitGuardian зафиксировал 28,65 млн новых захардкоженных секретов в публичных GitHub-коммитах за 2025 год — рост 34% год к году, крупнейший за всю историю наблюдений. Учётные данные AI-сервисов (API-ключи LLM-провайдеров, embedding-сервисов) выросли на 81% за тот же период [4]. AI-assisted коммиты «сливают» секреты по ставке 3,2% против 1,5% у коммитов без ИИ — более чем вдвое выше базового уровня [4].

Wiz отсканировал 5 600 приложений, построенных на vibe-coding-инструментах, и обнаружил открытые секреты в 400 из них [5]. Отдельно исследователи нашли 24 008 уникальных секретов в MCP-конфигурационных файлах на публичном GitHub — 2 117 из них оставались действующими [4].

Почему это происходит: ИИ обучался на репозиториях, где ключи захардкожены в туториалах. Он воспроизводит этот паттерн — const STRIPE_KEY = 'sk_live_...' — совершенно нормально, если разработчик не задал явное ограничение [6].

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

• Все API-ключи, токены, пароли, JWT-секреты — только через environment variables, не в коде.
• Git-история: секрет, однажды попавший в коммит, остаётся там даже после удаления из HEAD.
• .env-файлы не должны попадать в репозиторий (проверить .gitignore).
• Автоматическое сканирование: GitHub Secret Scanning, Gitleaks, truffleHog — запускать на каждый коммит [7].
• MCP-конфиги и инфраструктурные файлы (Dockerfile, CI/CD YAML, terraform) — отдельный приоритет.

2. Зависимости и supply chain

Второй по критичности слой — то, что приехало незаметно.

Исследование, опубликованное на USENIX Security 2025, проанализировало 576 000 образцов кода от 16 популярных LLM: 19,7% зависимостей оказались «галлюцинированными» — они не существуют в реальных реестрах [8]. Open-source-модели галлюцинировали с частотой ~22%, коммерческие (GPT-4) — ~5% [8]. Это не академическая проблема: 43% галлюцинированных имён пакетов повторялись в 10 последовательных запросах — атакующий может предсказать их и зарегистрировать заранее [9].

Этот вектор атаки получил название slopsquatting — термин, введённый Сетом Ларсоном из Python Software Foundation в апреле 2025 года [9]. Атакующий регистрирует пакет под галлюцинированным именем в PyPI или npm, вкладывает туда вредоносный код — и следующий разработчик, принявший предложение ИИ без проверки, устанавливает его.

По данным Endor Labs' 2025 State of Dependency Management, только 1 из 5 зависимостей, предложенных AI-инструментами, отвечает стандартам безопасности. Остальные 80% несут риск: известные уязвимости, несуществующие пакеты или непрозрачное происхождение [10].

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

• Каждое новое имя пакета — вручную или через SCA верифицировать существование в официальном реестре.
• Запускать SCA (Snyk, Dependabot, OWASP Dependency-Check) на каждый PR: сканировать package.json, requirements.txt, go.mod, Cargo.toml.
• Проверять транзитивные зависимости — прямой пакет может быть чистым, его зависимость — нет.
• Генерировать SBOM (CycloneDX, SPDX, Syft) для каждой сборки: это база для аудита и реагирования на инциденты [7].
• Lock-файлы (package-lock.json, poetry.lock) коммитить в репозиторий и проверять их целостность.

3. Аутентификация и авторизация

Самый распространённый логический дефект AI-кода — разрыв между «пользователь залогинен» и «пользователь имеет право на этот ресурс».

По данным Georgia Tech Vibe Security Radar, обход аутентификации входит в тройку наиболее часто подтверждённых типов уязвимостей в AI-сгенерированном коде — наряду с command injection и SSRF [5].

Типичные паттерны дефектов:

• Эндпоинт проверяет факт аутентификации, но не владение ресурсом (BOLA / IDOR): GET /invoice/123 возвращает данные любому залогиненному пользователю.
• Проверка прав выполняется на клиенте, а не на сервере.
• Слабые алгоритмы хэширования паролей (MD5, SHA-256 вместо bcrypt/argon2).
• Отсутствие rate limiting на login-эндпоинте — открытый вектор для brute force.
• Мультитенантные запросы без WHERE tenant_id = ? — Customer A видит данные Customer B.

AI-generated auth code часто выглядит рабочим в изолированном тесте. Проблема проявляется при пересечении пользовательских контекстов — в prod, не в dev [11].

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

• Каждый эндпоинт API: проверяется ли и аутентификация, и авторизация на сервере.
• Ресурсо-ориентированные маршруты (invoice/:id, user/:id): может ли пользователь подменить id и получить чужие данные.
• Парольный хэшинг: bcrypt или argon2, не устаревшие алгоритмы.
• Управление сессиями: secure cookies, правильный scope.
• Блокировка аккаунта после N неудачных попыток.
• Row-level security в БД — особенно в Supabase/Postgres, где ИИ часто генерирует RLS-политики с пробелами.

4. Инъекции, XSS и валидация ввода

Veracode зафиксировал, что 86% AI-сгенерированного кода не защищены от XSS [1]. CodeRabbit подтвердил: AI-код в 2,74 раза чаще вводит XSS-уязвимости по сравнению с кодом, написанным человеком [2].

Корневая причина: ИИ строит SQL-запросы через конкатенацию строк, а не параметризованные запросы. Он читал миллионы примеров, где query = "SELECT * FROM users WHERE id = " + userId — это норма.

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

• SQL: только параметризованные запросы или ORM с protection-by-default.
• Весь пользовательский ввод — валидируется на сервере, не только на клиенте.
• Вывод данных: все динамические данные экранируются перед вставкой в HTML.
• Загрузка файлов: тип, размер, контент — валидируются независимо.
• SAST-сканирование (Semgrep, CodeQL, Checkmarx) должно быть настроено на каждый PR [12].

5. Небезопасные конфигурации и дефолты

ИИ генерирует конфиги, которые нормально работают на localhost, но опасны в продакшене. Это системная проблема, подтверждённая аудитами тысяч vibe-coded приложений.

Bolt автоматически выставляет * в CORS, чтобы preview работал локально [11]. v0 часто смешивает клиентскую и серверную логику так, что environment variables попадают в браузерный бандл — открытые ключи обнаруживают в каждом третьем сложном дашборде [11]. AI-код почти никогда не выставляет security headers самостоятельно: в 3 из 5 проектов они отсутствуют полностью [13].

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

• CORS: конкретные origin-адреса, не wildcard *.
• Security headers: HSTS, CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy.
• Debug mode и verbose error messages — выключены в prod; stack trace и SQL-запросы не передаются клиенту.
• Rate limiting на все публичные эндпоинты, особенно auth и поисковые.
• HTTPS — весь трафик, не только login-страница.
• Environment variables для prod не содержат значений, предназначенных для dev/staging.
• Открытые порты и сервисы на хост-машине — нет ничего лишнего в публичном доступе.

6. Бизнес-логика, данные и мультиарендность

Это слой, который ни один сканер не покрывает полностью. Его проверяет только человек.

AI-код часто:

• Генерирует cascade rules для удаления данных неправильно — или не генерирует вовсе: удаление пользователя оставляет orphaned-записи или, наоборот, удаляет связанные данные, которые должны были остаться.
• В мультитенантных приложениях фильтрует данные на клиенте, а не в запросе: все записи возвращаются, лишние скрываются в JS.
• Не определяет, что происходит с данными при граничных условиях (пустой корзина, нулевой баланс, отозванные права).

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

• Ручной аудит всех мест, где данные одного пользователя/тенанта могут пересечься с данными другого.
• Тестирование с несколькими аккаунтами: может ли User A увидеть или изменить что-либо принадлежащее User B?
• Бэкапы: не «бэкапы включены», а реальный restore в чистое окружение с верификацией данных [13].
• Логи не содержат секретов, токенов, PII.

Инструментальный минимум: SAST, SCA, DAST — разные зоны ответственности

Три класса инструментов часто путают или считают взаимозаменяемыми. Это не так [14]:

1. SAST (Static Application Security Testing) — анализирует исходный код без запуска приложения. Находит SQL-инъекции, XSS, небезопасный crypto, hardcoded secrets в коде. Не видит поведение на runtime. Инструменты: Semgrep, CodeQL, Checkmarx, SonarQube.

1. SCA (Software Composition Analysis) — не смотрит на логику вашего кода вообще. Сканирует зависимости: известные CVE в open-source-библиотеках, лицензионные риски, hallucinated packages. Инструменты: Snyk, Dependabot, OWASP Dependency-Check, Endor Labs.

1. DAST (Dynamic Application Security Testing) — тестирует работающее приложение снаружи, как атакующий. Находит уязвимости, которые проявляются только в runtime: проблемы конфигурации, реальная эксплуатируемость инъекций, открытые эндпоинты. Инструменты: Invicti, Burp Suite, OWASP ZAP.

В контексте vibe-coding DAST особенно важен: после каждого промпта приложение может кардинально измениться, а SAST это не заметит [3].

Практическое правило: SAST и SCA — в CI/CD на каждый PR. DAST — перед каждым деплоем в staging и перед финальным релизом.

Чек-лист: что проверить перед нажатием кнопки «запустить»

Ниже — минимальный набор проверок, сгруппированных по приоритету.

Блокирующие (нельзя запускать без этого):

1. Все секреты и ключи — в environment variables, не в коде или git-истории.
2. Автосканирование секретов пройдено без критических находок.
3. SCA-скан зависимостей: нет Critical/High CVE без mitigation-плана.
4. Каждый пакет проверен на реальное существование в реестре.
5. SAST-скан: нет SQL-инъекций и XSS без исправления.
6. Auth и authz проверены на сервере для каждого эндпоинта.
7. CORS не wildcard в prod.
8. Debug mode и verbose errors отключены.
9. HTTPS включён для всего трафика.
10. Ручной тест: один аккаунт не может получить ресурсы другого.

Высокоприоритетные (сделать до публичного запуска):

1. Security headers выставлены: HSTS, CSP, X-Frame-Options.
2. Rate limiting на login, регистрацию и публичные API.
3. DAST-скан на staging-окружении.
4. Бэкап проверен реальным restore.
5. Логи проверены на отсутствие секретов и PII.
6. SBOM сгенерирован.
7. Мультитенантность проверена с двумя независимыми аккаунтами.

Типичные ошибки команд

Ошибка 1: «Сканер не нашёл — значит чисто». SAST не видит runtime-поведение. DAST не видит код. Ни один из них не проверяет логику приложения. Три класса инструментов нужны вместе.

Ошибка 2: «Ревью PR мы делаем — пролистываем весь диф». Вся проблема в этом «пролистываем». AI генерирует изменения, которые выглядят нормально при беглом просмотре: параметризованный запрос в одном месте, конкатенация — в другом, на 847-й строке. Точечные security-проверки критических мест важнее полного пролистывания [15].

Ошибка 3: «Мы используем Supabase / managed DB — с RLS всё настроено само». ИИ регулярно генерирует политики RLS с дырами — особенно в admin- и reporting-эндпоинтах, где tenant-фильтр пропускается [13].

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

Ошибка 5: «У нас нет времени делать всё это — мы стартап». Security-инциденты у стартапов дороже, чем у крупных компаний: нет команды реагирования, нет запаса репутации, нет юридической защиты. Блокирующий чек-лист из 10 пунктов занимает несколько часов, но закрывает наиболее критичные векторы.

Отдельно про конфиги, миграции и CI/CD-файлы

Служебный код — конфигурационные файлы, миграции БД, Dockerfile, .github/workflows — читается хуже всего при ревью. При этом именно он содержит наибольшую концентрацию небезопасных дефолтов.

Типичные находки в аудитах AI-generated проектов [4] [6]:

• CI/CD YAML с захардкоженными токенами вместо GitHub Secrets / Vault.
• Dockerfile с RUN pip install без pin-версий и проверки хэшей.
• Миграции, удаляющие cascade данные без явного подтверждения в логике.
• MCP-конфиги с API-ключами прямо в файле (паттерн из официальной документации) [4].

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

Контроль на уровне процесса: что нужно выстроить, а не просто один раз сделать

Разовая проверка перед запуском — необходимое, но не достаточное условие. AI-код меняется быстро: один промпт может переписать авторизацию. Поэтому security-проверки должны быть встроены в workflow, а не выполняться вручную перед каждым релизом.

Минимальная процессная цепочка:

1. Pre-commit: сканирование секретов (Gitleaks, GitHub Secret Scanning).
2. PR gate: SAST + SCA — результаты видит ревьюер, критические блокируют merge.
3. Pre-deploy: DAST на staging-окружении.
4. Release gate: ручное подтверждение security-чек-листа ответственным.

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

Инструменты вроде HighVibe строятся именно на этой идее: анализировать конкретное изменение в PR (код, конфиги, зависимости, релизный контекст) и давать команде понятный ответ — можно ли безопасно принять это изменение сейчас, и если нет — почему. Не как замена SAST/SCA/DAST, а как дополнительный слой контроля до merge и релиза, когда решение принимается быстро и информации мало.

Тренды: куда смещается риск в 2026 году

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

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

MCP-конфиги как новая поверхность атаки. 24 008 секретов в MCP-файлах на публичном GitHub — категория, которой год назад не существовало [4]. Официальная документация с захардкоженными ключами в примерах формирует опасный паттерн у разработчиков.

Slopsquatting набирает масштаб. В мае 2026 года одна скомпрометированная npm-зависимость может в теории затронуть сотни тысяч установок до того, как advisory будет опубликован. Predictable hallucination patterns делают эту атаку дешевле тайпсквоттинга [9].

Регуляторное давление усиливается. EU AI Act начал действовать для general-purpose AI в 2025 году, более широкие обязательства по compliance — 2026–2027 [16]. Для команд в регулируемых отраслях (финансы, здравоохранение, госсектор) проверки безопасности перестают быть только best practice — они становятся юридическим требованием.

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

Ключевой вывод этой статьи прост: AI радикально ускорил создание кода, но не изменил природу уязвимостей. SQL-инъекция, XSS, hardcoded secrets, отсутствующая авторизация — это всё те же классы проблем, что и десять лет назад. Только теперь они появляются быстрее и в местах, которые при беглом ревью выглядят нормально.

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

1. Пройти блокирующий чек-лист из 10 пунктов до любого публичного запуска.
2. Встроить сканирование секретов, SAST и SCA в CI/CD — это занимает один день, а не неделю.
3. Запустить DAST на staging-окружении перед финальным релизом.
4. Выделить отдельный security-взгляд на конфиги, миграции и CI/CD-файлы — они читаются хуже всего.
5. Проверить мультитенантность с двумя независимыми аккаунтами перед тем, как открывать доступ enterprise-клиентам.

«Работает» — это хорошее начало. Но это только начало.

Источники

[1] Veracode — GenAI Code Security Report / Despite Claims, AI Models Are Still Failing Security — https://www.veracode.com/resources/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] Invicti — Vibe Coding Security Checklist: How to Secure AI-Generated Apps — https://www.invicti.com/blog/web-security/vibe-coding-security-checklist-how-to-secure-ai-generated-apps

[4] Cloud Security Alliance 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/

[5] Autonoma — Vibe Coding Security Risks: Why 53% of AI Code Has Security Holes — https://getautonoma.com/blog/vibe-coding-security-risks

[6] DEV Community / Vitalii Petrenko — I Checked What Security Vulnerabilities AI Coding Tools Actually Introduce — https://dev.to/vitalii_petrenko_dev/i-checked-what-security-vulnerabilities-ai-coding-tools-actually-introduce-1cjd

[7] Beagle Security — Using AI-Generated Code Safely (Vibe Coding Security) — https://beaglesecurity.com/blog/article/using-ai-generated-code-safely.html

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

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

[10] Supply & Demand Chain Executive / Endor Labs — The Hidden Dependency Risk of AI-Written Code — https://www.sdcexec.com/software-technology/ai-ar/article/22959921/endor-labs-the-hidden-dependency-risk-of-aiwritten-code

[11] Retool Blog — The Risks of Vibe Coding: Security Vulnerabilities and Enterprise Pitfalls — https://retool.com/blog/vibe-coding-risks

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

[13] Variant Systems — Is Your AI-Built App Production Ready? The Checklist — https://variantsystems.io/blog/ai-app-production-readiness-checklist

[14] Aikido Security — SAST Platform: Static Code Analysis — https://www.aikido.dev/code/static-code-analysis-sast

[15] Cloud Security Alliance Labs — CSA Research Note: AI-Generated Code Vulnerability Surge 2026 — https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/

[16] Cycode — AI Application Security: Testing and Best Practices — https://cycode.com/blog/ai-application-security/