Где AI-код прячет настоящий риск: CI workflows, Dockerfile, Terraform и миграции

Самые опасные строки в вашем репозитории — не в бизнес-логике

Почему проблема не там, где её ищут

С 2024 года дискуссия об AI-безопасности в разработке ведётся примерно так: исследователи считают уязвимости в бизнес-коде, команды настраивают SAST на репозиторий, CTO читает очередной отчёт о том, что "AI пишет код с уязвимостями". Отчёты точные. Вывод — неполный.

Настоящая проблема не в том, что AI-код в среднем хуже человеческого. Проблема в том, что AI не понимает разницы между файлами по уровню их критичности. Для языковой модели main.go и .github/workflows/deploy.yml — одинаково "просто код". Для атакующего это небо и земля.

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

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

Часть 1. CI workflows: файлы, которые никто не дочитывает

Что такое workflow-файл и почему он опасен

GitHub Actions workflow — это YAML-файл в директории .github/workflows/. Он описывает, что происходит при каждом push, PR или merge: какой код запускается, с какими переменными окружения, с каким уровнем доступа к репозиторию и облачной инфраструктуре.

С точки зрения безопасности workflow-файл — это не конфигурация. Это исполняемый код с привилегированным доступом. CI-runner работает с GITHUB_TOKEN, cloud credentials, NPM-токенами, SSH-ключами — всем, что нужно для сборки, тестирования и деплоя. OWASP фиксирует в своём CI/CD Top 10 [1]: CI/CD-системы "типично содержат десятки высокоценных credentials и токенов — к cloud-провайдерам, artifact registry, к самому SCM".

Как AI пишет workflow-файлы

AI генерирует синтаксически корректные workflow-файлы. Более того — часто добавляет "удобные" вещи: кэширование зависимостей, матричные сборки, автоматическую публикацию в реестр. Проблема в том, что он тиражирует небезопасные паттерны из обучающих данных:

• использует триггер pull_request_target вместо pull_request, не понимая, что первый даёт доступ к секретам базовой ветки из форков [2];
• закрепляет сторонние actions по тегу (@v2), а не по commit SHA, делая pipeline уязвимым к supply chain атакам [3];
• выводит в run: шаги с интерполяцией пользовательских данных (${{ github.event.issue.title }}), создавая инъекции команд [4];
• назначает избыточные permissions (write-all) — "чтобы точно работало".

Реальный инцидент: tj-actions и CVE-2025-30066

В марте 2025 был скомпрометирован GitHub Action tj-actions/changed-files, который использовался более чем в 23 000 репозиториев [5]. Атакующие модифицировали action таким образом, что он сканировал память CI-runner и печатал секреты в логах workflow в формате base64. CISA выпустила экстренный алерт [6].

Вектор атаки был прост: получить доступ к Personal Access Token (PAT) бота с правами на репозиторий action, подменить теги версий на вредоносный коммит. Все репозитории, использующие action по тегу, немедленно получили скомпрометированную версию.

В сентябре 2025 GitGuardian задокументировал кампанию GhostAction [7]: 327 скомпрометированных GitHub-аккаунтов, 817 репозиториев, 3 325 украденных секретов — включая AWS access keys, database credentials, PyPI и npm-токены. Атакующие инжектировали workflow-файлы, маскируясь под "Github Actions Security".

Почему reviewer не замечает

Эксперименты StepSecurity [8] показывают системную проблему: traditional EDR-решения не понимают CI/CD-контекст. Они видят низкоуровневые системные вызовы, но не различают легитимный деплой и компрометацию. Человек-reviewer сталкивается с другой проблемой: YAML-файл workflow выглядит как "конфигурация", не как "код". Внимание ослабевает. Строка uses: third-party/action@v1 проходит ревью быстрее, чем аналогичный импорт в Python.

Когда AI генерирует целый workflow-файл за секунды, reviewer получает 80 строк YAML — и тратит на них 30 секунд.

Часть 2. Dockerfile: слои, которые помнят всё

Природа Docker-слоёв и проблема персистентности

Dockerfile строит образ послойно. Каждая инструкция — RUN, COPY, ENV, ARG — создаёт неизменяемый слой. Ключевое свойство, о котором AI не предупреждает: если секрет попал в слой, он остаётся там навсегда — даже после последующего удаления [9].

# Небезопасно — секрет сохраняется в слое навсегда
ENV DATABASE_URL="postgres://admin:password@db:5432/prod"
RUN rm /tmp/secrets  # это не удаляет секрет из предыдущих слоёв

Команда docker history позволяет любому, у кого есть доступ к образу, извлечь значения переменных окружения из всех слоёв. В августе 2025 исследователи обнаружили более 10 000 образов на Docker Hub, содержащих production credentials — API-ключи, пароли баз данных, токены AI-моделей — из более чем 100 организаций, включая компании из Fortune 500 [10].

Что AI генерирует в Dockerfile

AI-ассистент, получая задачу "напиши Dockerfile для production Node.js сервиса", производит синтаксически корректный результат. При этом типичные проблемы:

• передача секретов через --build-arg (они попадают в метаданные образа и доступны через docker inspect);
• запуск контейнера от root (отсутствие директивы USER nonroot);
• использование тегов вместо digest для базовых образов (FROM node:20 вместо FROM node:20@sha256:...), что делает сборку уязвимой к supply chain атакам;
• отсутствие multi-stage build — в финальный образ попадают build-зависимости, dev-инструменты и отладочные компоненты.

В августе 2025 исследователи Binarly обнаружили, что десятки официальных Debian-based образов на Docker Hub всё ещё содержали XZ Utils backdoor (CVE-2024-3094, CVSS 10.0) — спустя месяцы после публичного раскрытия. Команды, использующие mutable-теги (debian:bookworm), незаметно для себя получили скомпрометированную библиотеку [10].

Red Hat: 42% команд говорят, что container security не даёт им спать

Согласно Red Hat 2024 State of Container Security Report, почти половина (42%) DevOps, engineering и security-команд признают, что container security — их главная боль [11]. И при этом именно Dockerfile часто генерируется AI "за один промпт" — без осознания долгосрочных последствий для безопасности образа.

Правильный паттерн, который AI редко предлагает по умолчанию — использование BuildKit secret mounts:

# Правильно: секрет используется только в памяти при сборке
RUN --mount=type=secret,id=api_token \
    cat /run/secrets/api_token | pip install --extra-index-url ...

Часть 3. Terraform: когда автоматизация тиражирует ошибку

IaC-специфика: одна строка → вся инфраструктура

Infrastructure as Code изменил модель угроз кардинально. Если раньше мисконфигурация была ошибкой конкретного инженера в конкретном AWS-аккаунте, то теперь небезопасный дефолт в Terraform-модуле автоматически распространяется на все окружения, которые этот модуль используют.

Gartner прогнозирует, что через 2027 год 99% облачных security failures будут вызваны ошибками клиента — прежде всего мисконфигурацией [12]. Статистика подтверждается реальными инцидентами: Capital One (2019) — 106 миллионов записей клиентов из-за misconfigured WAF role с избыточным доступом к S3; Microsoft (2023) — 38 TB внутренних данных из-за misconfigured Azure storage account [12].

Индустриальные аналитики в 2025 году предупреждали, что 75% security failures к концу года будут связаны с IaC-ошибками [13].

Что AI пишет в Terraform — и где это ломается

Cloud Magazine документировал системную проблему: AI-ассистенты "генерируют синтаксически корректный HCL, который проходит линтинг — но тихо применяет небезопасные дефолты, которые reviewer пропускает" [14].

Конкретные паттерны, которые воспроизводит AI:

• IAM-политики с правами : — потому что в обучающих данных это встречается как "быстрое решение" для разработки;
• S3-бакеты без block_public_access = true — дефолт в старых версиях provider'а был публичным;
• security groups с cidr_blocks = ["0.0.0.0/0"] — для входящего трафика на порты 22 или 3306;
• Terraform state files, хранящиеся локально без encryption — секреты в .tfstate хранятся в открытом виде;
• использование непроверенных сторонних модулей из Terraform Registry без pinning версии.

Исследование TerraDS, проанализировавшее 62 406 GitHub-репозиториев с Terraform-конфигурациями, подтвердило: human-written configurations "часто содержат критические security vulnerabilities" — что делает AI-воспроизведение этих паттернов предсказуемо опасным [15].

Ещё один документированный риск — "Comprehension Gap": когда команды делегируют IaC-разработку AI, они постепенно теряют ментальную модель того, что реально задеплоено. Автономный AI-агент, исправляющий "drift", может перезаписать вручную применённый emergency patch — это задокументированный production risk [14].

Часть 4. Миграции баз данных: необратимость как вектор риска

Почему миграции — особый случай

Миграции базы данных обладают уникальным свойством, которое делает их принципиально отличными от остального кода: многие операции необратимы в production без предварительного backup или специальной подготовки.

DROP COLUMN, DROP TABLE, TRUNCATE, изменение типа данных с потерей информации, удаление индекса в high-load системе без CONCURRENTLY — всё это может вызвать потерю данных, даунтайм или нарушение целостности, которые невозможно "откатить" обычным git revert.

Согласно опросу 2025 года, 1 из 5 enterprise-компаний сталкивается хотя бы с одной проблемой целостности данных при крупных миграциях [16].

Паттерны ошибок в AI-сгенерированных миграциях

AI-ассистенты работают с миграциями как с обычным SQL. Они не знают о production-специфике:

• генерируют DROP COLUMN без проверки того, что приложение уже не читает эту колонку (Blue-Green deployment проблема);
• создают индексы без CONCURRENTLY в PostgreSQL — что вызывает table lock и даунтайм;
• пишут data migrations (преобразование данных) внутри schema migration, что может привести к timeout на больших таблицах;
• не добавляют rollback-секцию или пишут её формально, без понимания того, что она должна полностью отменить forward-миграцию.

Дополнительный риск, который выявили исследователи — text-to-SQL системы с LLM открывают новый класс уязвимостей. Schema inference attacks позволяют извлечь структуру базы данных из SQL-ответов модели, раскрывая внутреннюю архитектуру данных конкурентам или атакующим [17].

Почему это читают хуже всего

Файл миграции выглядит безобидно: несколько SQL-строк. Reviewer, который устал от большого PR, пробегает его глазами — видит привычные команды — и одобряет. Контекст — что эта операция будет выполнена в production на таблице с 50 миллионами строк в пятницу вечером — не виден из файла.

Часть 5. Internal tools и deploy scripts: "технический долг с привилегиями"

Невидимая зона риска

Internal tools — скрипты деплоя, CLI-утилиты для DBA, скрипты ротации секретов, боты для мониторинга — пишутся быстро, часто AI-ассистентом, и практически не проходят security review. AppSecEngineer зафиксировал [18]: "В большинстве команд этот код оказывается в automation scripts, internal tools, API glue layers и IaC — областях, которые редко получают такой же security scrutiny, как production services".

При этом именно internal tools часто работают с admin-credentials, имеют доступ к production-базам и cloud-аккаунтам, и хранятся в репозиториях с менее строгими branch protection правилами.

Конкретные паттерны, которые AI воспроизводит в internal tools:

• IAM-политики с : permissions — "потому что так быстрее работает в dev";
• Lambda-функции с hardcoded secrets или без input validation;
• API endpoints без аутентификации — "это же внутренний инструмент";
• широкий CORS (*) для "удобства".

Shadow agents как новый Shadow IT

Dark Reading в конце 2025 зафиксировал новый феномен [19]: "Shadow agents — это новый shadow IT. Если вы не знаете, какие инструменты и MCP-серверы используют разработчики, как вы собираетесь их защищать?" MCP-серверы, встроенные в codebases в highly regulated environments — не гипотетический сценарий, а реально наблюдаемая практика.

GitGuardian в своём отчёте 2026 зафиксировал [20]: 59% скомпрометированных машин в атаке Shai-Hulud 2 были CI/CD runner-ами, а не personal developer laptops. AI-assisted commits в 2025 году содержали secrets в 2 раза чаще базового уровня — 3,2% против 1,5% для всех публичных коммитов GitHub.

Почему это не замечают: системная проблема ревью

OX Security проанализировал более 300 репозиториев, включая 50 с AI-coding tools [21]. Вывод неожиданный: "AI-сгенерированный код не более уязвим на строку, чем написанный человеком. Проблема — в скорости. Bottlenecks — code review, debugging, team-based oversight — были убраны".

Это ключевое наблюдение. Проблема не только в качестве AI-кода — проблема в том, что review не успевает за velocity. И когда 80 строк workflow-файла генерируются за 5 секунд, reviewer физически не успевает провести тот же анализ, что он делал бы за час ручной работы.

AppSecEngineer формулирует точно [18]: "Ваша команда не может сказать вам, где живёт AI-сгенерированный код, кто его владелец и как он ревьюируется — это уже blind spot. И по мере того, как всё больше dev-команд принимают GenAI, этот blind spot будет расти".

Модель с одинаковыми blind spots не может их детектировать: "Если одна модель генерирует код, а та же модель его ревьюирует — ревью не поймает систематические слепые пятна, потому что reviewer разделяет их с генератором" [22].

Практический чек-лист: что проверять до merge

CI/CD workflow-файлы

1. Триггер: нет ли pull_request_target с checkout кода из PR и доступом к секретам?
2. Permissions: явно ли ограничены (contents: read, packages: write — только необходимое)?
3. Third-party actions: закреплены ли по commit SHA (uses: action/checkout@abc123ef...), а не по тегу?
4. Интерполяция: нет ли ${{ github.event.*.title }} или аналогов в run: шагах без sanitization?
5. Секреты: не передаются ли через env: в шелл-команды, где могут утечь в логи?
6. Audit: нет ли прав на изменение workflow-файлов у внешних контрибьюторов?

Dockerfile

1. Base image: закреплён ли по digest (sha256:...), а не по mutable тегу?
2. Секреты: нет ли значений в ENV или --build-arg (проверяется через docker history)?
3. Пользователь: есть ли директива USER nonroot перед CMD/ENTRYPOINT?
4. Multi-stage: отделены ли build-зависимости от runtime-образа?
5. BuildKit secrets: используется ли --mount=type=secret для секретов при сборке?
6. Сканирование: проходит ли образ через Trivy или аналог в CI до push в registry?

Terraform

1. IAM: нет ли : в политиках? Есть ли explicit deny для критичных операций?
2. S3: включён ли block_public_access? Есть ли encryption at rest?
3. Security groups: нет ли 0.0.0.0/0 для входящего трафика на служебные порты?
4. State: хранится ли remote state с encryption? Есть ли access control на state bucket?
5. Modules: pinned ли версии сторонних модулей? Проверен ли их источник?
6. Drift: настроен ли мониторинг расхождения между state и реальной инфраструктурой?

Миграции баз данных

1. Необратимость: есть ли rollback-секция, которая реально отменяет forward?
2. Объём: для больших таблиц — есть ли CONCURRENTLY для индексов, батчинг для UPDATE?
3. Зависимости: готово ли приложение к изменению схемы (Blue-Green совместимость)?
4. Backup: подтверждён ли backup до запуска миграции в production?
5. Тестирование: прогонялась ли миграция на копии production-данных, а не только на dev?
6. Мониторинг: настроен ли алерт на время выполнения миграции и lock timeout?

Internal tools и deploy scripts

1. Credentials: нет ли hardcoded secrets, токенов, паролей?
2. Принцип минимальных привилегий: достаточно ли ограничены IAM/RBAC права?
3. Input validation: проверяются ли входные параметры перед передачей в шелл-команды?
4. Аутентификация: требуется ли auth для внутренних API?
5. Аудит: логируются ли действия с указанием инициатора?
6. Ревью: проходят ли эти файлы тот же security review, что и production code?

Ошибки и anti-patterns

Несколько устойчивых заблуждений, которые увеличивают риск:

"Это внутренний инструмент, его никто не атакует" — ложная посылка. Internal tools часто имеют production-доступ и хранятся в репозиториях с более слабой защитой.

"AI сгенерировал — значит, это best practice" — нет. Модели тренируются на публичном коде, который включает небезопасные паттерны, устаревшие примеры и copy-paste из StackOverflow 2017 года.

"SAST нашёл ноль — значит, безопасно" — SAST и SCA не покрывают конфигурационные ошибки в workflow-файлах, Terraform-мисконфигурации, проблемы доступа в Dockerfile и необратимые операции в миграциях. Aikido прямо указывает [23]: "zero CVE scan result does not mean the image is secure".

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

Тренды: что изменится в ближайшие 12–18 месяцев

Несколько направлений заслуживают отдельного внимания.

AI-агенты в CI/CD — уже реальность. StepSecurity документировал [8]: GitHub Next's Continuous AI — видение, где AI-агенты становятся интегральной частью всего SDLC. Это увеличивает поверхность атаки нелинейно: агент с GITHUB_TOKEN и cloud credentials, который действует автономно — это принципиально другой threat model.

Prompt injection в CI-контексте. Исследователи Aikido (2025) описали новый класс уязвимостей — PromptPwnd [4]: атаки на AI-агентов, подключённых к GitHub Actions, через prompt injection в issue title или PR description. Агент выполняет privileged tools с правами CI-runner.

Регуляторное давление растёт. CISA уже выпускает экстренные алерты на supply chain атаки через CI/CD (CVE-2025-30066, CVE-2025-30154) [6]. Это сигнал: регуляторы рассматривают pipeline security как часть critical infrastructure.

AI bills of materials — следующий шаг. Dark Reading цитирует [19]: компании должны двигаться за SBOM к AI BOM — документированию конкретных AI-инструментов, одобренных для использования, с явным запретом на вещи вне этого списка.

Слой контроля там, где риск реально живёт

Ускорение разработки с AI — это данность. Задача не в том, чтобы замедлить команду, а в том, чтобы контроль успевал за velocity — особенно там, где риск максимален.

Бизнес-логика важна, но в ней риск локализован. Workflow-файл, Dockerfile, Terraform-модуль и скрипт миграции — это другая категория: один файл может дать атакующему ключи ко всей инфраструктуре, утечь тысячи секретов или уничтожить production-данные без возможности восстановления.

Именно на эти файлы стоит направить особое внимание при ревью — и именно их должен покрывать любой дополнительный слой контроля перед merge.

Инструменты вроде HighVibe появились как раз для этого сценария: анализировать конкретное изменение в workflow-файле, Dockerfile, IaC или миграции в контексте релиза — и давать команде короткий, понятный сигнал до merge, не заменяя SAST/SCA, а закрывая слепые пятна, которые те не видят. Рабочий PR не обязательно безопасен. Ошибка в служебном файле не менее критична, чем SQL-инъекция в бизнес-логике — просто она проявляется иначе и обнаруживается позже.

Следующий шаг: пройдитесь по чек-листу выше применительно к вашему последнему PR, который затрагивал workflow-файл или Terraform. Скорее всего, там найдётся как минимум один пункт, который стоит пересмотреть.

Источники

[1] OWASP — "Top 10 CI/CD Security Risks" — https://owasp.org/www-project-top-10-ci-cd-security-risks/

[2] Snyk — "Trivy GitHub Actions Supply Chain Compromise" — https://snyk.io/articles/trivy-github-actions-supply-chain-compromise/

[3] GitHub Blog — "Securing the open source supply chain across GitHub" — https://github.blog/security/supply-chain-security/securing-the-open-source-supply-chain-across-github/

[4] The Hacker News — "Researcher Uncovers 30+ Flaws in AI Coding Tools Enabling Data Theft and RCE Attacks" — https://thehackernews.com/2025/12/researchers-uncover-30-flaws-in-ai.html

[5] Palo Alto Unit 42 — "GitHub Actions Supply Chain Attack: tj-actions/changed-files Incident" — https://unit42.paloaltonetworks.com/github-actions-supply-chain-attack/

[6] CISA — "Supply Chain Compromise of Third-Party GitHub Action CVE-2025-30066" — https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-github-action-cve-2025-30066

[7] GitGuardian — "GhostAction Campaign: 3,325 Secrets Stolen Through Compromised GitHub Workflows" — https://blog.gitguardian.com/ghostaction-campaign-3-325-secrets-stolen/

[8] StepSecurity — "When AI Meets CI/CD: Coding Agents in GitHub Actions Pose Hidden Security Risks" — https://www.stepsecurity.io/blog/when-ai-meets-ci-cd-coding-agents-in-github-actions-pose-hidden-security-risks

[9] Xygeni — "Dockerfile Secrets: Why Layers Keep Your Data Forever" — https://xygeni.io/blog/dockerfile-secrets-why-layers-keep-your-sensitive-data-forever/

[10] TechSaaS — "Docker Container Security Best Practices in 2026" — https://www.techsaas.cloud/blog/docker-container-security-best-practices-2026/

[11] Aikido — "9 Common Docker Container Security Vulnerabilities & Fixes" — https://www.aikido.dev/blog/docker-container-security-vulnerabilities

[12] DEV Community — "IaC Security in 2026: Terraform, Checkov, and Cloud Drift Detection" — https://dev.to/matheus_releaserun/iac-security-in-2026-terraform-checkov-and-cloud-drift-detection-5n

[13] Medium / InstaTunnel — "Terraform Nightmares: How a Misconfigured IaC Can Expose Everything" — https://medium.com/@instatunnel/terraform-nightmares-how-a-misconfigured-iac-can-expose-everything-09c4206864dd

[14] Cloud Magazin — "AI-Generated Terraform Code Is the Cloud Stack's Biggest Unspoken Risk" — https://www.cloudmagazin.com/en/2026/04/02/ai-generated-terraform-code-is-the-cloud-stacks-biggest-unspoken-risk/

[15] arXiv — "TerraFormer: Automated Infrastructure-as-Code with LLMs Fine-Tuned via Policy-Guided Verifier Feedback" — https://arxiv.org/html/2601.08734

[16] ITConvergence — "Cloud Migration Risks in 2025: Security and Compliance Challenges" — https://www.itconvergence.com/blog/cloud-migration-risks-in-2025-turning-compliance-and-security-challenges-into-resilience/

[17] arXiv — "Unmasking Database Vulnerabilities: Zero-Knowledge Schema Inference Attacks in Text-to-SQL Systems" — https://arxiv.org/pdf/2406.14545

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

[19] Dark Reading — "As Coders Adopt AI Agents, Security Pitfalls Lurk in 2026" — https://www.darkreading.com/application-security/coders-adopt-ai-agents-security-pitfalls-lurk-2026

[20] The Hacker News / GitGuardian — "The Real Problem Isn't That AI Can't Write Secure Code — It's That It's Expanding Attack Surface" — https://thehackernews.com/expert-insights/2026/03/the-real-problem-isnt-that-ai-cant.html

[21] Help Net Security — "AI writes code like a junior dev, and security is feeling it" — https://www.helpnetsecurity.com/2025/10/27/ai-code-security-risks-report/

[22] War on the Rocks — "Your Defense Code Is Already AI-Generated. Now What?" — https://warontherocks.com/2026/03/your-defense-code-is-already-ai-generated-now-what/

[23] Aikido — "IaC Security Scanning for Terraform & Kubernetes" — https://www.aikido.dev/blog/iac-security-scanning-terraform-kubernetes-misconfigurations