ИИ-агент безопасности взломал Snowflake. История с Copilot была шумом.

В июне ИИ-агент проник во внутреннюю Jira Snowflake, и почти все вынесли в заголовок не ту часть истории. Первая версия говорила, что уязвимый код написал GitHub Copilot, получилась удобная притча о том, как один ИИ отравляет другой. Эта версия прожила несколько часов. Wiz в тот же день исправила собственное раскрытие, GitHub прямо оспаривает такую атрибуцию, а после коррекции остаётся история куда страннее и полезнее: автономный агент нашёл действующую уязвимость, написал эксплойт, сам отладил неудачную полезную нагрузку и добыл рабочие учётные данные от начала до конца, пока обычные сканеры на том же коде не увидели ничего. Вот на это действительно стоит потратить время.

Ключевые выводы - Red Agent от Wiz, автономный агент наступательной безопасности, нашёл инъекцию скрипта в рабочий процесс GitHub Actions публичного репозитория Snowflake snowflake-connector-net и эксплуатировал её, чтобы украсть токен Jira. Между обнаружением и эксфильтрацией учётных данных человек не касался клавиатуры. - Уязвимость появилась 18 июня 2026 года, а 23 июня её нашли, эксплуатировали и сообщили о ней, всё в рамках программы Snowflake на HackerOne. Snowflake исправила проблему в тот же день, а журналы аудита показывают, что Wiz была единственным участником, воспользовавшимся доступом в этот период. - Первоначальное утверждение, что ошибку написал Copilot, отозвали через несколько часов. Уязвимый шаблон находился в изменении, написанном человеком; документированный вклад Copilot Autofix относился к другому файлу, а метка соавтора появилась как артефакт squash-слияния. - GitHub Advanced Security просканировал ровно ту уязвимую ревизию и пропустил проблему. Сканер сопоставления шаблонов смотрел на тот же код, по которому рассуждал агент, и смысл понял только один из них. - Действительно агентная часть была узкой, но реальной: диагностика неудачного эксплойта и его переписывание. Всё остальное было хорошей автоматизацией с языковой моделью внутри.

Что произошло

Хронология, целиком по раскрытию Wiz и ответу Snowflake:

• 18 июня 2026 года. PR #1218 сливают в snowflakedb/snowflake-connector-net, публичный репозиторий .NET-коннектора Snowflake. Он переписывает рабочий процесс jira_issue.yml, который автоматически создаёт тикеты Jira, когда кто-то открывает задачу на GitHub. Изменение заменяет безопасный шаблон, где заголовок задачи передаётся через переменную окружения в jq --arg, на прямую интерполяцию заголовка в блок run: командной оболочки.

• 23 июня. Red Agent, автономный исследовательский агент безопасности Wiz, при сканировании организации Snowflake на GitHub в рамках программы вознаграждения за уязвимости компании на HackerOne помечает рабочий процесс как уязвимый для инъекции. Он строит эксплойт, запускает его, получает ошибку синтаксиса командной оболочки из-за собственной полезной нагрузки, диагностирует причину, переписывает полезную нагрузку и добивается успеха со второй попытки. Размещённый в Azure исполнитель GitHub Actions отправляет на приёмник Wiz закодированный в base64 API-токен Jira сервисной учётной записи. Wiz в тот же день сообщает о проблеме через HackerOne.

• 23 июня, в тот же день. Snowflake исправляет рабочий процесс, возвращая безопасный шаблон.

• 24 июня. Токен Jira отзывают и заменяют. Проверка журналов аудита Snowflake не находит за пятидневное окно доступа никого, кроме Wiz. Wiz сообщает, что удалила данные, полученные для демонстрации работоспособности.

• 17 августа. Wiz публикует разбор Gal Nagli, руководителя направления анализа поверхности угроз в Wiz Research, и в тот же день в 19:57 UTC обновляет его, уточняя, что Copilot был соавтором, проверявшим объединённый PR и не нашедшим проблемы, а был ли уязвимый фрагмент вообще создан с помощью ИИ, неизвестно.

Токен давал доступ на чтение к внутренней Jira Snowflake: инженерным проектам, материалам по соответствию требованиям безопасности и самой программе вознаграждения за уязвимости. Данные клиентов никто не затронул, а выпущенный коннектор уязвимость вообще не содержал.

23 июня 2026 года автономный Red Agent от Wiz нашёл и эксплуатировал инъекцию скрипта в рабочий процесс GitHub Actions репозитория snowflake-connector-net компании Snowflake, вынеся токен Jira с доступом на чтение к внутренним инженерным проектам, материалам по соответствию требованиям безопасности и вознаграждению за уязвимости, через пять дней после появления уязвимости и без участия человека, согласно раскрытию Wiz Research. Snowflake исправила проблему в тот же день и не обнаружила в журналах аудита доступа третьих сторон.

Цепочка разрешений, звено за звеном

Этот эксплойт очень наглядно показывает, сколько доверия незаметно сосредоточено в CI-конвейере. Проследим, до чего смог добраться один специально составленный заголовок задачи:

1. Триггер. Рабочий процесс запускался на issues: opened, то есть любой пользователь GitHub на планете мог запустить его, просто открыв задачу. Условная проверка, которая должна была ограничивать доступ, всегда давала true для событий открытия задачи, согласно техническому разбору.

2. Инъекция. Новый код выполнял TITLE=$(echo '${{ github.event.issue.title }}' | sed ...). GitHub разворачивает шаблон ${{ }} до запуска командной оболочки, поэтому экранирование через sed происходит слишком поздно. Одна одинарная кавычка в заголовке закрывает строку, а остаток заголовка выполняется как команды оболочки.

3. Среда. Теперь команды выполняются внутри исполнителя GitHub Actions, то есть на машине, где по определению много учётных данных. В данном случае там находился API-токен Jira сервисной учётной записи, потому что задача рабочего процесса и состояла в создании тикетов Jira.

4. Эксфильтрация. Полезная нагрузка кодировала токен в base64 и отправляла её на приёмник Wiz через внеполосный обратный вызов, поэтому в журналах рабочего процесса не появлялось ничего явно подозрительного.

5. Приз. Токен аутентифицировался во внутренней среде Atlassian Snowflake и давал доступ на чтение к инженерным проектам, материалам по соответствию требованиям безопасности и вознаграждению за уязвимости.

Каждое звено этой цепочки это обычная, разрешённая, скучная инфраструктура: публичный репозиторий, рабочий процесс, который делает свою работу, сервисная учётная запись с нужными ей правами. Уязвимость не была одной конкретной неверной настройкой. Она возникла из композиции. Радиус поражения рабочего процесса равен всему, до чего может дотянуться его исполнитель, а исполнитель обычно способен дотянуться дальше, чем помнит написавшая его команда. Это тот же аргумент, который я привожу, когда клиенты спрашивают об управлении агентами: вопрос не в том, что представляет собой агент, а в том, к чему он может прикоснуться.

Эксплойт соединил пять уровней легитимного доверия: неаутентифицированная задача GitHub запускал рабочий процесс, инъекция одинарной кавычки выходила из строки командной оболочки, среда исполнителя содержала токен сервисной учётной записи Jira, внеполосный обратный вызов выносил токен, а токен открывал доступ на чтение к внутренней Jira Snowflake. Разворачивание шаблонов GitHub происходит до экранирования командной оболочки, поэтому очистка приходила слишком поздно, согласно разбору Wiz.

Что здесь было агентным, а что нет

Здесь хочется быть точным, потому что фраза «ИИ-агент взломал Snowflake» провоцирует два ленивых прочтения: либо это просто сканер с более удачным маркетингом, либо Skynet вырвался наружу. Подробности не подтверждают ни одно.

Обычная автоматизация с моделью внутри. Сканирование и первичная маркировка. Модуль CI/CD в Red Agent обходит организации GitHub в поиске файлов рабочих процессов, где недоверенный ввод интерполируется в блоки run:. Это хорошо известный класс уязвимостей с узнаваемой формой, и хорошее статическое правило вполне могло бы пометить jira_issue.yml. Выбрать цель, прочитать рабочий процесс и решить, что его можно эксплуатировать, требует навыка, но это близко к тому, что Wiz уже продаёт как непрерывное управление поверхностью атаки.

Действительно агентная часть. Цикл эксплуатации. Первая полезная нагрузка агента использовала символ комментария, который сломал синтаксис командной оболочки, и атака провалилась. Агент прочитал полученную ошибку bash, понял, почему полезная нагрузка составлена неверно, переписал её так, чтобы корректно закрыть скрипт, и добился успеха со второй попытки. Затем он проверил, что украденный токен действительно работает с Jira Snowflake, и оценил, до чего этот токен позволяет добраться. Диагностировать новую ошибку времени выполнения в собственной атаке и самостоятельно адаптироваться без дополнительной подсказки это не сопоставление сигнатур. Цикл попытка, наблюдение, исправление и есть то, что отличает агента от сканера. Тот же цикл я в более общем виде разбирал в агентной архитектуре. Увидеть, как он автономно работает в наступательном режиме против компании Fortune 500, удалось впервые, и это стоит отметить.

Вообще не работа агента. Область действия, этика и раскрытие. Red Agent работал внутри программы Snowflake на HackerOne, в песочнице, которую человек в Wiz выбрал и разрешил использовать. Автономность была настоящей, но ограниченной, санкционированной и наблюдаемой. Именно это я бы особенно подчеркнул для защитников. Wiz запустила Red Agent в марте и сделала его общедоступным в конце июля; продукт частично построен на Claude Opus от Anthropic. Теперь такую возможность может арендовать любая команда безопасности, поэтому наступательная версия этого цикла скоро станет очень распространённой.

Сканирование и триаж Red Agent были автоматизацией с моделью внутри; агентным ядром стал цикл эксплуатации: когда первая полезная нагрузка дала ошибку синтаксиса командной оболочки, агент диагностировал сбой bash, переписал полезную нагрузку и добился успеха со второй попытки, затем проверил токен и определил радиус его доступа, всё без помощи человека, согласно раскрытию Wiz.

Строка с Copilot здесь наименее интересна

Первые заголовки говорили, что ошибку написал Copilot. Данные говорят другое. Документированный вклад Copilot Autofix в PR #1218 был отдельным исправлением другого файла, jira_close.yml. Уязвимая интерполяция находилась в коммите, приписанном конкретному инженеру Snowflake, а GitHub сообщил журналистам, что внутренняя проверка показала: Copilot Autofix эти строки не писал и не рецензировал. Метка «соавтором значился Copilot» на объединённом PR была артефактом squash-слияния, который протащил служебную строку вместе с остальным. Wiz исправила публикацию в тот же день; The Register исправил свою статью. Самый полезный вывод прозвучал в комментарии CTO Wiz Ami Luttwak для CSO: когда на каждом PR работают несколько агентов, «просто смотреть на соавторов PR недостаточно», чтобы установить, кто что написал.

Одновременно могут быть верны две вещи. GitHub Advanced Security, использующий Copilot Autofix, просканировал финальную ревизию этого PR, включая уязвимый рабочий процесс, и не отметил инъекцию; это указано в описании Wiz, и GitHub с этим не спорил. При этом конкретное утверждение, что уязвимость написал Copilot, не подтверждается. Ревью с помощью ИИ пропустило критическую ошибку в коде, который признало нормальным. Это настоящая история об ограничениях ИИ-ревью. Просто это не история о том, что ошибку написал ИИ, а смешивание двух тезисов никому не помогает решить, насколько доверять ИИ-ревью собственных PR.

Сначала Wiz создала впечатление, что Copilot помог написать уязвимый код, а в тот же день уточнила: документированный вклад Copilot Autofix относился к другому файлу в том же PR, а метка соавтора была артефактом squash-слияния. GitHub утверждает, что ошибочный рефакторинг написал инженер-человек и Copilot его не рецензировал. Неоспоримый факт другой: GitHub Advanced Security просканировал уязвимую ревизию и ничего не отметил, согласно обновлённой публикации Wiz и материалу CSO.

Что делать сейчас

Если в ваших GitHub Actions есть хоть какие-то секреты, на этой неделе:

1. Поищите через grep ${{ github.event.* }} внутри блоков run: ваших рабочих процессов. Любая интерполяция заголовков задач, PR, имён веток или текстов комментариев прямо в командную оболочку допускает инъекцию, без оговорок. Перенесите значение в переменную env: и передавайте с корректным экранированием или разбирайте через jq --arg. Именно этот безопасный шаблон вернула Snowflake.

2. Считайте исполнителей хранилищами учётных данных. Ограничивайте токены рабочих процессов минимумом прав, предпочитайте короткоживущие учётные данные OIDC долговечным токенам сервисных аккаунтов и относитесь к любому рабочему процессу, запускаемому недоверенными событиями (issues, pull_request_target, комментарии), как к коду, доступному из интернета.

3. Не делайте ИИ-ревью последней линией защиты. Собственный сканер GitHub посмотрел на этот конкретный код и пропустил его. Наслаивайте проверки и с подозрением относитесь к рабочему процессу, где рецензирование, авторство и сканирование делегированы моделям одного поставщика.

4. Считайте пятидневное окно уже медленным. Агент прошёл путь от нулевого знания этого репозитория до рабочих учётных данных меньше чем за неделю. Если процесс раскрытия у вас предполагает месяцы присутствия атакующего до обнаружения, пора менять предположение и иметь инструкцию ротации учётных данных, которую можно выполнить в тот же день, как это сделала Snowflake.

Частые вопросы

GitHub Copilot написал уязвимость Snowflake?

По имеющимся данным, нет. Copilot Autofix значился соавтором объединённого PR, но его документированное изменение относилось к другому файлу, метка появилась из-за squash-слияния, а GitHub утверждает, что уязвимый код написал инженер-человек. Что подтверждается: GitHub Advanced Security просканировал уязвимую ревизию и пропустил инъекцию.

Как агент Wiz попал во внутреннюю Jira Snowflake?

Он нашёл рабочий процесс, который напрямую интерполировал заголовки задач в скрипт командной оболочки. Открытие задачи со специально составленным заголовком запускало произвольные команды на исполнителе, где хранился токен сервисной учётной записи Jira. Агент вынес токен через внеполосный обратный вызов и использовал его для чтения внутренних проектов Jira. Snowflake исправила рабочий процесс в день сообщения, а на следующий день заменила токен.

Это была настоящая атака?

Санкционированная. Red Agent работал в рамках программы вознаграждения за уязвимости Snowflake на HackerOne, Wiz сразу раскрыла результат, а журналы аудита Snowflake подтвердили, что за пять дней существования уязвимости Wiz была единственной стороной, использовавшей доступ. Данные клиентов не затрагивались. Но для несанкционированного агента тот же приём работает совершенно так же, и в этом весь смысл.

Что это означает для ИИ-агентов безопасности?

Что наступательные агенты сейчас впереди защитных. Автономный агент нашёл, эксплуатировал и оценил реальную уязвимость через несколько дней после её появления, тогда как автоматический сканер того же кода не увидел ничего. Защитникам стоит считать скорость обнаружения агентами новой базовой нормой и исходить из того, что всё, что можно запустить из интернета, будут проверять именно с такой скоростью.

Итог

Если убрать драму вокруг Copilot, остаются два факта. Обычный дорогой сканер безопасности проверил этот код и признал его чистым. Автономный агент прочитал тот же код, понял его достаточно глубоко, чтобы превратить в оружие, и по ходу сам исправил собственные ошибки. Пять дней между «слито» и «эксплуатировано машиной»: вот цифра, на которую должны смотреть команды безопасности, потому что наступательные агенты теперь продукт, а не исследовательская демонстрация, и выходных у них нет. Через месяц спор об атрибуции Copilot забудут. Возможность останется.

Если вы решаете, сколько автономности давать наступательным или защитным агентам внутри собственных конвейеров, я регулярно обсуждаю это с клиентами. Свяжитесь со мной.

Источники

• Wiz Research (Gal Nagli), «Wiz Red Agent проникает во внутреннюю Jira Snowflake через ошибку в PR с участием GitHub Copilot»: https://www.wiz.io/blog/red-agent-snowflake-copilot-cicd-bug (опубликовано 17.08.2026, обновлено 17.08.2026 в 19:57 UTC, получено 29.08.2026)

• Wiz, «Представляем Wiz Red Agent, ИИ-агента для наступательных атак»: https://www.wiz.io/blog/introducing-the-wiz-red-agent (опубликовано 23.03.2026, получено 29.08.2026)

• Cybersecurity News, «ИИ-агент взламывает рабочий процесс Snowflake на GitHub»: https://cybersecuritynews.com/ai-agent-hacks-snowflake-github-workflow/ (опубликовано 20.08.2026, получено 29.08.2026)

• CSO Online, «Уязвимость Snowflake проходит мимо ИИ-проверок и эксплуатируется другим ИИ»: https://www.csoonline.com/article/4211501/snowflake-flaw-slips-past-ai-checks-gets-exploited-by-another-ai.html (опубликовано 19.08.2026, получено 29.08.2026)

• Infosecurity Magazine, «ИИ-агент Wiz находит критическую ошибку в репозитории Snowflake на GitHub»: https://www.infosecurity-magazine.com/news/wiz-ai-agent-finds-snowflake/ (опубликовано 18.08.2026, получено 29.08.2026)

• daily.dev (из The Next Web), «GitHub оспаривает утверждение Wiz, что Copilot Autofix написал уязвимость Snowflake»: https://daily.dev/posts/github-disputes-wiz-s-claim-that-copilot-autofix-wrote-a-snowflake-flaw-ybruxnh95 (опубликовано 18.08.2026, получено 29.08.2026)

• Репозиторий snowflakedb/snowflake-connector-net: https://github.com/snowflakedb/snowflake-connector-net (получено 29.08.2026)