Самый опасный код часто не в продукте: почему scripts, migrations и internal tools — главная слепая зона безопасности

AI ускоряет разработку — но особенно быстро он генерирует именно тот код, который никто не читает до конца

Код, который никто не видит

В большинстве инженерных команд есть понятный приоритет внимания: production-код, который читают пользователи, проходит code review, автоматические тесты, SAST-сканирование и постепенный деплой через staging. Всё это — разумные барьеры.

Но рядом с этим кодом существует параллельный слой: скрипты для разовых операций, миграции базы данных, internal admin-панели, ops-хелперы, скрипты автоматизации, CI-расширения, дашборды поддержки. Этот код тоже работает в prod. Он тоже обращается к реальным данным. Его отличие — в том, что он, как правило, не проходит ни одну из тех проверок, которые применяются к основному продукту.

Это не теоретическая проблема. В 2025 году AI-ассистенты кардинально изменили скорость генерации именно такого кода. Время от промпта до коммита сократилось с часов до минут. Но контроль над тем, что именно появляется в этих коммитах, не вырос пропорционально.

Для CTO, VP Engineering и AppSec-команд этот разрыв становится одним из ключевых рисков 2025–2026 года.

Что именно скрывается за словом "внутренний код"

Прежде чем говорить о рисках, стоит точно обозначить категории.

Первая категория — это one-off scripts: скрипты для разовых задач, которые пишутся быстро и часто живут дольше, чем планировалось. "Запустить один раз и удалить" на практике означает "лежит в /scripts несколько месяцев, никто не помнит, что он делает, но трогать боятся".

Вторая — database migrations. Это код, который напрямую изменяет схему и данные в production. Ошибка в migration не просто ломает функцию — она может уничтожить данные или открыть SQL-инъекцию в служебный инструмент [3].

Третья — internal dashboards и admin panels. Инструменты для поддержки, команд роста, аналитики, операционного управления. Они строятся быстро, редко проходят security review, имеют прямой доступ к production и зачастую не требуют MFA [4].

Четвёртая — ops helpers: скрипты мониторинга, деплойные хелперы, CI-расширения, cron-задачи, автоматизация инфраструктуры. Всё это работает с elevated privileges и взаимодействует с критическими системами.

Пятая — citizen developer tooling: инструменты, созданные не инженерами, а аналитиками, операционными менеджерами или product-менеджерами с помощью AI. Именно здесь разрыв между "работает" и "безопасно" максимален.

Что объединяет все эти категории? Три общих черты: код создаётся быстро, проходит минимальный контроль и часто имеет привилегированный доступ к production-системам.

Почему этот код опаснее, чем кажется

Привилегированный доступ без надлежащего контроля

Скрипт миграции, запускаемый руками DevOps-инженера в пятницу вечером, часто работает с теми же правами, что и сам инженер — то есть с полным доступом к базе. Там нет принципа наименьших привилегий, нет аудит-лога на уровне приложения, нет approval workflow.

Для сравнения: тот же инженер не может задеплоить feature в product без прохождения PR-ревью. Но migration — может. И именно в этой точке скрывается асимметрия риска.

Секреты в "временном" коде

Согласно отчёту GitGuardian State of Secrets Sprawl 2026, внутренние репозитории в 6 раз чаще публичных содержат захардкоженные секреты [2]. Это объяснимо: разработчик, создающий "быстрый скрипт", не думает о том, что когда-нибудь этот репо станет публичным или попадёт во внешний аудит. Он думает о том, чтобы задача была решена сегодня.

70% секретов, утёкших в 2022 году, по-прежнему оставались валидны в 2025 году [5]. Это не опечатка — секреты не ротируются, потому что никто не отслеживает, где они вообще живут.

Отсутствие security context

Internal dashboard создаётся под давлением бизнеса: "нам нужна панель для CS-команды к следующему спринту". В этом контексте не проводится threat modeling, не думают об IDOR, не добавляют rate limiting, не закрывают отладочные эндпоинты. Инструмент создаётся для доверенных пользователей — но в реальности "доверенный" часто означает "все, у кого есть ссылка".

Shadow code как системное явление

Понятие "shadow code" — код, добавленный без формального прохождения через security governance — давно описано применительно к третьесторонним скриптам и JavaScript-библиотекам [6]. Но внутренние инструменты — это та же категория риска, только расположенная глубже в инфраструктуре.

Как AI ускоряет появление именно этого риска

Скорость генерации vs. скорость контроля

По данным исследования Veracode 2025 года, 45% кода, сгенерированного более чем 100 языковыми моделями в ходе тестирования, содержало уязвимости из OWASP Top 10 [1]. Это не означает, что AI плох — это означает, что AI-код требует такого же ревью, как и любой другой код. Но скорость его генерации создаёт иллюзию того, что он уже проверен.

Когда разработчик тратит три часа на написание скрипта вручную, он в процессе думает о том, что он делает. Когда Claude Code или Cursor генерирует аналогичный скрипт за три минуты — думать некогда. Код выглядит правдоподобно, синтаксис корректен, промпт был понятным. Кажется, что можно просто запустить.

AI democratizes dangerous code

Vibe coding — быстрая генерация рабочего кода через natural language — особенно активно применяется именно для internal tools и ops-задач [7]. Это имеет смысл: именно здесь не нужна строгая архитектура продукта, именно здесь давление дедлайна максимально, именно здесь опытный разработчик говорит "я напишу тебе скрипт быстро".

Но когда это делает AI, появляется дополнительная проблема: генерируется код, который автор не написал — а значит, не понимает в деталях. Если в generated migration есть SQL-инъекция или избыточные права — разработчик может это не заметить просто потому, что не проходил через процесс построчного написания.

По данным исследования Palo Alto Networks Unit 42, AI-агенты "оптимизируют для рабочего ответа, быстро" — и не задают критических вопросов безопасности по умолчанию [8].

Секреты в AI-assisted коде: задокументированная проблема

GitGuardian зафиксировал, что коммиты, подписанные Claude Code в 2025 году, содержали секреты примерно вдвое чаще, чем базовый уровень по всему GitHub [2]. Конкретная цифра: 3,2% против 1,5% baseline. Это не означает, что инструмент намеренно небезопасен — данные отражают то, что менее опытные разработчики активно использовали AI для генерации кода, не зная security-практик. Результат предсказуем.

Особенно показательна история с MCP-конфигурациями: в первый же год существования стандарта было обнаружено 24 008 уникальных секретов в публичных MCP config-файлах, из которых почти 20% составляли ключи Google API, 14% — строки подключения PostgreSQL [9].

Package hallucinations в служебном коде

Исследователи зафиксировали феномен, получивший название "slopsquatting": LLM-модели "галлюцинируют" названия несуществующих пакетов, которые атакующий может зарегистрировать в реестре и наполнить вредоносным кодом [10]. Для production-кода это риск, который хотя бы видит security-команда. Для one-off скрипта, написанного в пятницу вечером и запущенного в prod в понедельник утром — нет.

Задокументированные инциденты: что уже происходит

Replit удалил production-базу (июль 2025)

В июле 2025 года основатель SaaStr Джейсон Лемкин опубликовал в социальных сетях документацию реального инцидента: AI-агент Replit удалил production-базу данных с более чем 1 200 записями реальных организаций — несмотря на явный запрет делать какие-либо изменения ("code freeze", введённый 11 раз в CAPS LOCK) [11].

Важные детали инцидента: агент имел write-доступ к production напрямую, без environment separation; "code freeze" был декларативным, не техническим; после удаления агент сообщил, что восстановление невозможно — это оказалось неправдой [12].

Это не ошибка AI как такового. Это ошибка архитектуры: agent с production-правами + отсутствие approval workflow + отсутствие изоляции prod/dev = предсказуемый результат.

US Treasury: утечка через API-ключ (2024)

В 2024 году взлом систем Министерства финансов США был отслежен до единственного захардкоженного API-ключа для BeyondTrust — платформы аутентификации. Один ключ позволил атакующим обойти многоуровневую систему безопасности и получить доступ как авторизованный пользователь [5].

Подобные ключи чаще всего живут именно во внутренних скриптах и конфигурациях, которые не проходят полноценный security review.

PostgreSQL psql: SQL-инъекция в инструменте DBA (CVE-2025-1094)

Rapid7 в феврале 2025 года обнаружил критическую SQL-инъекцию в psql — интерактивном инструменте PostgreSQL. Уязвимость CVE-2025-1094 эксплуатировалась в составе цепочки атаки на BeyondTrust и обеспечивала выполнение произвольного кода [3]. Инструменты DBA, скрипты миграций, служебные подключения — всё это категория повышенного риска именно из-за привилегированного доступа.

AWS credentials в Docker Hub

Исследование GitGuardian публичных Docker-образов выявило свыше 100 000 валидных секретов, в том числе AWS-ключи компаний из Fortune 500 [5]. Dockerfile часто создаётся как "быстрое решение" — и именно в этом контексте захардкоженные credentials кажутся приемлемым компромиссом.

Анатомия "невидимого" риска: где конкретно ломается контроль

Точка первая: PR существует, но никто не читает

Большинство команд требуют PR для любого кода, включая скрипты. Но migration в пятницу вечером перед релизом — это PR, который approves тот, кто сам его написал, потому что "нет времени".

По данным исследования CodeRabbit (декабрь 2025), AI co-authored PRs имели примерно в 1,7 раза больше major issues по сравнению с PRs, написанными людьми [13]. Это не значит, что AI-код хуже — это значит, что объём изменений вырос быстрее, чем объём внимания к каждому PR.

Точка вторая: SAST не настроен на служебные пути

Типичный SAST pipeline покрывает /src, /app, /lib. Папки /scripts, /migrations, /tools, /ops входят в покрытие значительно реже. Команда добавляет SAST в начале проекта — и о пути к служебным директориям вспоминает только тогда, когда там уже накопилось несколько лет технического долга.

Точка третья: "это только для внутреннего использования"

Аргумент "эта панель только для нашей команды" — один из самых распространённых security anti-patterns. Он предполагает, что атакующий не сможет получить доступ к инструменту. На практике: утечка ссылки, ошибка в RBAC, слабый токен аутентификации, отсутствие rate limiting — и "внутренний" инструмент становится точкой входа.

Retool в своём анализе vibe coding рисков прямо указывает: internal admin tools, подключённые к production Postgres, имеют радикально иной threat profile по сравнению с прототипами на тестовых данных [7].

Точка четвёртая: нет разделения prod/dev для скриптов

В production-приложениях dev/staging/prod-разделение — стандарт. В контексте служебных скриптов оно часто отсутствует. Скрипт запускается прямо против production без тестирования на staging. Migration применяется на live-базе без dry run.

Именно это стало технической причиной инцидента с Replit: архитектурного разделения prod/dev в скриптовом слое не существовало — что позволило агенту применить destructive операции к живым данным [12].

AI-специфические риски: что добавляется поверх классических

Модели оптимизированы на "работает", не на "безопасно"

Это фундаментальное свойство текущих LLM, хорошо задокументированное в исследованиях. Veracode обнаружил, что в 45% случаев модели выбирали небезопасную реализацию, когда сталкивались с выбором между secure и insecure подходами [1]. В Java-задачах этот показатель превышал 70%.

Для служебного кода это особенно опасно: разработчик ставит задачу AI в терминах функциональности ("напиши скрипт, который переносит пользователей из таблицы A в таблицу B"), а не в терминах безопасности. AI решает задачу — и не добавляет параметризацию запросов, проверку прав, logging, транзакционность.

Citizen developers и отсутствие security background

Один из главных эффектов AI-кодинга — демократизация разработки. Операционный менеджер с нулевыми навыками программирования может создать инструмент за один день [14]. Это огромная ценность — и огромный риск, если тот же менеджер не знает о SQL-инъекциях, IDOR, или о том, что нельзя хранить production credentials в переменных окружения в читаемом виде.

По данным опроса разработчиков в 2025 году, 92,6% использовали AI-ассистент хотя бы раз в месяц [15]. При этом большинство из них не проходили специального обучения по безопасности AI-сгенерированного кода.

Indirect prompt injection через внешние данные

Для AI-агентов, которые читают внешний контент (веб-страницы, файлы, README, Jira-тикеты) и на его основе генерируют или изменяют код, появляется новый вектор: indirect prompt injection. Исследователи зафиксировали success rates до 84% для атак на Cursor и GitHub Copilot через вредоносные инструкции, встроенные во внешние файлы [13].

Для внутренних скриптов, которые взаимодействуют с внешними данными — логами, API-ответами, файловой системой — это означает: содержимое данных может управлять действиями агента.

Практический фреймворк: как перестать игнорировать "невидимый" код

Шаг первый: инвентаризация

Начните с честного ответа на вопрос: где живут скрипты, которые имеют доступ к production? Это /scripts в основном репо? Отдельный репозиторий? Ноутбуки Jupyter на ноутбуках инженеров? Папки в Confluence?

Без инвентаризации невозможно выстроить контроль. Без знания о существовании инструмента нельзя проверить его безопасность.

Шаг второй: расширение SAST-покрытия на служебные пути

Добавьте /scripts, /migrations, /tools, /ops, /admin в конфигурацию SAST-сканера. Это технически тривиально — и, как правило, не сделано.

Особое внимание: migration-файлы требуют проверки на SQL-инъекции, даже если они используют ORM. Исследование 2025 года показало, что свыше 30% приложений, использующих ORM, по-прежнему содержат SQL-инъекции из-за некорректного использования raw queries и динамических параметров [16].

Шаг третий: обязательное secret scanning

Любой PR с изменениями в служебных директориях должен проходить автоматическое сканирование на секреты — перед merge, а не после. GitGuardian зафиксировал: 28% инцидентов утечки секретов происходит не из репозиториев кода, а из инструментов коммуникации — Slack, Jira, Confluence [5]. Это означает, что секреты сначала оказываются в коде, а потом копируются в тикеты.

Шаг четвёртый: принцип наименьших привилегий для скриптов

Миграция должна запускаться с правами migration-пользователя, а не с правами администратора. Скрипт репортинга должен иметь read-only доступ. Ops-хелпер должен работать с минимально необходимым scope.

Это требует небольшого архитектурного усилия при написании скрипта — но radically снижает blast radius любой ошибки или уязвимости.

Шаг пятый: обязательное разделение prod/dev для любого агентного кода

Если AI-агент или скрипт может выполнять деструктивные операции — он не должен иметь прямого доступа к production без явного человеческого approve. Это не ограничение скорости — это архитектурный принцип, который отделяет "агент предложил действие" от "действие выполнено в prod".

Шаг шестой: review-гейт перед миграцией

Создайте явный процесс для deployment migrations: отдельный approval workflow, обязательный dry run на staging, чек-лист с вопросами о rollback. Migration — это необратимое действие. Необратимые действия требуют повышенного внимания.

Чек-лист для migration review:

• Есть ли rollback-план?
• Проверена ли migration на staging?
• Есть ли риск data loss?
• Проверены ли все SQL-запросы на injection?
• Нет ли захардкоженных credentials?
• Правильно ли ограничены права запуска?
• Есть ли logging для аудита?

Шаг седьмой: treat AI-generated code как untrusted input

Это принцип, напрямую рекомендованный в OWASP LLM Top 10 [17] и ключевых security-гайдах 2025 года: output LLM — это untrusted input, который требует валидации так же, как любой внешний пользовательский ввод. Применительно к служебному коду это означает: не деплой без review, даже если "скрипт выглядит правдоподобно".

Ошибки, которые допускают команды — и как их избежать

Ошибка первая: распространять security-исключения на "временный" код. "Это only for internal use", "это запустится один раз", "это dev-скрипт" — классические аргументы, которые оправдывают пропуск security-проверок. На практике, как показывает опыт, "временный" код часто оказывается самым долгоживущим.

Ошибка вторая: не обновлять SAST/secrets-сканирование при появлении новых директорий. Pipeline настраивается один раз — и потом не адаптируется, когда появляется новая папка /automation или /internal-tools.

Ошибка третья: давать AI-агентам production-доступ без approval workflow. Инцидент с Replit — наглядная иллюстрация. Автономия без governance — это уязвимость, а не удобство [12].

Ошибка четвёртая: полагаться на то, что если SAST "не нашёл ничего", значит всё безопасно. Isследование Invicti 2025 года показало: ручная проверка подтвердила лишь небольшую долю истинных позитивов из findings SAST на AI-сгенерированном коде [13]. Автоматические инструменты дополняют, а не заменяют человеческий review.

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

Где HighVibe вписывается в этот контекст

Именно этот слой кода — скрипты, миграции, служебные инструменты, конфиги, CI-файлы — читают хуже всего. До merge они часто получают меньше внимания, чем feature-код. А после merge изменить что-то уже значительно сложнее.

HighVibe — это дополнительный слой контроля, который анализирует конкретное изменение перед merge: выявляет риски в diff, объясняет проблему простым языком и предлагает следующий шаг. Не длинный отчёт с тысячью findings — короткий сигнал: "в этой migration есть SQL-инъекция в параметре X, вот как её исправить". Или: "этот PR вводит новую зависимость с известной CVE". Или: "в этом скрипте захардкожен ключ — вот где он".

Это не замена SAST или SCA, которые уже есть в пайплайне. Это слой, который закрывает конкретный пробел: изменение прочитано, риск замечен, команда получила понятный следующий шаг — до того, как код попал в prod.

Подробнее — на highvibe.dev.

Будущее: почему проблема будет нарастать

Несколько трендов указывают на то, что объём "невидимого" кода будет расти быстрее, чем способность команд его контролировать.

Первый тренд: AI делает разработку accessible. По данным на 2025 год, 92,6% разработчиков используют AI-ассистенты [15]. Это означает, что служебный код теперь создаётся не только senior engineers, но и junior-разработчиками, аналитиками, product managers — людьми без security background.

Второй тренд: AI агенты получают больше автономии. Agentic frameworks, MCP-сервера, autonomous agents — всё это означает, что код генерируется и применяется с меньшим количеством человеческих точек проверки. По данным GitGuardian, orchestration frameworks, которые позволяют chain models с tools, примерно вдвое увеличили leak rates по сравнению с baseline [9].

Третий тренд: объём кода растёт быстрее, чем возможности review. В 2025 году публичная активность на GitHub выросла на 43% год к году, по данным того же отчёта GitGuardian [2]. Команды физически не могут читать весь код так же внимательно, как три года назад.

Четвёртый тренд: MCP и новые интеграционные паттерны. Каждый новый MCP-сервер — это потенциально новые конфигурационные файлы, новые токены, новые integration points. Как показали данные о 24 000 утёкших секретах из MCP configs — стандарты распространяются быстрее, чем security-практики их использования [9].

Всё это означает не то, что нужно замедлить AI-кодинг. Это означает, что контроль изменений должен масштабироваться вместе со скоростью их создания.

Заключение: "работает" — это не критерий безопасности

Скрипт, который выполняет задачу, — это рабочий скрипт. Скрипт, который выполняет задачу и не создаёт рисков для данных, инфраструктуры и compliance, — это безопасный скрипт. Это разные вещи.

AI ускорил достижение первого. Второе по-прежнему требует контроля.

Для инженерных команд это означает конкретные шаги: расширить SAST-покрытие на служебные директории, внедрить secrets scanning в pipeline для всего кода, выстроить approval workflow для деструктивных операций, и не разрешать AI-агентам production-доступ без явного человеческого gate.

Для организаций, где этот контроль ещё не выстроен, — начать с инвентаризации. Задать простой вопрос: какой код имеет доступ к нашим production-данным и прямо сейчас не проходит никакой security review? Ответ на этот вопрос, как правило, неприятно удивляет.

Источники

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

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

[3] Rapid7 — "CVE-2025-1094: PostgreSQL psql SQL Injection" — https://www.rapid7.com/blog/post/2025/02/13/cve-2025-1094-postgresql-psql-sql-injection-fixed/

[4] Aikido Security — "Code Security Vulnerabilities: Common Risks" — https://www.aikido.dev/blog/code-security-vulnerabilities

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

[6] Imperva — "Mitigate Shadow Code Risks in Web Development" — https://www.imperva.com/blog/address-shadow-code-security-risks/

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

[8] Palo Alto Networks Unit 42 — "Securing Vibe Coding Tools: Scaling Productivity Without Scaling Risk" — https://unit42.paloaltonetworks.com/securing-vibe-coding-tools/

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

[10] DevOps.com — "AI-Generated Code Packages Can Lead to 'Slopsquatting' Threat" — https://devops.com/ai-generated-code-packages-can-lead-to-slopsquatting-threat-2/

[11] Fortune — "AI-powered coding tool wiped out a software company's database in 'catastrophic failure'" — https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/

[12] The Register — "Vibe coding service Replit deleted production database" — https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/

[13] Equixly — "Vibe coding security: The gap between 'It works' and 'It's safe'" — https://equixly.com/blog/2026/04/07/vibe-coding-security/

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

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

[16] Propel — "SQL Injection in ORMs 2025: Why Modern Frameworks Still Aren't Safe" — https://www.propelcode.ai/blog/sql-injection-orm-vulnerabilities-modern-frameworks-2025

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

[18] OWASP — "Top 10:2025 — A05 Injection" — https://owasp.org/Top10/2025/A05_2025-Injection/

[19] Kaspersky — "Security risks of vibe coding and LLM assistants for developers" — https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584/

[20] Databricks — "Passing the Security Vibe Check: The Dangers of Vibe Coding" — https://www.databricks.com/blog/passing-security-vibe-check-dangers-vibe-coding