Почему «работает» не значит «можно выпускать»

Разрыв между функциональностью и безопасностью: как AI ускорил разработку, но не ускорил контроль

Введение: разрыв, который AI сделал видимым

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

Теперь разрыв стал мгновенным. AI-инструменты — Copilot, Claude Code, Cursor, Windsurf — позволяют за несколько часов написать то, на что раньше уходили дни. Pull request появляется быстро, выглядит работающим, тесты проходят. Всё хорошо. Но «работает» и «безопасно выпускать» — это разные утверждения, разделённые целым пластом проверок, которые при высокой скорости никто не успевает сделать.

Эта статья — для CTO, VP Engineering, Tech Lead и AppSec-специалистов, которые хотят понять, где именно расползается этот разрыв и что с ним делать практически, не теряя скорость разработки.

Что значит «работает»

«Работает» — значит функция выполняет то, что от неё просят, тесты зелёные, приложение запускается, данные возвращаются. Это необходимое условие. Но не достаточное.

Выпускаемый в production код несёт несколько дополнительных слоёв ответственности, которые не видны через призму «запустилось и не упало»:

1. Безопасность — нет ли уязвимостей в коде, зависимостях, конфигурации.
2. Соответствие принципу наименьших привилегий — не открыто ли лишнего.
3. Отсутствие секретов и чувствительных данных в коде или истории коммитов.
4. Целостность цепочки поставок — откуда пришли зависимости и что в них.
5. Корректность конфигурации для production-среды, а не для localhost.
6. Наблюдаемость и возможность отката, если что-то пойдёт не так.

Именно здесь «работает» расходится с «можно выпускать».

AI ускорил код. Контроль — нет

Инструменты AI-кодинга радикально изменили скорость разработки. По данным GitHub, Copilot повышает продуктивность разработчиков примерно на 55% [7]. К 2024 году 97% разработчиков хотя бы однажды использовали AI-инструменты [8]. В 2024 году 41% всего написанного кода был AI-сгенерированным — и значительная его часть попадала в production без security-ревью [9].

Но AI не знает вашего threat model, внутренних стандартов или требований compliance. Он имитирует паттерны из обучающих данных — а там полно небезопасных примеров [1]. Именно поэтому исследователи из Cloud Security Alliance зафиксировали, что 62% AI-сгенерированного кода содержит архитектурные дефекты или известные уязвимости [1].

Исследование, опубликованное на USENIX Security 2025, проверило 16 моделей генерации кода и выявило среднюю частоту галлюцинаций пакетов 19,6% [3] — почти каждый пятый пакет, который AI предлагает установить, может не существовать. А значит — стать вектором атаки.

Apiiro зафиксировала, что к июню 2025 года AI-инструменты добавляли более 10 000 новых security-находок в месяц — рост в 10 раз за полгода [10]. При этом синтаксические ошибки AI снизил на 76%, а логические — на 60%. Проблема сместилась: от поверхностных к системным и архитектурным уязвимостям.

Пять слоёв, где «работает» разрушается

1. Код работает, но несёт уязвимости

Первый и самый очевидный слой. Исследование Pearce et al. (одно из первых систематических) показало, что около 40% программ, написанных Copilot, содержат уязвимости [11]. Последующие работы 2024–2025 годов показывают, что повторные итерации не улучшают ситуацию — рефайнинг кода через AI может вводить новые проблемы [11].

Частые типы дефектов в AI-коде:

• SQL-инъекции (CWE-89) и XSS (CWE-80) — AI часто использует конкатенацию строк как «быстрое» решение.
• Отсутствие аутентификации или авторизации — особенно в агентском режиме, когда AI строит целые фичи без явного требования добавить auth.
• Слабая или отсутствующая криптография (CWE-327).
• Отключённые механизмы защиты на уровне базы данных (Row Level Security, например, в Supabase — по данным аудитов, около 70% vibe-coded приложений имеют эту проблему) [9].

Georgia Tech's Vibe Security Radar к марту 2026 года идентифицировал 74 CVE, напрямую прослеживаемых к AI-инструментам; только за март 2026 — 35 из них [12].

2. Зависимости: риск, приехавший снаружи

По оценкам, 80–90% современного кода состоит из зависимостей [5]. И OWASP 2025, впервые выделив Software Supply Chain Failures отдельной категорией (A03:2025), признал: основной вектор атаки переместился с вашего кода на то, от чего он зависит.

Что происходит сегодня:

• Злоумышленники публикуют пакеты с именами, похожими на внутренние библиотеки (dependency confusion), и сборочная система подтягивает публичную, вредоносную версию [5].
• Атаки типа XZ Utils (CVE-2024-3094): многолетняя работа по получению доверия мейнтейнера, потом закладка бэкдора в официальный релиз [13].
• Shai-Hulud, первый самораспространяющийся npm-червь 2025 года: заражал пакеты, собирал npm-токены и расширялся через них [5].
• Атака на Bybit ($1,5 млрд, 2025): компрометация кода кошелька, который вёл себя нормально во всех случаях, кроме одного специфического условия [14].

Особо опасны транзитивные зависимости: уязвимость может жить не в том пакете, который вы добавили явно, а в зависимости его зависимости. Их не видно в code review.

3. Секреты в коде: тихая бомба

В 2024 году на публичных репозиториях GitHub было обнаружено более 39 миллионов утечек секретов — рост на 67% год к году [2]. GitGuardian зафиксировал 23,8 миллиона новых захардкоденных секретов за тот же период [15]. В 2025 году эти цифры выросли ещё на 34% [16].

Отдельный тревожный паттерн: AI-assisted коммиты утекают секреты примерно вдвое чаще, чем написанные вручную [16]. Причины:

• AI генерирует «работающий» код с placeholder-ключами, которые остаются в продакшне.
• Инструменты автодополнения могут воспроизводить credentials, виденные в обучающих данных.
• Разработчики, работающие в высоком темпе, не замечают, что секрет попал в diff.

Критически важный факт: 70% секретов, утёкших в 2022 году, остаются активными по сей день [15]. Атака на казначейство США в 2024 году началась с одного утёкшего API-ключа для платформы BeyondTrust [15].

4. Конфигурация: production ≠ localhost

Код может идеально работать на локальной машине и при этом нести критические конфигурационные уязвимости в production.

Классические примеры:

• Широкий CORS (Access-Control-Allow-Origin: *): нормально для локальной разработки, катастрофично для production API с авторизацией [17]. CVE-2024-8183 в Prefect — именно такой случай.
• Debug-режим в production: stack traces видны внешнему миру, иногда с переменными окружения.
• Null-origin в белом списке CORS: разработчики добавляют его для локального тестирования и забывают убрать [17].
• Чрезмерно широкие IAM-права: сервис имеет доступ ко всему, хотя нужен был доступ к одному бакету.

AI отлично умеет сгенерировать «работающую конфигурацию». Он не умеет угадать, что это production-среда с реальными пользователями.

5. Галлюцинированные пакеты: slopsquatting

Это один из самых новых и недооценённых векторов. USENIX Security 2025: все 16 протестированных моделей показали существенную частоту галлюцинаций пакетов, в среднем 19,6% [3]. Для коммерческих моделей (GPT-4, Claude) — около 5%, что звучит лучше, но на масштабе разработки означает сотни потенциально опасных install-команд.

Как это работает: злоумышленник находит имя пакета, который AI регулярно галлюцинирует, регистрирует его в npm или PyPI с вредоносным payload-ом и ждёт. Когда следующий разработчик попросит AI написать аналогичный код — тот снова предложит «то же имя». Исследователь Bar Lanyado зарегистрировал пустой пакет huggingface-cli на PyPI и за три месяца получил более 35 000 загрузок — включая запросы от инженеров крупных компаний [3].

Феномен получил название «slopsquatting»: в отличие от классического typosquatting, здесь не нужно угадывать опечатку. Достаточно знать, что именно AI уверенно придумывает.

Что это значит для процессов: проблема скорости и контроля

Все описанные риски объединяет одно: они стали проблемой именно сейчас, потому что скорость генерации кода обогнала скорость его проверки.

По данным отчёта Cortex 2024 State of Production Readiness, 98% технических лидеров лично сталкивались с серьёзными последствиями выпуска без надлежащих production-readiness проверок [4]. 62% видели рост change failure rate. 52% — задержки в поставке. При этом 66% называют главной проблемой непоследовательность стандартов между командами [4].

Это не вопрос профессионализма разработчиков. Это структурная проблема: pull request появляется быстро, diff большой (AI генерирует много кода сразу), code review под давлением времени делается по диагонали, зависимости никто не смотрит до конца, конфигурация «выглядит нормально». В этом контексте даже опытная команда пропускает критические риски.

Исследование Perry et al. показало, что разработчики, использующие AI-ассистентов, не только пишут менее безопасный код, но и демонстрируют «ложное ощущение безопасности» — часто оценивают свои небезопасные решения как безопасные [11].

Что проверять до merge

Ниже — не полная AppSec-программа, а минимальный набор gate-проверок, без которых «работает» не равно «можно выпускать».

Проверки кода

1. SAST-сканирование на критические CWE: SQLi, XSS, SSRF, insecure crypto, command injection — автоматически на каждый PR.
2. Ревью аутентификации и авторизации: явно проверить, что каждый endpoint защищён, а не предположить это.
3. Поиск секретов: secrets scanning в CI — не как опция, а как блокирующий gate.
4. Проверка конфигурации: CORS-настройки, debug-флаги, широкие IAM-права.

Проверки зависимостей

1. SCA (Software Composition Analysis): каждая новая или обновлённая зависимость — с проверкой на CVE.
2. Транзитивные зависимости: не только прямые, но и indirect deps.
3. Lock-файлы: проверка, что они зафиксированы и не изменились неожиданно.
4. Верификация имён пакетов: особенно если они были предложены AI — проверить существование в официальном registry.
5. SBOM: наличие актуального Software Bill of Materials для понимания полного состава.

Проверки перед релизом

1. Релизный контекст: что именно изменилось по сравнению с предыдущим релизом — не только фичи, но и зависимости и конфиги.
2. Production-конфигурация: отдельный прогон по конфигурационным файлам для production-окружения.
3. Ротация секретов: если секрет был упомянут в коммитах — ротировать его, даже если коммит был приватным.

Ошибки и антипаттерны

«Тесты проходят — значит безопасно»

Функциональные тесты проверяют, что код делает то, что должен. Security-уязвимости — это когда код делает что-то, чего не должен: позволяет обойти авторизацию, выполнить injection, утечь данные. Эти сценарии в обычные тесты не попадают.

«SAST запускается, но мы смотрим только на CRITICAL»

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

«Мы используем известные пакеты»

SolarWinds и Bybit показали: известные пакеты от известных вендоров тоже компрометируются. OWASP A03:2025 прямо указывает: атаки работают через цепочку доверия, а не против неё [5].

«AI-агент сам проверит код»

Veracode проверила более 100 LLM на security-чувствительных задачах кодинга: 45% выборок содержали OWASP Top 10 уязвимости, и результаты не улучшались от тест-цикла к тест-циклу [9]. Самопроверка модели ловит поверхностные проблемы, но системно пропускает инфраструктурные и контекстно-зависимые.

«Посмотрим на security после релиза»

IBM's Cost of a Data Breach фиксирует: исправление уязвимости в production в 6 раз дороже, чем обнаружение в разработке [6]. Shift-left — не идеология, а экономика.

Кейсы

Moltbook: от промпта до взлома за 72 часа

В январе 2026 года основатель AI-социальной сети Moltbook, построившей всё приложение исключительно через AI-инструменты без написания ни одной строки кода вручную, столкнулся с утечкой 1,5 миллиона API-токенов аутентификации и 35 000 адресов электронной почты менее чем через 72 часа после запуска [9]. Уязвимость была конфигурационной и элементарной — её обнаружил бы стандартный code review. Но code review не было.

XZ Utils (CVE-2024-3094): закладка через доверие

Многолетняя атака на open-source библиотеку xz/liblzma: злоумышленник методично завоёвывал доверие сообщества, стал мейнтейнером и внедрил бэкдор в официальные релизы 5.6.0–5.6.1 [13]. Обнаружили случайно — по аномалиям в поведении SSH. Код «работал», релизы были подписаны, артефакты выглядели легитимно.

Bybit ($1,5 млрд, 2025)

Атака на кошелёк: вредоносный код в зависимости был активирован только в одном специфическом условии — когда целевой кошелёк Bybit выполнял транзакцию [14]. Всё остальное время приложение работало нормально. Автоматические тесты ничего не нашли. Security review не обнаружил условного триггера.

Стандарты и регуляторный контекст

NIST выпустил SSDF 1.1 (SP 800-218) как фреймворк безопасной разработки, а в декабре 2025 опубликовал для публичного комментирования SSDF 1.2 с обновлёнными практиками для современных реалий [18]. В июле 2024 вышел SP 800-218A — расширение SSDF специально для AI-компонентов и dual-use моделей [18].

Ключевые принципы SSDF применительно к теме статьи: интегрировать security-практики во весь SDLC, а не только в конце; обеспечивать целостность артефактов; контролировать цепочку поставок. Это не про «проверить перед релизом» — это про встроить проверки в каждый шаг.

На уровне международных стандартов значимы: OpenSSF Scorecard для оценки зрелости security-практик в open-source проектах; SLSA (Supply-chain Levels for Software Artifacts) для attestation артефактов; требования SBOM, уже обязательные для federal procurement в США [5].

Как это выглядит в pipeline

Практическая архитектура контроля, которая не ломает скорость:

• В IDE: подсказки по безопасному коду на уровне автодополнения, минимальная задержка.
• На PR/commit: secrets scanning (блокирующий), SAST (критические находки), SCA для новых/изменённых зависимостей.
• В CI/CD: более полное SAST/DAST/SCA, проверка конфигурации, lock-файлов, SBOM-генерация.
• Release gate: итоговая проверка что именно изменилось, есть ли новые CVE, нет ли регрессий в security.

Shift-left security в своей основе — экономическое решение. Задача не в том, чтобы замедлить разработку, а в том, чтобы дать сигнал там, где он стоит дешевле всего: до merge, а не после инцидента [6].

Важный баланс: alert fatigue убивает compliance. Если pipeline выдаёт 200 предупреждений при первом запуске, разработчики начинают их игнорировать. Начинать стоит только с CRITICAL-находок, добиваться нуля, потом расширять зону контроля [19].

Место HighVibe в этой картине

HighVibe — это дополнительный слой контроля именно в точке, где разрыв между «работает» и «можно выпускать» проявляется сильнее всего: на стадии PR и релиза.

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

Это не замена SAST, SCA или другим инструментам AppSec-стека. Это слой рядом с ними — специально для тех изменений, которые приходят быстро, генерируются AI и читаются под давлением времени. Именно там, где «PR выглядит ок», но внутри может быть галлюцинированная зависимость, захардкоженный ключ или открытый CORS.

Подробнее: highvibe.dev

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

«Работает» — хорошая новость. Это значит, что функциональность реализована. Но выпуск в production — это другое утверждение: что код не только делает то, что должен, но и не делает того, чего не должен, и не несёт рисков, которые вы не приняли сознательно.

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

Практические шаги для команды:

1. Определить, что является блокирующим для релиза — и зафиксировать это явно, не в голове тимлида.
2. Встроить secrets scanning и SAST в CI как блокирующие gate, а не advisory.
3. Ввести явную проверку зависимостей для каждого нового или обновлённого пакета — особенно если он был предложен AI.
4. Проверять конфигурацию production-окружения отдельно, не только код.
5. Относиться к AI-generated PR так же, как к PR от Junior-разработчика: читать, а не доверять по умолчанию.

Скорость — это конкурентное преимущество. Но инцидент в production стоит дороже, чем несколько часов контроля до релиза. Разрыв между «работает» и «можно выпускать» — это не барьер на пути к скорости. Это страховка, которая позволяет сохранить скорость надолго.

Источники

[1] Cloud Security Alliance — "Understanding Security Risks in AI-Generated Code" — https://cloudsecurityalliance.org/blog/2025/07/09/understanding-security-risks-in-ai-generated-code

[2] BleepingComputer — "GitHub expands security tools after 39 million secrets leaked in 2024" — https://www.bleepingcomputer.com/news/security/github-expands-security-tools-after-39-million-secrets-leaked-in-2024/

[3] USENIX Security 2025 — "We Have a Package for You: A Comprehensive Analysis of Package Hallucinations in Code" — https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code

[4] Cortex — "The 2024 State of Software Production Readiness" — https://www.cortex.io/report/the-2024-state-of-software-production-readiness

[5] OWASP — "A03:2025 Software Supply Chain Failures" — https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/

[6] IBM / Medium — "Shift-Left Security: Why DevSecOps Is the Most Important Skill" — https://medium.com/@lahiruavishka747/shift-left-security-why-devsecops-is-the-most-important-skill-youre-probably-ignoring-aaa397f90f09

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

[8] Veracode — там же

[9] OX Security — "Vibe Coding Security: Why 62% Of AI-Generated Code Ships With Vulnerabilities" — https://www.ox.security/blog/vibe-coding-security/

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

[11] arXiv — "Security Degradation in Iterative AI Code Generation" — https://arxiv.org/pdf/2506.11022

[12] Georgia Tech SSLab / Futurity — "AI-generated code is vulnerable" — https://www.futurity.org/ai-generated-code-vulnerable-3330542/

[13] OWASP / Authgear — "OWASP 2025 Top 10: A03 Software Supply Chain Failures" — https://www.authgear.com/post/owasp-2025-software-supply-chain-failures/

[14] CrossClassify — "How to Prevent OWASP A03:2025 Software Supply Chain Failures" — https://www.crossclassify.com/resources/articles/how-to-prevent-owasp-software-supply-chain-failures-with-continuous-third-party-monitoring-sbom-management-and-crossclassify-device-fingerprinting/

[15] ZeroHost Security Blog — "23.8 Million Secrets Leaked on GitHub: The Case for Credentials That Expire" — https://zerohost.net/blog/github-secrets-leaked-case-for-expiring-credentials/

[16] TechRadar — "Over 29 million secrets were leaked on GitHub in 2025, and AI really isn't helping" — https://www.techradar.com/pro/security/over-29-million-secrets-were-leaked-on-github-in-2025-and-ai-really-isnt-helping

[17] Medium / InstaTunnel — "CORS of Confusion: How a Misconfigured Header Can Punch a Hole in Your Security" — https://medium.com/@instatunnel/cors-of-confusion-how-a-misconfigured-header-can-punch-a-hole-in-your-security-6749e8c3f541

[18] NIST — "Secure Software Development Framework (SSDF) Version 1.2 Available for Public Comment" — https://www.nist.gov/news-events/news/2025/12/secure-software-development-framework-ssdf-version-12-available-public

[19] Medium — "Shift-Left Security: Why DevSecOps Is the Most Important Skill You're Probably Ignoring" — https://medium.com/@lahiruavishka747/shift-left-security-why-devsecops-is-the-most-important-skill-youre-probably-ignoring-aaa397f90f09тей) — частично доступна, но неполна; приводить конкретные сравнительные рейтинги без полного контекста рискованно.