Тригер issues: opened також не робив заголовок надійним. Будь-який користувач, який міг відкрити issue у публічному репозиторії, контролював його текст. Перевірка типу події обмежувала умови запуску workflow, але не перетворювала дані користувача на довірені й не блокувала їхню інтерполяцію в shell.

Яку роль відіграв Copilot Autofix

У squash-коміті Copilot Autofix powered by AI був зазначений як співавтор, а автоматизована перевірка не виявила небезпечної конструкції. Водночас наявні матеріали не встановлюють, чи Copilot згенерував цю зміну, чи лише був залучений до її перегляду або співавторства.

Тому точніше сказати, що Copilot був пов’язаний із комітом і не виявив ін’єкцію, а не стверджувати, ніби модель беззаперечно написала вразливий код.

Як Red Agent знайшов і використав недолік

Автономний інструмент Wiz Red Agent просканував публічну GitHub-організацію Snowflake на наявність небезпечних CI/CD-патернів. Він визначив, що jira_issue.yml використовує ненадійні дані issue всередині shell-блоку run:, і дійшов висновку, що спеціально сформований заголовок публічного issue може призвести до виконання довільних команд на runner GitHub Actions.

23 червня — лише через п’ять днів після злиття небезпечної зміни — агент відкрив підготовлений issue у межах програми Snowflake з розкриття вразливостей через HackerOne. Заголовок вийшов за межі передбаченого shell-рядка, після чого workflow передав облікові дані Jira на out-of-band callback, контрольований для авторизованої перевірки концепції.

Це був санкціонований тест безпеки, а не неконтрольоване проникнення. Але технічний висновок від цього не стає менш важливим: звичайне відкриття публічного issue давало змогу дістатися до кроку workflow, який працював із внутрішніми секретами, і перетворити користувацький текст на виконувані команди.

До чого отримали доступ

Уразливий workflow мав доступ до налаштувань внутрішньої Jira Snowflake — зокрема до URL Jira, електронної адреси користувача та API-токена. Отриманий токен був пов’язаний із qa@snowflake.net. Wiz використала його для автентифікації у внутрішньому порталі Jira та оцінки потенційного масштабу доступу.

За повідомленнями, токен дозволяв читати проєкти Jira, пов’язані з інженерною роботою, безпекою та відповідністю вимогам, а також активностями bug bounty. Водночас надані матеріали не містять повного переліку дозволів токена й не дають остаточного списку всіх записів, до яких можна було дістатися. Найобережніший підтверджений висновок полягає в тому, що токен відкривав доступ до чутливого внутрішнього вмісту Jira, але не свідчить про необмежений доступ до систем Snowflake.

Постраждалим активом була CI/CD-автоматизація репозиторію. Повідомлень про вразливу випущену версію Snowflake Connector for .NET не було, оскільки проблема містилася у workflow GitHub Actions, а не в коді, який виконується в самому конекторі.

Реакція Snowflake

Wiz повідомила про проблему 23 червня. Snowflake того ж дня виправила workflow, а наступного дня замінила відкритий Jira-токен.

Після цього компанія перевірила журнали аудиту й дійшла висновку, що протягом періоду експозиції єдиною активною стороною була Wiz. Wiz також заявила, що безпечно видалила дані, отримані під час proof-of-concept.

Про несанкціонований доступ третіх осіб, присвоєння CVE або постраждалий реліз конектора не повідомлялося. Ці обставини окреслюють підтверджений масштаб наслідків, але не виправдовують початковий дизайн workflow: заголовок публічного issue не мав ставати частиною shell-команди у процесі, який працював із внутрішніми обліковими даними.

Головний урок для CI/CD

Інцидент виходить за межі історії про Snowflake чи Copilot. Заголовки issue і pull request, назви гілок, коментарі та інші GitHub-вирази слід вважати потенційно шкідливими даними щоразу, коли вони потрапляють у shell-команду.

Безпечніший підхід передбачає:

• передавання ненадійних значень через змінні середовища, а не їхню пряму вставку в скрипти run:;
• використання структурованих інструментів на кшталт jq для створення JSON замість складання shell-рядків;
• коректне екранування та перевірку даних на межі взаємодії із shell;
• вилучення секретів із кроків, які обробляють дані, контрольовані користувачем;
• незалежну перевірку змін, створених ШІ, так само ретельно, як і коду, написаного людиною.

Цей випадок наочно показує нову проблему кібербезпеки: одна AI-система для допомоги в програмуванні може пропустити небезпечну зміну CI/CD, а автономний наступальний агент — знайти й підтвердити її наслідки за кілька днів. Автоматизація пришвидшує і виправлення, і експлуатацію вразливостей, але не замінює незалежного контролю.

Тригер issues: opened також не робив заголовок надійним. Будь-який користувач, який міг відкрити issue у публічному репозиторії, контролював його текст. Перевірка типу події обмежувала умови запуску workflow, але не перетворювала дані користувача на довірені й не блокувала їхню інтерполяцію в shell.

Яку роль відіграв Copilot Autofix

У squash-коміті Copilot Autofix powered by AI був зазначений як співавтор, а автоматизована перевірка не виявила небезпечної конструкції. Водночас наявні матеріали не встановлюють, чи Copilot згенерував цю зміну, чи лише був залучений до її перегляду або співавторства.

Тому точніше сказати, що Copilot був пов’язаний із комітом і не виявив ін’єкцію, а не стверджувати, ніби модель беззаперечно написала вразливий код.

Як Red Agent знайшов і використав недолік

Автономний інструмент Wiz Red Agent просканував публічну GitHub-організацію Snowflake на наявність небезпечних CI/CD-патернів. Він визначив, що jira_issue.yml використовує ненадійні дані issue всередині shell-блоку run:, і дійшов висновку, що спеціально сформований заголовок публічного issue може призвести до виконання довільних команд на runner GitHub Actions.

23 червня — лише через п’ять днів після злиття небезпечної зміни — агент відкрив підготовлений issue у межах програми Snowflake з розкриття вразливостей через HackerOne. Заголовок вийшов за межі передбаченого shell-рядка, після чого workflow передав облікові дані Jira на out-of-band callback, контрольований для авторизованої перевірки концепції.

Це був санкціонований тест безпеки, а не неконтрольоване проникнення. Але технічний висновок від цього не стає менш важливим: звичайне відкриття публічного issue давало змогу дістатися до кроку workflow, який працював із внутрішніми секретами, і перетворити користувацький текст на виконувані команди.

До чого отримали доступ

Уразливий workflow мав доступ до налаштувань внутрішньої Jira Snowflake — зокрема до URL Jira, електронної адреси користувача та API-токена. Отриманий токен був пов’язаний із qa@snowflake.net. Wiz використала його для автентифікації у внутрішньому порталі Jira та оцінки потенційного масштабу доступу.

За повідомленнями, токен дозволяв читати проєкти Jira, пов’язані з інженерною роботою, безпекою та відповідністю вимогам, а також активностями bug bounty. Водночас надані матеріали не містять повного переліку дозволів токена й не дають остаточного списку всіх записів, до яких можна було дістатися. Найобережніший підтверджений висновок полягає в тому, що токен відкривав доступ до чутливого внутрішнього вмісту Jira, але не свідчить про необмежений доступ до систем Snowflake.

Постраждалим активом була CI/CD-автоматизація репозиторію. Повідомлень про вразливу випущену версію Snowflake Connector for .NET не було, оскільки проблема містилася у workflow GitHub Actions, а не в коді, який виконується в самому конекторі.

Реакція Snowflake

Wiz повідомила про проблему 23 червня. Snowflake того ж дня виправила workflow, а наступного дня замінила відкритий Jira-токен.

Після цього компанія перевірила журнали аудиту й дійшла висновку, що протягом періоду експозиції єдиною активною стороною була Wiz. Wiz також заявила, що безпечно видалила дані, отримані під час proof-of-concept.

Про несанкціонований доступ третіх осіб, присвоєння CVE або постраждалий реліз конектора не повідомлялося. Ці обставини окреслюють підтверджений масштаб наслідків, але не виправдовують початковий дизайн workflow: заголовок публічного issue не мав ставати частиною shell-команди у процесі, який працював із внутрішніми обліковими даними.

Головний урок для CI/CD

Інцидент виходить за межі історії про Snowflake чи Copilot. Заголовки issue і pull request, назви гілок, коментарі та інші GitHub-вирази слід вважати потенційно шкідливими даними щоразу, коли вони потрапляють у shell-команду.

Безпечніший підхід передбачає:

• передавання ненадійних значень через змінні середовища, а не їхню пряму вставку в скрипти run:;
• використання структурованих інструментів на кшталт jq для створення JSON замість складання shell-рядків;
• коректне екранування та перевірку даних на межі взаємодії із shell;
• вилучення секретів із кроків, які обробляють дані, контрольовані користувачем;
• незалежну перевірку змін, створених ШІ, так само ретельно, як і коду, написаного людиною.

Цей випадок наочно показує нову проблему кібербезпеки: одна AI-система для допомоги в програмуванні може пропустити небезпечну зміну CI/CD, а автономний наступальний агент — знайти й підтвердити її наслідки за кілька днів. Автоматизація пришвидшує і виправлення, і експлуатацію вразливостей, але не замінює незалежного контролю.