Miało to kluczowe znaczenie. GitHub rozwija takie wyrażenie, zanim polecenie trafi do powłoki. Tytuł zawierający pojedynczy cudzysłów mógł więc zamknąć pierwotny łańcuch tekstowy i dodać własne polecenia. Późniejsze oczyszczanie wartości za pomocą sed nie mogło już cofnąć interpretacji, do której doszło wcześniej.

Workflow reagował na zdarzenie issues: opened, ale nie czyniło to tytułu zaufanym. Każdy użytkownik mogący otworzyć zgłoszenie w publicznym repozytorium mógł kontrolować jego treść. Sam warunek ograniczający workflow do aktywności związanej ze zgłoszeniami nie chronił przed wstrzyknięciem danych do polecenia powłoki.

Commit wskazywał „Copilot Autofix powered by AI” jako współautora, a wspomagany przez AI przegląd nie wykrył problemu. Nie ma jednak wystarczających dowodów, by stwierdzić, że Copilot wygenerował niebezpieczną zmianę albo że był jej autorem w ścisłym sensie. Najostrożniejszy wniosek brzmi: narzędzie było powiązane ze zmianą i nie wykryło w niej podatności.

Jak Red Agent znalazł i wykorzystał problem

Red Agent skanował publiczną organizację GitHub Snowflake’a pod kątem ryzykownych wzorców w potokach CI/CD. Zidentyfikował workflow Jira, w którym niezaufane dane ze zgłoszenia trafiały do bloku run:, i wywnioskował, że odpowiednio spreparowany tytuł publicznego zgłoszenia może doprowadzić do wykonania dowolnych poleceń na runnerze GitHub Actions.

23 czerwca — pięć dni po scaleniu podatnej zmiany — agent otworzył specjalnie przygotowane zgłoszenie w ramach programu ujawniania podatności HackerOne Snowflake’a. Tytuł wydostał się z łańcucha powłoki, a workflow wysłał dane uwierzytelniające Jira do kontrolowanego przez badaczy, pozapasmowego punktu zwrotnego (out-of-band callback), użytego w autoryzowanym dowodzie koncepcji.

Nie był to niekontrolowany włamanie, lecz usankcjonowany test bezpieczeństwa. Sama luka była jednak rzeczywista: każdy, kto mógł otworzyć publiczne zgłoszenie, mógł doprowadzić do wykonania poleceń w kroku workflow obsługującym dane uwierzytelniające.

Jaki dostęp uzyskano

Uruchomiony workflow miał dostęp do konfiguracji wewnętrznego Jira Snowflake’a, w tym adresu usługi, adresu e-mail użytkownika oraz tokena API. Odzyskany token był powiązany z kontem qa@snowflake.net. Wiz użył go do uwierzytelnienia w wewnętrznym portalu Jira i oceny potencjalnego zasięgu dostępu.

Z opisów wynika, że token zapewniał dostęp odczytu do projektów Jira związanych z inżynierią, zgodnością bezpieczeństwa oraz programem bug bounty. Dostępne materiały nie określają jednak pełnego zestawu uprawnień tokena ani nie zawierają kompletnej listy rekordów, które można było otworzyć. Najpewniejszy wniosek jest więc taki, że token umożliwiał dostęp do wrażliwych wewnętrznych treści Jira, a nie nieograniczony dostęp do systemów Snowflake’a.

Podatnym elementem była automatyzacja CI/CD repozytorium. Nie zgłoszono podatnej wydanej wersji Snowflake Connector for .NET, ponieważ problem znajdował się w workflow GitHub Actions, a nie w kodzie wykonywanym przez sam konektor.

Reakcja Snowflake’a

Wiz zgłosił problem 23 czerwca. Snowflake naprawił workflow tego samego dnia, a następnego dnia obrócił ujawnione dane uwierzytelniające Jira.

Firma przeanalizowała logi audytowe i ustaliła, że w czasie ekspozycji jedynym aktorem był Wiz. Wiz poinformował również, że bezpiecznie usunął dane wykorzystane w dowodzie koncepcji.

Nie zgłoszono nieautoryzowanego dostępu osób trzecich, nie przypisano podatności numeru CVE i nie wskazano żadnej podatnej wersji konektora. Te ograniczenia opisują potwierdzony wpływ incydentu, ale nie oznaczają, że pierwotny projekt workflow był bezpieczny. Tytuł publicznego zgłoszenia nie powinien trafiać bezpośrednio do polecenia powłoki w workflow, który korzysta z wewnętrznych danych uwierzytelniających.

Lekcja dla zespołów CI/CD

Przypadek Snowflake’a pokazuje problem szerszy niż samo Copilot Autofix. Tytuły zgłoszeń i pull requestów, nazwy gałęzi oraz komentarze należy traktować jako potencjalnie wrogie dane za każdym razem, gdy trafiają do polecenia powłoki.

Bezpieczniejszy projekt workflow obejmuje:

• przekazywanie niezaufanych wartości przez zmienne środowiskowe zamiast bezpośredniego wstawiania ich do skryptów run:;
• korzystanie z narzędzi strukturalnych, takich jak jq, do tworzenia JSON-a zamiast składania łańcuchów powłoki;
• odpowiednie cytowanie i walidowanie danych na granicy między workflow a powłoką;
• unikanie udostępniania danych uwierzytelniających krokom przetwarzającym treści kontrolowane przez użytkownika;
• sprawdzanie zmian wygenerowanych przez AI z taką samą starannością jak kod napisany przez człowieka.

To zwięzły przykład nowego wyścigu automatyzacji: jedno narzędzie AI może przeoczyć niebezpieczną zmianę w CI/CD, a autonomiczny agent ofensywny może znaleźć i zweryfikować ją w ciągu kilku dni. Automatyzacja przyspiesza zarówno wykrywanie i naprawę luk, jak i ich wykorzystanie — nie zastępuje jednak niezależnego przeglądu bezpieczeństwa.

Miało to kluczowe znaczenie. GitHub rozwija takie wyrażenie, zanim polecenie trafi do powłoki. Tytuł zawierający pojedynczy cudzysłów mógł więc zamknąć pierwotny łańcuch tekstowy i dodać własne polecenia. Późniejsze oczyszczanie wartości za pomocą sed nie mogło już cofnąć interpretacji, do której doszło wcześniej.

Workflow reagował na zdarzenie issues: opened, ale nie czyniło to tytułu zaufanym. Każdy użytkownik mogący otworzyć zgłoszenie w publicznym repozytorium mógł kontrolować jego treść. Sam warunek ograniczający workflow do aktywności związanej ze zgłoszeniami nie chronił przed wstrzyknięciem danych do polecenia powłoki.

Commit wskazywał „Copilot Autofix powered by AI” jako współautora, a wspomagany przez AI przegląd nie wykrył problemu. Nie ma jednak wystarczających dowodów, by stwierdzić, że Copilot wygenerował niebezpieczną zmianę albo że był jej autorem w ścisłym sensie. Najostrożniejszy wniosek brzmi: narzędzie było powiązane ze zmianą i nie wykryło w niej podatności.

Jak Red Agent znalazł i wykorzystał problem

Red Agent skanował publiczną organizację GitHub Snowflake’a pod kątem ryzykownych wzorców w potokach CI/CD. Zidentyfikował workflow Jira, w którym niezaufane dane ze zgłoszenia trafiały do bloku run:, i wywnioskował, że odpowiednio spreparowany tytuł publicznego zgłoszenia może doprowadzić do wykonania dowolnych poleceń na runnerze GitHub Actions.

23 czerwca — pięć dni po scaleniu podatnej zmiany — agent otworzył specjalnie przygotowane zgłoszenie w ramach programu ujawniania podatności HackerOne Snowflake’a. Tytuł wydostał się z łańcucha powłoki, a workflow wysłał dane uwierzytelniające Jira do kontrolowanego przez badaczy, pozapasmowego punktu zwrotnego (out-of-band callback), użytego w autoryzowanym dowodzie koncepcji.

Nie był to niekontrolowany włamanie, lecz usankcjonowany test bezpieczeństwa. Sama luka była jednak rzeczywista: każdy, kto mógł otworzyć publiczne zgłoszenie, mógł doprowadzić do wykonania poleceń w kroku workflow obsługującym dane uwierzytelniające.

Jaki dostęp uzyskano

Uruchomiony workflow miał dostęp do konfiguracji wewnętrznego Jira Snowflake’a, w tym adresu usługi, adresu e-mail użytkownika oraz tokena API. Odzyskany token był powiązany z kontem qa@snowflake.net. Wiz użył go do uwierzytelnienia w wewnętrznym portalu Jira i oceny potencjalnego zasięgu dostępu.

Z opisów wynika, że token zapewniał dostęp odczytu do projektów Jira związanych z inżynierią, zgodnością bezpieczeństwa oraz programem bug bounty. Dostępne materiały nie określają jednak pełnego zestawu uprawnień tokena ani nie zawierają kompletnej listy rekordów, które można było otworzyć. Najpewniejszy wniosek jest więc taki, że token umożliwiał dostęp do wrażliwych wewnętrznych treści Jira, a nie nieograniczony dostęp do systemów Snowflake’a.

Podatnym elementem była automatyzacja CI/CD repozytorium. Nie zgłoszono podatnej wydanej wersji Snowflake Connector for .NET, ponieważ problem znajdował się w workflow GitHub Actions, a nie w kodzie wykonywanym przez sam konektor.

Reakcja Snowflake’a

Wiz zgłosił problem 23 czerwca. Snowflake naprawił workflow tego samego dnia, a następnego dnia obrócił ujawnione dane uwierzytelniające Jira.

Firma przeanalizowała logi audytowe i ustaliła, że w czasie ekspozycji jedynym aktorem był Wiz. Wiz poinformował również, że bezpiecznie usunął dane wykorzystane w dowodzie koncepcji.

Nie zgłoszono nieautoryzowanego dostępu osób trzecich, nie przypisano podatności numeru CVE i nie wskazano żadnej podatnej wersji konektora. Te ograniczenia opisują potwierdzony wpływ incydentu, ale nie oznaczają, że pierwotny projekt workflow był bezpieczny. Tytuł publicznego zgłoszenia nie powinien trafiać bezpośrednio do polecenia powłoki w workflow, który korzysta z wewnętrznych danych uwierzytelniających.

Lekcja dla zespołów CI/CD

Przypadek Snowflake’a pokazuje problem szerszy niż samo Copilot Autofix. Tytuły zgłoszeń i pull requestów, nazwy gałęzi oraz komentarze należy traktować jako potencjalnie wrogie dane za każdym razem, gdy trafiają do polecenia powłoki.

Bezpieczniejszy projekt workflow obejmuje:

• przekazywanie niezaufanych wartości przez zmienne środowiskowe zamiast bezpośredniego wstawiania ich do skryptów run:;
• korzystanie z narzędzi strukturalnych, takich jak jq, do tworzenia JSON-a zamiast składania łańcuchów powłoki;
• odpowiednie cytowanie i walidowanie danych na granicy między workflow a powłoką;
• unikanie udostępniania danych uwierzytelniających krokom przetwarzającym treści kontrolowane przez użytkownika;
• sprawdzanie zmian wygenerowanych przez AI z taką samą starannością jak kod napisany przez człowieka.

To zwięzły przykład nowego wyścigu automatyzacji: jedno narzędzie AI może przeoczyć niebezpieczną zmianę w CI/CD, a autonomiczny agent ofensywny może znaleźć i zweryfikować ją w ciągu kilku dni. Automatyzacja przyspiesza zarówno wykrywanie i naprawę luk, jak i ich wykorzystanie — nie zastępuje jednak niezależnego przeglądu bezpieczeństwa.