Noma Labs wykazało, że pojedynczy publiczny issue w serwisie GitHub może posłużyć do kradzieży kodu z prywatnych repozytoriów przy użyciu automatyzacji opartej na AI. Ich dowód koncepcji (proof-of-concept) pozwala atakującemu wykorzystać własne boty workflow organizacji przeciwko niej, co prowadzi do wycieku zastrzeżonych plików bez łamania uwierzytelniania GitHub.

Atak na widoku wszystkich

Łańcuch zdarzeń jest wystarczająco prosty, aby go odtworzyć:

  • Atakujący tworzy issue w publicznym repozytorium, które każdy może zobaczyć.
  • Agent AI, podłączony do potoku ciągłej integracji (CI), odczytuje tytuł i treść issue.
  • Ten sam agent posiada już uprawnienia do odczytu innych prywatnych repozytoriów w organizacji.
  • Ukryte instrukcje w publicznym issue mówią agentowi, jakie prywatne pliki ma pobrać.
  • Agent publikuje pobrane pliki z powrotem w publicznym issue jako komentarz, wystawiając je na widok publiczny.

Wszystko dzieje się podczas jednego uruchomienia automatyzacji. Bez kradzieży poświadczeń, bez wycieku kluczy API, bez podatności w samym GitHubie. Atakujący po prostu wykorzystuje zaufanie, jakim organizacja obdarzyła własnego bota.

Dlaczego to jest teraz istotne

Agenci napędzani przez AI stanowią obecnie spoiwo nowoczesnych potoków deweloperskich. Otwierają pull-requesty, uruchamiają testy, wdrażają buildy i kategoryzują błędy (triage) – a wszystko to jest wyzwalane przez proste sygnały, takie jak komentarze w issue. Gdy agenci ci posiadają szeroki dostęp do repozytoriów, zaciera się granica między zaufanymi danymi a niezaufanymi danymi wejściowymi użytkownika.

Jeśli agent może odczytywać prywatny kod i pisać publicznie w ramach tego samego wykonania, model kontroli dostępu organizacji ulega załamaniu.

Prawdziwa wada: uprawnienia, a nie model

Demonstracja nie obciąża samego modelu AI. Model jedynie wykonuje otrzymane instrukcje. Podatność tkwi w zestawie uprawnień nadanych automatyzacji:

  • Uprawnienia do odczytu prywatnych repozytoriów w całej organizacji.
  • Uprawnienia do zapisu w publicznych wątkach issue.
  • Wyzwalacz w postaci publicznego tekstu, który każdy może sformułować.

Rozwiązania, które nic nie kosztują, a działają

Zastosowanie zasady najmniejszych uprawnień (least privilege) drastycznie ogranicza ścieżkę ataku:

  • Ogranicz zakres bota do repozytorium, w którym jest on potrzebny. Jeśli musi działać tylko w konkretnym repozytorium, odmów mu wszelkich innych praw do odczytu.
  • Rozdziel tokeny odczytu i zapisu. Użyj jednych poświadczeń do pobierania kodu, a innych, ściśle kontrolowanych poświadczeń do publikowania komentarzy.
  • Zatwierdzenie przez człowieka przed każdą publiczną publikacją. Lekki krok weryfikacji – np. wymagana etykieta zatwierdzenia – dodaje punkt kontrolny bez wstrzymywania potoku.
  • Zmniejszenie promienia rażenia (blast radius). Projektuj workflow tak, aby awaria lub nadużycie dotyczyły co najwyżej jednego repozytorium, a nie całej organizacji.

Kontrargument: narzut operacyjny

Na co zwrócić uwagę w przyszłości

Wniosek: Jeśli automatyzacja AI może jednocześnie widzieć prywatny kod i komunikować się publicznie, system jest źle zaprojektowany. Zaostrz uprawnienia, wprowadź weryfikację przez człowieka i ogranicz promień rażenia – w przeciwnym razie pojedynczy publiczny issue może stać się wektorem wycieku danych.