--- service: "Publicasta" schema_version: "1.0" article_id: 347 title: "Урок Snowflake о GitHub Actions: когда публичный issue становится входом в CI/CD" language: "ru" default_language: "en" canonical_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=ru" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=ru" api_url: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles/snowflake_github_actions_red_agent_cicd_secrets?lang=ru" channel_url: "https://publicasta.com/api/public/v1/channels/cybersecurity" channel_articles: "https://publicasta.com/api/public/v1/channels/cybersecurity/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-08-18T07:10:48+00:00" updated_at: "2026-08-18T07:10:48+00:00" translations: - language: "ar" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=ar" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=ar" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=ar" - language: "de" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=de" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=de" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=de" - language: "en" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=en" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=en" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=en" - language: "es" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=es" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=es" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=es" - language: "fr" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=fr" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=fr" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=pl" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=pl" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=ru" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=ru" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets?lang=zh" markdown_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.md?lang=zh" json_url: "https://publicasta.com/cybersecurity/snowflake_github_actions_red_agent_cicd_secrets.json?lang=zh" --- # Урок Snowflake о GitHub Actions: когда публичный issue становится входом в CI/CD > Кейс Wiz Red Agent не доказывает взлом клиентов Snowflake. Это спокойное предупреждение: публичные события репозитория, YAML-автоматизация и долгоживущие внутренние токены требуют контроля как production-код. Кейс Wiz и Snowflake не стоит читать как новую утечку клиентских данных и не стоит превращать в панику про AI-инструменты. Практический урок уже: публичный GitHub issue может стать входом для корпоративной автоматизации, а если этот ввод напрямую попадает в shell-команду внутри GitHub Actions, он перестаёт быть просто текстом. Wiz Research сообщает, что автономный инструмент Red Agent нашёл workflow injection в публичном репозитории `snowflakedb/snowflake-connector-net`, открыл специально сформированный issue, получил callback от GitHub Actions runner и добрался до Jira API token. Snowflake после disclosure исправила workflow, rotated token и, по опубликованным материалам, не нашла признаков несанкционированного доступа за пределами авторизованного research. ![Нейтральная схема: публичный GitHub issue попадает в CI workflow и к заблокированному внутреннему Jira token](https://publicasta.com/storage/projects/9/pages/347/2026/08/2ecdf05a-81f4-48bc-a6c8-c253ba05059a.webp) ## Что произошло В основе истории — обычная автоматизация. Публичный репозиторий связывал GitHub issues с внутренними Jira-процессами через GitHub Actions. Такое glue code встречается повсюду: новый баг может создавать тикет, менять label, отправлять сообщение в Slack или синхронизировать статус. Риск возникает, когда workflow воспринимает пользовательский текст как доверенный. Заголовок issue, body, branch name, PR title, comment и label в публичном проекте часто контролируются внешним человеком. Wiz пишет, что Red Agent просканировал публичную GitHub-организацию Snowflake и нашёл script injection в `.github/workflows/jira_issue.yml`. Workflow срабатывал на `issues: opened`. По описанию Wiz, attacker-controlled issue title вставлялся прямо в shell `run:` block. Первая попытка дала bash syntax error, после чего агент изменил payload и получил out-of-band callback от runner с base64-encoded credentials. Извлечённый Jira API token, по словам Wiz, аутентифицировался как `qa@snowflake.net` в Atlassian tenant Snowflake и давал read access к инженерным, security compliance и bug bounty tracking проектам. Timeline важен. Изменение workflow было merged в PR #1218, “SNOW-2069227 : Update jira workflows”, 18 июня 2026 года. Wiz сообщает, что Red Agent нашёл, проверил и сообщил проблему 23 июня. Fix PR #1402, “NO-SNOW adjust jira yml files”, был merged в тот же день, а token rotated 24 июня. Публичный разбор Wiz вышел 17 августа, The Hacker News написал о нём 18 августа и аккуратно уточнил scope: affected release Snowflake Connector for .NET не найден, публичного CVE или CISA KEV нет, публичных evidence of customer compromise тоже нет. ## Почему это важно сейчас История зацепила не из-за громкого имени Snowflake, а из-за скорости. AI code assistants уже стали частью обычной разработки. Автоматические security review, CodeQL-подобные проверки и vendor bots всё чаще стоят в pull-request gates. Одновременно autonomous security agents начинают искать публичный код, сопоставлять его с известными классами багов, пробовать путь эксплуатации, видеть ошибку и адаптироваться. Это не делает каждый AI-agent сверхзлоумышленником. Но это сокращает окно между ошибкой и рабочей демонстрацией. Раньше подобный YAML-баг мог лежать до случайного human review. Теперь агенты могут постоянно читать public repos и проверять старые классы уязвимостей в новых местах. Для защитников это полезно, если работа авторизована и раскрыта ответственно. Для компаний это неприятно, потому что тот же механизм быстрее обнаруживает secrets exposure. Вывод не в запрете Copilot и не в слепом доверии к нему. Нужна другая baseline: AI-reviewed code не становится безопасным только потому, что прошёл автоматическую проверку. Любой PR, который трогает `.github/workflows`, deployment scripts, cloud credentials, Jira tokens, release signing, package publishing или production secrets, должен считаться security-sensitive code. ## Workflow injection простыми словами Workflow injection начинается с простой границы. Данные остаются данными, пока система не превращает их в код. Public issue title — просто строка, пока GitHub хранит её как текст. Она становится опасной, если workflow разворачивает эту строку прямо внутри shell command. Символы, которые shell интерпретирует как управляющие, могут изменить действие runner. Безопасный pattern — не вставлять untrusted values в command text. Их кладут в environment variables, корректно quote, передают инструментам как данные и используют structured encoders вроде `jq --arg` при сборке JSON. GitHub Security Lab уже объяснял этот класс: значения из contexts, включая issue titles and branch names, нельзя бездумно раскрывать внутри `run:` blocks. Это не Snowflake-specific и не Jira-specific проблема. Она появляется везде, где YAML-автоматизация смешивает user-controlled metadata, shell execution and credentials. Статье не нужен реальный payload. Защита не требует копирования exploit string. Достаточно модели: если public event запускает workflow, а workflow имеет secrets, каждое поле этого события hostile by default. ## Public repos как attack surface Многие команды по-прежнему воспринимают публичный GitHub repo как место для кода и community. Но это ещё и front door для automation. New issue, pull request title, label change, comment or branch name могут запускать workflows на hosted or self-hosted runners. Эти workflows могут иметь tokens для Jira, Slack, package registries, cloud providers, test environments или release tooling. Поэтому событие `issues: opened` — не просто уведомление. Это untrusted input path из интернета в workflow. Если workflow использует internal service token, public repo фактически соединён с corporate infrastructure. Такое соединение может быть узким и законным, но оно должно быть inventoried and defended. Read-only tokens тоже чувствительны. Jira token с доступом к engineering, security compliance или bug bounty проектам может раскрывать vulnerability status, product roadmaps, triage comments, internal usernames и другие operational clues. Для настоящего атакующего это карта для phishing, social engineering, vulnerability chaining и выбора момента атаки. ## Где здесь AI AI-angle реален, но требует точности. Wiz сначала подчёркивал связь с GitHub Copilot-assisted PR и автономным Red Agent. Позже Wiz обновил текст: Copilot был co-author/checker within the merged PR and code change and marked it all-clear, но публичные данные не доказывают, что именно Copilot написал vulnerable lines. Это важная правка. Ответственный вывод не “Copilot сделал баг”. Вывод другой: AI assistance не предотвратил known class of CI/CD flaw. В истории PR видны GitHub Advanced Security context and automated checks, но нужное security property — не исполнять untrusted issue text in privileged workflow — не сохранилось. Автоматический review полезен, но это не proof of safety. С другой стороны, Red Agent показал, что autonomous defensive/offensive tooling уже умеет находить и проверять старые баги быстрее людей. Агенту не нужно изобретать новый класс уязвимости. Достаточно применить известный pattern к публичной автоматизации и довести проверку до observable result. ## Почему это не история о взломе клиентов Спокойная часть важна. Публичные материалы не показывают breach customer data. THN уточнил, что weakness confined to repository CI/CD automation, affected connector release не найден. Wiz пишет, что Snowflake по audit logs подтвердила: Wiz был sole actor during the exposure window, а Snowflake stated no evidence of unauthorized access. Token был rotated. Это не обнуляет серьёзность. Это задаёт scope. CI/CD secret exposure может быть важным даже тогда, когда его нашёл authorized researcher, компания быстро исправила проблему, а customer compromise не подтверждён. На таких ограниченных incidents и стоит учиться до того, как похожая цепочка попадёт к худшему актору. Не стоит смешивать этот случай с прежними Snowflake-related account compromises. Здесь речь о public connector repository workflow, internal Jira token and CI/CD automation. Большой narrative “Snowflake снова взломали” был бы неточным и вредным. ## Известный класс, который повторяется Workflow injection не exotic. GitHub Blog подробно писал, что attacker-controlled contexts нельзя разворачивать внутри shell. Правила известны: не подставлять issue titles and branch names directly in `run:`, осторожно использовать privileged triggers, сокращать permissions, не отдавать secrets untrusted events, treating workflow files as security-impact code. Класс повторяется потому, что CI/CD YAML часто считают “обвязкой”, а не software. Его быстро refactor, копируют snippets, соединяют API и проверяют reviewers, которые в основном смотрят application code. Workflow выглядит безобидно: нет web route, нет binary, нет obvious auth logic. На практике внутри могут быть Jira tokens, release keys, cloud credentials and package registry secrets. Если старый workflow использовал более безопасный pattern через `env:` and structured JSON handling, а после refactor intent потерялся, это не человеческая мелочь, а системный сигнал. Безопасный паттерн должен быть encoded as policy, tests, lint rules and code-owner review, а не держаться в памяти одного reviewer. ## Практический чек-лист Начните с inventory. Перечислите workflows в public and private repos, особенно trigger types: `issues`, `issue_comment`, `pull_request`, `pull_request_target`, `discussion`, `workflow_dispatch` with user input and repository dispatch. Для каждого workflow запишите, какие secrets он видит, какие external systems вызывает и где run происходит. Ищите прямое context expansion внутри `run:`. Подозрительны `${{ github.event.issue.title }}`, `${{ github.event.issue.body }}`, `${{ github.head_ref }}`, PR titles, comment bodies and branch names. Исправление — не “добавить кавычки где-нибудь”. Переносите input в environment variables, pass it as data, применяйте safe encoders, избегайте string concatenation при сборке JSON для Jira или Slack. Сокращайте credentials. Задавайте explicit workflow `permissions`. Не давайте write access там, где нужен read. Не храните long-lived Jira, Slack, registry and cloud tokens, если можно использовать OIDC, short-lived credentials or tightly scoped service accounts. Мониторьте вызовы из CI runners и alert on unusual calls. Разделяйте trust zones. Workflows, triggered by public events, не должны получать production-adjacent secrets. Если public issue должен создать Jira ticket, поставьте broker service, maintainer-approved label or manual gate before privileged automation. Для `pull_request_target` нужна отдельная осторожность, потому что он может работать в context of the base repository. Защитите workflow changes. Требуйте code-owner review для `.github/workflows/**`, release scripts and deployment helpers. Добавьте static checks, которые fail PR, если untrusted contexts появляются прямо в `run:`. Храните GitHub Actions logs, runner network logs and external-service audit logs достаточно долго, чтобы расследовать token use. ## Governance для AI-assisted изменений AI-generated or AI-reviewed changes должны проходить risk-based policy. Labels для AI-assisted commits помогают auditability, но сами по себе не защищают. Главное — если change touches CI/CD, identity, secrets, security policy, release automation or customer data paths, его проверяет человек, accountable for that area, плюс automated checks под конкретный тип файлов. Командам нужно трезво описывать роль AI. Copilot, Autofix, CodeQL and scanners уменьшают toil и находят много дефектов. Они не обещают, что каждый workflow edge case safe. Bot comment — не финальный security review. Autonomous defensive agents тоже требуют рамок: scope, rate limits, logging and disclosure rules. Они могут взаимодействовать с real systems, создавать callbacks and alerts. Bug bounty programs should define acceptable agent-driven testing and how exposed secrets are rotated after validation. ## Что сделать сегодня Проверьте workflows, которые слушают public repository events. Найдите untrusted GitHub context values inside shell commands. Уберите secrets из этих workflows или поместите privileged step behind maintainer approval. Rotate long-lived tokens. Сделайте `.github/workflows` code-owned directory. Добавьте лёгкий linter or regression test for workflow injection patterns. Главный вывод для руководителей: AI не отменяет AppSec basics, а ускоряет обе стороны. Время между vulnerable workflow merge and working proof может сократиться до days or hours. Спокойный ответ — считать CI/CD YAML production code with secrets. Public issues are user input. User input needs boundaries. Secrets need scopes. Automation needs owners.