Do Czego Naprawdę Włamał Się Agent Wiz

Wiz zbudował autonomicznego agenta AI o nazwie Red Agent, aby szukał możliwych do wykorzystania luk tak, jak zrobiłby to ludzki tester penetracyjny, a następnie działał na podstawie tego, co znajdzie. Skierowany na publiczne repozytoria GitHub Snowflake, znalazł lukę typu wstrzyknięcie skryptu w pliku workflow GitHub Actions o nazwie jira_issue.yml wewnątrz snowflakedb/snowflake-connector-net, otwartoźródłowego łącznika .NET Snowflake. Luka pozwalała każdemu otworzyć zgłoszenie GitHub ze specjalnie spreparowanym tytułem i sprawić, że własna automatyzacja Snowflake wykonywała część tego tytułu jako polecenie powłoki, bez logowania.

Pierwsza próba Red Agenta się nie powiodła. Runner zwrócił błąd składni zamiast wykonać ładunek. Zamiast się poddać, agent odczytał błąd, samodzielnie przepisał spreparowany tytuł zgłoszenia i spróbował ponownie. Druga próba wyrwała się z ciągu powłoki i dotarła do domeny kontrolowanej przez atakującego, wykradając przy okazji zakodowany w base64 token API Jira. Odkrycie, dostosowanie, wykorzystanie i weryfikacja uzyskanego dostępu odbyły się wszystkie w jednej sesji, bez udziału człowieka podejmującego decyzję o kolejnym kroku.

Skradziony token był ważny i uwierzytelniony jako konto usługi Snowflake, co dawało dostęp do odczytu wewnętrznej instancji Jira obejmującej projekty inżynieryjne, zgodność bezpieczeństwa i śledzenie nagród za błędy. Podatny kod był aktywny od połączenia PR #1218 18 czerwca 2026 roku, które zastąpiło bezpieczny wzorzec parsowania bezpośrednią interpolacją zmiennych w poleceniu powłoki. Snowflake naprawił to 23 czerwca 2026 roku, przywracając bezpieczny wzorzec, oraz unieważnił i odnowił ujawniony token; kontrola dzienników nie wykazała dowodów, że jakakolwiek strona zewnętrzna go użyła podczas pięciodniowego okna ekspozycji.

Wiz Wskazał Copilota Jako Współautora Błędu

Pierwotny raport Wiz wskazał na commit, który wprowadził lukę, i zauważył, że GitHub Copilot Autofix pojawiał się w nim jako współautor. Narracja napisała się sama: asystent programistyczny AI wydawał się pomóc napisać dokładnie ten błąd, który agent bezpieczeństwa AI następnie znalazł i wykorzystał autonomicznie, po obu stronach.

Linia współautorstwa była prawdziwa, a scalenia typu squash sprawiają, że tego rodzaju dowód wygląda solidniej, niż jest w rzeczywistości. Pull request może zawierać wiele pojedynczych commitów od wielu współtwórców, ale scalenie squash łączy je wszystkie w jeden commit na głównej gałęzi, a każda linia współautorstwa z każdego z tych commitów przenosi się do połączonego wyniku. Nazwisko w tej linii rejestruje udział gdzieś w pull requeście, a nie autorstwo konkretnej linii. Zanim Wiz zaktualizował swój wpis 17 sierpnia 2026 roku, jego własny język już złagodniał do przyznania, że nie było jasne, czy Copilot w ogóle przyczynił się do podatnych linii.

Historia Commitów GitHub Mówi, Że Napisał To Człowiek

GitHub przeprowadził własny wewnętrzny przegląd tego samego repozytorium i doszedł do innego wniosku. Według GitHub, niebezpieczną refaktoryzację napisał ludzki inżynier Snowflake, w osobnym commicie datowanym na 25 sierpnia 2025 roku, około dziesięciu miesięcy przed połączeniem podatnego pull requestu, a Copilot Autofix ani nie przejrzał, ani nie przyczynił się do tych konkretnych linii.

Rzeczywisty commit współautorski Copilota wewnątrz pull requestu #1218 zmienił inny plik, jira_close.yml, niepowiązany z podatnymi liniami jira_issue.yml, które wykorzystał Red Agent. Gdy pull request został skompresowany do jednego commitu scalającego, linia współautorstwa Copilota i tak podróżowała razem z nim, przypięta do zmiany, której nigdy nie dotknął.

Spór jest teraz publiczny, z dwiema sprzecznymi wersjami i bez niezależnego sędziego. Wiz wskazuje na linię współautorstwa w żywej historii commitów; GitHub wskazuje na wewnętrzny przegląd tego samego repozytorium, który odczytuje autorstwo inaczej. Nikt poza tymi dwiema firmami nie ma dostępu potrzebnego, aby ustalić, która interpretacja jest poprawna.

Luka w Zarządzaniu, Którą Powinien Zauważyć Każdy Zespół Wspierany przez AI

Prowadzenie asystenta programistycznego AI i skanera bezpieczeństwa AI w tym samym potoku szybko staje się konfiguracją domyślną, a nie wyjątkiem. Gdy w takiej konfiguracji coś pójdzie źle, zarówno strona, która znajduje błąd, jak i narzędzie oskarżone o jego napisanie mogą być systemami AI, a jedynym dowodem, do którego może się odwołać którakolwiek ze stron, jest historia commitów repozytorium. Ta historia jest wiarygodna tylko na tyle, na ile wiarygodne są praktyki, które ją wytworzyły, a rutynowe scalenie squash właśnie udowodniło, że może przypisać nazwisko jednego współtwórcy do błędu innego, choć nikt tego nie zamierzał.

Sam błąd pozostawał ujawniony przez pięć dni i potrzebował kolejnych pięciu dni na naprawę. Dyskusja o tym, kto go napisał, trwała dłużej niż sama luka, a toczyła się między dwoma dostawcami dysponującymi zasobami i dostępem do repozytorium potrzebnymi do właściwego zbadania sprawy. Firma z mniejszą dyscypliną w zachowywaniu historii commitów własnych plików workflow, bez ustalonej odpowiedzi na to, kto wewnątrz firmy jest upoważniony do publikowania twierdzenia o autorstwie, zanim stanie się ono publicznym sporem, nie rozwiąże swojej wersji równie starannie.

Czytaj dalej: Jeden udział był wart więcej niż trzy fundusze  |  Wycofany model graniczny znów jest online