Каковы основные риски при использовании GitHub Actions?

Основные риски включают уязвимости в конфигурациях и недостаточный контроль доступа.

Почему Dockerfile может быть опасен?

Dockerfile может содержать критические ошибки конфигурации, такие как запуск от root.

Как защитить свои CI/CD процессы?

Необходимо проводить тщательный код-ревью и ограничивать права токенов.

Что такое 'отравление пайплайна'?

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

Как AI влияет на безопасность кода?

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

Материал

GitHub Actions, Dockerfile, миграции и скрипты: невидимая зона риска в AI‑кодинге

Опубликовано: 27 апреля 2026 Время чтения: 18 мин

Пока ваш ревью сфокусирован на бизнес-логике, атаки приходят через .yml-файлы, Dockerfile и хелпер-скрипты, которые никто не дочитывает до конца

Где живёт настоящий риск

Когда разработчик открывает pull request, команда смотрит на бизнес-логику: новый эндпоинт, исправление бага, рефакторинг модели. Это понятно и привычно. Но в том же PR могут лежать изменения в .github/workflows/deploy.yml, новый Dockerfile, обновление requirements.txt или скрипт миграции — и на них смотрят значительно хуже.

AI-ассистенты усилили эту асимметрию. Они одинаково уверенно генерируют и бизнес-логику, и пайплайны, и конфигурации — но ревьюят их совсем не одинаково. По данным исследования Veracode 2025 года, проанализировавшего более 100 LLM на 80 задачах, только 55% AI-сгенерированного кода является безопасным [6]. И хуже всего дела обстоят именно с вспомогательным кодом: конфигурациями, скриптами и инфраструктурными файлами, где AI воспроизводит паттерны из обучающей выборки без понимания контекста безопасности.

Эта статья — о той части риска, которую команды системно недооценивают.

Часть 1. GitHub Actions как вектор атаки

Почему пайплайны так привлекательны для атакующих

CI/CD-системы — это, по определению OWASP Top 10 CI/CD Security Risks, «кратчайший путь к production и кратчайший путь для атакующего» [7]. Пайплайн работает с десятками секретов одновременно: токены облачных провайдеров, ключи к реестрам артефактов, SSH-ключи, PAT для SCM. При этом код в пайплайне зачастую выполняется автоматически, без человеческого ревью каждого запуска.

В марте 2025 года это стало реальностью в масштабах отрасли.

Инцидент tj-actions/changed-files: анатомия атаки

Атака на GitHub Action tj-actions/changed-files (CVE-2025-30066, CVSS 8.6) — один из наиболее детально задокументированных инцидентов в истории software supply chain [3]. По данным CISA, она затронула более 23 000 репозиториев [4].

Механика атаки выглядела так:

Атакующие получили доступ к GitHub Personal Access Token бота @tj-actions-bot, у которого были права записи в репозиторий.
Злоумышленники внедрили Base64-закодированный payload в код action'а и ретроактивно перезаписали существующие теги версий — так, чтобы все ссылки указывали на вредоносный коммит.
Payload при исполнении скачивал Python-скрипт, сканировал память GitHub Runner на наличие секретов и печатал их прямо в логи workflow.
В публичных репозиториях логи доступны любому — AWS Access Keys, npm-токены, RSA-ключи оказались в открытом доступе.

Примечательно, что атака началась ещё в ноябре 2024 года, но была обнаружена только в марте 2025 — спустя несколько месяцев [1]. Это иллюстрирует фундаментальную проблему: вредоносный код в пайплайне может работать незаметно долгое время, потому что логи раннеров читают значительно реже, чем код приложения.

Согласно исследованию Palo Alto Networks, атака восходила к компрометации reviewdog/action-setup, который в свою очередь использовался tj-actions/eslint-changed-files, а тот — конечным tj-actions/changed-files [1]. Это классическая цепочка транзитивных зависимостей в Actions: никто не проверял, что именно делает action в трёх уровнях вложенности.

В сентябре 2025 года кампания GhostAction показала ту же схему в большем масштабе: 327 скомпрометированных аккаунтов, 817 репозиториев, 3 325 похищенных секретов — PyPI-токены, npm-токены, DockerHub credentials, AWS-ключи [8].

Что AI делает с GitHub Actions

AI-ассистент, которому дают задачу «сделай workflow для деплоя», генерирует рабочий YAML-файл. Он будет правильно форматирован, будет запускаться при нужных событиях и делать именно то, о чём попросили. Но с высокой вероятностью он:

не ограничит разрешения токена (permissions: write-all вместо минимально необходимого),
использует action по тегу версии (@v3), а не по хешу коммита,
добавит pull_request_target там, где безопаснее pull_request,
разместит секрет прямо в переменной окружения вместо использования OIDC.

Согласно отчёту Legit Security 2024 года, 86% реальных GitHub Actions workflows не ограничивают права токена [9]. AI воспроизводит этот паттерн, потому что именно он преобладает в его обучающей выборке.

Атака CICD-SEC-4 («отравление пайплайна», Poisoned Pipeline Execution) по классификации OWASP — одна из самых распространённых в дикой природе [7]. Она эксплуатирует именно то, что модифицированный файл пайплайна или скрипт, на который он ссылается, выполняется без ревью человека.

Часть 2. Dockerfile: видимая конфигурация с невидимыми последствиями

Типовые ошибки, которые воспроизводит AI

Dockerfile — это инструкция по сборке окружения. Он влияет на runtime-безопасность каждого контейнера, попадающего в production. Но в процессе code review Dockerfile зачастую воспринимается как «просто конфигурация» и проходит мимо внимания.

AI генерирует Dockerfile с характерными паттернами безопасности, перечисленными ниже.

Запуск от root — наиболее распространённая проблема. Docker по умолчанию запускает контейнер от root, и AI воспроизводит это поведение, если явно не указать иное [10]. Согласно данным OWASP Docker Security Cheat Sheet, это одна из наиболее критичных мисконфигураций: процесс с правами root внутри контейнера при побеге из него получает права root на хосте [11].

Использование тега latest вместо конкретного дайджеста. Образ FROM python:latest сегодня и через три недели — это разный образ. AI систематически не закрепляет версии, что открывает путь к supply chain атакам через отравление базовых образов.

Hardcoded секреты в слоях образа. Даже если секрет удалён в следующем слое командой RUN, он сохраняется в истории образа (docker history). По данным SUSE, это одна из наиболее частых причин утечки credentials из контейнерных сред [12]. AI особенно склонен к этому паттерну, когда генерирует примеры интеграции с внешними сервисами.

Монтирование Docker socket. -v /var/run/docker.sock:/var/run/docker.sock — это фактически предоставление процессу внутри контейнера полного контроля над хостом. Patern встречается в AI-генерированных примерах CI-раннеров.

Минимальный размер образа без multi-stage build. AI часто генерирует однослойный Dockerfile с полным build-окружением в финальном образе: компиляторами, отладочными утилитами, лишними пакетами. Каждый лишний компонент — расширение attack surface.

DockerDash: когда AI стал частью вектора

В ноябре 2025 года Docker закрыл критическую уязвимость DockerDash (CVE, обнаруженная Noma Labs) в функции Ask Gordon — AI-ассистенте для Docker Desktop. Единственного вредоносного метадата-лейбла в образе было достаточно, чтобы через MCP Gateway выполнить произвольный код [13]. Этот инцидент показывает, что теперь небезопасным может оказаться и сам AI, встроенный в инструменты разработки.

Часть 3. Миграции баз данных: привилегированный код без ревью

Почему миграции особенно опасны

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

выполняются от имени привилегированного пользователя БД,
применяются к production-данным напрямую,
часто необратимы или трудно обратимы,
содержат DDL-операции (ALTER, DROP, TRUNCATE), которые могут уничтожить данные,
нередко включают DML для трансформации существующих записей.

При этом миграции традиционно меньше других артефактов покрыты инструментами статического анализа. SAST-инструменты настроены на анализ кода приложения, а не SQL-файлов и скриптов миграций.

Что AI генерирует в миграциях

Исследование SQ Magazine 2026 года зафиксировало, что SQL injection и XSS остаются наиболее частыми классами уязвимостей в AI-сгенерированном коде [14]. В контексте миграций это проявляется в нескольких паттернах.

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

Отсутствие транзакций и rollback-логики. AI генерирует миграцию как последовательность операций без явного BEGIN/COMMIT/ROLLBACK. При падении на середине операции данные оказываются в неконсистентном состоянии.

Избыточные права выполнения. Скрипт миграции, сгенерированный AI, нередко предполагает права суперпользователя БД, тогда как для его выполнения достаточно прав на конкретные таблицы.

Утечка данных через лог. AI-сгенерированные скрипты часто логируют промежуточные значения «для отладки» — включая PII или чувствительные поля, которые не должны появляться в логах.

Важно учитывать, что в марте 2026 года в LangGraph (фреймворк для AI-агентов) была обнаружена SQL-инъекция непосредственно в реализации SQLite checkpoint (CVE-2025-67644, CVSS 7.3), что позволяло читать конфигурационные файлы Docker и перехватывать секреты [15]. AI-инфраструктура сама по себе может содержать те же классы уязвимостей, что и генерируемый ею код.

Часть 4. Вспомогательные скрипты: зона наибольшей слепоты

deploy.sh, seed.py, cleanup.rb

Вспомогательные скрипты — это большая и разнородная категория: скрипты деплоя, утилиты для наполнения БД тестовыми данными, скрипты очистки, ротации ключей, отчётности, миграции данных между сервисами. Их объединяет несколько свойств:

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

AI особенно активно используется именно для таких задач — «напиши скрипт, который переместит данные из таблицы A в таблицу B» или «сделай скрипт деплоя для этого сервиса». И именно здесь AI наиболее склонен к характерным ошибкам:

hardcoded credentials («для примера, замените на своё»),
отсутствие валидации входных параметров,
слишком широкий CORS или отсутствующая аутентификация в отладочных эндпоинтах,
debug-режимы, включённые по умолчанию,
отсутствие обработки ошибок и частичное выполнение деструктивных операций.

Исследование Ravenna (декабрь 2025), протестировавшее пять vibe coding инструментов на 15 приложениях, обнаружило 69 уязвимостей, из которых шесть критических [16]. Примечательно, что большинство из них находились именно во вспомогательном коде — обработчиках, скриптах автоматизации, конфигурационных файлах.

Пример из практики: что находят в реальных PR

В декабре 2025 CodeRabbit проанализировал 470 open-source PR с AI-соавторством и зафиксировал: misconfigurations встречались на 75% чаще в AI-сгенерированном коде, чем в человеческом [17]. Это не только SQL-инъекции — это неправильно настроенные разрешения, лишние порты, открытые эндпоинты, избыточные права сервисных аккаунтов.

Разработчик из публикации DEV Community описывает типичный сценарий: junior-разработчик сдаёт модуль, код выглядит профессионально, хорошо прокомментирован. SAST-сканер находит hardcoded API-ключи в утилитной функции, SQL-запрос с конкатенацией внутри хелпера и JWT-валидацию, которая проверяет подпись, но не проверяет expiration. «О да, я вайбкодил этот модуль», — говорит разработчик [17].

Часть 5. Секреты: системная проблема

Масштаб

GitGuardian в своём отчёте 2026 года зафиксировал, что за 2025 год в публичных репозиториях GitHub появилось 28,65 млн новых hardcoded секретов — рост на 34% к предыдущему году [5]. GitHub в собственном отчёте насчитал 39 млн утечек секретов за 2024 год.

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

Влияние AI на эту статистику прямое и измеримое. GitGuardian обнаружил, что в репозиториях с активным Copilot частота утечки секретов составляет 6,4% против 4,6% в среднем — разница около 40% [5]. Причины понятны: AI оптимизирован для скорости, а не для безопасности обращения с credentials; он воспроизводит паттерны из обучающей выборки, где секреты нередко хардкодились «для примера»; разработчики принимают AI-предложения быстрее, чем проверяют их содержимое.

Особую роль играет категория CI/CD-секретов. Инцидент GhostAction в сентябре 2025 показал, что атакующие целенаправленно охотятся именно за ними: PyPI-токены позволяют публиковать зловредные пакеты, DockerHub credentials — подменять образы, AWS-ключи — получить доступ к инфраструктуре [8].

OIDC как структурное решение

Традиционная модель хранения статических секретов в GitHub Secrets принципиально уязвима: долгоживущие токены с широкими правами. Альтернатива — OIDC-федерация (OpenID Connect), при которой пайплайн получает краткосрочные credentials через AssumeRoleWithWebIdentity без хранения каких-либо ключей в репозитории. GitHub поддерживает эту схему для AWS, GCP, Azure [9]. AI-ассистент, генерирующий workflow, по умолчанию этого не знает и не применяет.

Часть 6. Почему вспомогательный код ревьюят хуже

Когнитивная экономия ревью

Ревью PR — когнитивно затратная задача. Когда в PR 500 строк бизнес-логики и ещё 80 строк YAML-пайплайна, человек неосознанно концентрирует внимание на том, что он понимает лучше. Конфигурационные файлы воспринимаются как «вторичные» — их смотрят быстрее, с меньшей критичностью.

Исследование показывает, что security review coverage на 20–30% ниже для AI-сгенерированного кода в целом [14]. Но этот разрыв многократно увеличивается для вспомогательного кода — потому что проблема усиливается привычками ревью, а не только природой AI.

Ложное чувство безопасности

Согласно данным Veracode 2025, 58% разработчиков доверяют AI-выводу без дополнительного тестирования [6]. Это означает, что красивый, хорошо структурированный Dockerfile или чистый YAML-файл пайплайна сигнализирует «здесь всё в порядке» — даже если внутри заложены системные проблемы безопасности.

AI не различает, насколько критичен тот или иной файл. Он генерирует .github/workflows/deploy.yml с той же уверенностью, с которой генерирует auth.py. Но reviewer воспринимают эти файлы совершенно по-разному.

Транзитивные зависимости никто не читает

Инцидент tj-actions показал, что атака прошла через три уровня транзитивных зависимостей между Actions. Команда, подключившая tj-actions/changed-files, не знала, что тот зависит от reviewdog/action-setup. Никто не ревьюит транзитивные зависимости Actions — так же, как никто не ревьюит транзитивные зависимости npm-пакетов до тех пор, пока не случится инцидент.

Часть 7. Чек-лист: что проверять до merge и релиза

GitHub Actions

Все ли Actions закреплены по SHA-хешу коммита, а не по тегу версии?
Установлены ли минимально необходимые permissions для каждого workflow?
Используется ли pull_request вместо pull_request_target там, где форк не должен получать доступ к секретам?
Нет ли в workflow секретов, переданных через переменные окружения, которые могут попасть в логи?
Настроен ли OIDC для доступа к облачным провайдерам вместо статических ключей?
Проверены ли транзитивные зависимости добавленных Actions?

Dockerfile

Запускается ли контейнер от non-root пользователя (директива USER)?
Закреплён ли базовый образ по дайджесту (sha256:...), а не по тегу?
Нет ли секретов в переменных окружения (ENV) или аргументах сборки (ARG)?
Используется ли multi-stage build для минимизации финального образа?
Нет ли монтирования Docker socket?
Включено ли сканирование образа на уязвимости в CI-пайплайне?

Миграции и скрипты

Используют ли SQL-запросы параметризацию, а не конкатенацию строк?
Обёрнуты ли деструктивные операции в транзакции с rollback-логикой?
Логируются ли чувствительные данные (PII, credentials) в процессе выполнения?
Соответствуют ли права выполнения принципу наименьших привилегий?
Есть ли у скрипта путь для безопасного прерывания при ошибке?

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

Ротировались ли секреты, если workflow мог быть скомпрометирован?
Нет ли новых hardcoded credentials в изменении (включая .env.example)?
Проверены ли новые зависимости — прямые и транзитивные?
Не появились ли в CI-логах значения, которые должны быть секретными?

Часть 8. HighVibe: контроль там, где ревью слабее всего

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

Именно для этого создан HighVibe — слой безопасности для команд, которые уже ускорили разработку с AI. Он анализирует конкретное изменение в PR: не только бизнес-логику, но и изменения в Dockerfile, .github/workflows/, скриптах миграций и служебных файлах. HighVibe обращает внимание на новые и обновлённые зависимости, на появление secrets-паттернов, на конфигурации с потенциально избыточными правами — и объясняет проблему простым языком, предлагая конкретный следующий шаг.

Ключевая логика: не тотальный аудит всей кодовой базы без повода, а анализ конкретного изменения и связанного контекста в момент, когда это ещё можно остановить — до merge и до релиза. Короткий и понятный сигнал вместо длинного отчёта, который никто не дочитает перед деплоем.

HighVibe не заменяет SAST, SCA и другие инструменты AppSec-стека — он работает как дополнительный слой контроля рядом с ними, фокусируясь на изменении, а не на общем состоянии репозитория.

Часть 9. Тренды: что будет усиливаться

Агентный AI и автономное выполнение

К 2025–2026 годам разработка сместилась от «AI предлагает — человек принимает» к «AI выполняет — человек проверяет результат». Claude Code, GitHub Copilot Workspace, Cursor Composer автономно модифицируют файлы, запускают команды, обновляют зависимости. По данным McKinsey (октябрь 2025), бизнес-лидеры активно внедряют agentic AI в процессы разработки [18].

В этой модели вспомогательный код генерируется ещё быстрее и ещё реже проходит внимательный ревью. Агент, которому дали задачу «сделай CI для нового сервиса», создаст весь pipeline-файл целиком — и вопрос в том, кто и как его проверит.

Shadow AI и citizen developers

76% организаций в 2026 году считают shadow AI серьёзной проблемой (рост с 61% в 2025 году). По оценке IBM, инциденты, связанные с shadow AI, увеличивают среднюю стоимость утечки данных примерно на $670 000 [19]. Разработчики используют свои личные аккаунты AI-инструментов даже после официального запрета в компании — а значит, неконтролируемый AI-сгенерированный код попадает в production без каких-либо проверок.

По данным Cycode, 25% стартапов из когорты Y Combinator Winter 2025 заявили о кодовой базе, сгенерированной на 95% с помощью AI [19]. Исследователи безопасности, проверившие около 5 600 vibe-кодированных приложений, обнаружили более 2 000 уязвимостей и более 400 открытых секретов.

Package hallucinations

Отдельная и недооценённая категория рисков — AI «галлюцинирует» несуществующие пакеты. Когда модель генерирует import some-nonexistent-package, атакующие могут зарегистрировать этот пакет в npm или PyPI с вредоносным содержимым — и дождаться, пока разработчики установят его по рекомендации AI. Этот вектор пока не имеет масштабной задокументированной атаки, но теоретически является прямым следствием того, как LLM работают с зависимостями.

Заключение

Опасность AI-кодинга редко живёт там, где её ищут. Бизнес-логика — это видимая часть PR, которую ревьюят с максимальным вниманием. Вспомогательный код — пайплайны, Dockerfile, миграции, деплой-скрипты — проходит мимо этого внимания.

Атаки на tj-actions, GhostAction и другие инциденты 2024–2025 годов показывают одну и ту же закономерность: компрометация происходит через инфраструктурный код, который никто не дочитывал до конца. AI ускорил производство этого кода, но не изменил культуру его ревью.

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

Ввести явные требования к ревью файлов пайплайнов, Dockerfile и служебных скриптов наравне с бизнес-логикой.
Применять к этим файлам те же инструменты статического анализа: hadolint для Dockerfile, actionlint для GitHub Actions, secrets-сканеры для всех изменений.
Перейти к OIDC-модели для CI/CD credentials там, где это возможно.
Закреплять Actions по SHA-хешу, а не по тегу версии.
Выстроить дополнительный слой контроля, который видит вспомогательный код в контексте релиза — не после него.

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

Источники

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

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

[3] GitHub Advisory Database — "CVE-2025-30066: tj-actions/changed-files supply chain compromise" — https://github.com/advisories/ghsa-mrrh-fwg8-r2c3

[4] CISA — "Supply Chain Compromise of Third-Party tj-actions/changed-files (CVE-2025-30066)" — https://www.cisa.gov/news-events/alerts/2025/03/18/supply-chain-compromise-third-party-tj-actionschanged-files-cve-2025-30066-and-reviewdogaction

[5] Snyk — "Why 28 million credentials leaked on GitHub in 2025, and what to do about it" — https://snyk.io/articles/state-of-secrets/

[6] Veracode / SCRAM — "2025 GenAI Code Security Report: AI Code Vulnerabilities" — https://scram-pra.org/veracode_genai_report.html

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

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

[9] Aembit — "Secretless Access for GitHub Actions and Workflows" — https://aembit.io/blog/secretless-access-for-github-actions/

[10] Snyk — "10 Docker Security Best Practices" — https://snyk.io/blog/10-docker-image-security-best-practices/

[11] OWASP — "Docker Security Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html

[12] SUSE — "Six Essential Docker Security Best Practices for Safe Containers" — https://www.suse.com/c/six-essential-docker-security-best-practices-for-safe-containers/

[13] The Hacker News — "Docker Fixes Critical Ask Gordon AI Flaw Allowing Code Execution via Image Metadata" — https://thehackernews.com/2026/02/docker-fixes-critical-ask-gordon-ai.html

[14] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026: Alarming Data" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[15] The Hacker News — "LangChain, LangGraph Flaws Expose Files, Secrets, Databases in Widely Used AI Frameworks" — https://thehackernews.com/2026/03/langchain-langgraph-flaws-expose-files.html

[16] Ravenna — "Vibe Coding Security Risks in IT Workflows 2026" — https://ravenna.ai/blog/vibe-coding-security-risks-it-workflows

[17] DEV Community / Orthogonal Thinking — "Vibe Coding Is a Security Nightmare: How to Fix It" — https://dev.to/orthogonalinfo/vibe-coding-is-a-security-nightmare-how-to-fix-it-2m37

[18] Tenable — "Security for AI: A guide to managing the risks of vibe coding and AI in software development" — https://www.tenable.com/blog/security-for-ai-guide-managing-vibe-coding-risks-ai-in-software-development

[19] Cycode — "Top AI Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/ai-security-vulnerabilities/

[20] OWASP — "CI/CD Security Cheat Sheet" — https://cheatsheetseries.owasp.org/cheatsheets/CI_CD_Security_Cheat_Sheet.html