Wyciek danych z CISA przez GitHub. Czego uczy nas incydent w amerykańskiej agencji?

Pod koniec maja 2026 roku amerykańska Agencja ds. Cyberbezpieczeństwa i Bezpieczeństwa Infrastruktury (CISA) zmagała się z poważnym incydentem bezpieczeństwa. Jeden z kontraktorów agencji, mający administracyjny dostęp do platformy deweloperskiej, utworzył publiczne repozytorium na GitHubie o nazwie „Private-CISA” i opublikował w nim dziesiątki haseł oraz kluczy dostępu do wewnętrznych systemów CISA. Sprawa, opisana przez KrebsOnSecurity, pokazuje, jak niebezpieczne może być łączenie prywatnych kont z pracą nad newralgicznymi projektami.

Jak doszło do wycieku?

Według ustaleń dziennikarzy, kontraktor CISA celowo wyłączył wbudowane w GitHuba zabezpieczenie przed publikowaniem poufnych danych w publicznych repozytoriach. Eksperci, którzy przeanalizowali archiwum „Private-CISA”, stwierdzili, że repozytorium powstało w listopadzie 2025 roku i było używane jako roboczy notatnik lub narzędzie do synchronizacji plików między służbowym a domowym komputerem. Znalazły się w nim m.in. klucze dostępu do zasobów AWS GovCloud, a także klucz prywatny RSA umożliwiający odczyt kodu źródłowego ze wszystkich repozytoriów w organizacji CISA-IT.

Firma GitGuardian, specjalizująca się w wykrywaniu wycieków, powiadomiła CISA o incydencie. Mimo to, jak podaje KrebsOnSecurity, agencja potrzebowała ponad tygodnia, aby unieważnić część ujawnionych kluczy. Dylan Ayrey, twórca narzędzia TruffleHog do wykrywania sekretów w kodzie, zwrócił uwagę, że jeszcze 20 maja 2026 roku CISA nie unieważniła klucza RSA do aplikacji GitHub z pełnym dostępem do repozytoriów. Dopiero po ponownym zgłoszeniu agencja zareagowała.

Dlaczego to ważne dla polskich firm?

Incydent w CISA nie dotyczy bezpośrednio polskich użytkowników, ale niesie uniwersalne lekcje. Każda organizacja, która korzysta z GitHub, GitLaba czy innych platform do zarządzania kodem, jest narażona na podobne ryzyko. Jak zauważył Adam Boileau, współprowadzący podcast Risky Business, cytowany przez KrebsOnSecurity: „Ostatecznie jest to problem ludzki, a nie techniczny. Zatrudniasz kontraktorów, a oni z własnej woli decydują się używać GitHub do synchronizacji treści między służbowym a domowym komputerem”.

W praktyce oznacza to, że nawet najlepsze zabezpieczenia techniczne – blokady na poziomie GitHub Enterprise, polityki skanowania sekretów czy zakazy publikowania na zewnętrznych serwerach – mogą okazać się nieskuteczne, jeśli pracownik lub kontraktor założy własne, niekontrolowane konto i zacznie na nim przechowywać poufne dane.

Jakie były skutki incydentu?

CISA w oficjalnym oświadczeniu zapewniła, że „nie ma dowodów na to, by w wyniku incydentu doszło do kompromitacji jakichkolwiek danych wrażliwych”. Jednak kongresmeni i senatorowie zażądali odpowiedzi na kilkanaście pytań dotyczących okoliczności wycieku. W liście do pełniącego obowiązki dyrektora CISA, Nicka Andersena, senator Maggie Hassan napisała: „To zgłoszenie budzi poważne obawy dotyczące wewnętrznych polityk i procedur CISA w czasie, gdy zagrożenia cybernetyczne dla amerykańskiej infrastruktury krytycznej są znaczące”.

Eksperci, z którymi rozmawiał KrebsOnSecurity, podkreślają, że cyberprzestępcy i obce wywiady również monitorują publiczny strumień commitów na GitHubie. Oznacza to, że klucze opublikowane w „Private-CISA” mogły zostać przechwycone przez atakujących jeszcze przed powiadomieniem agencji. Ayrey z Truffle Security wskazał, że najbardziej wrażliwe dane trafiły do repozytorium pod koniec kwietnia 2026 roku, co dawało potencjalnym napastnikom przynajmniej kilka tygodni na ich wykorzystanie.

Jak się bronić przed podobnym ryzykiem?

Incydent w CISA pokazuje, że kluczowe jest połączenie zabezpieczeń technicznych z kontrolą procesów i szkoleniami. Oto kilka praktycznych zaleceń dla administratorów i działów IT:

• Blokada publikowania sekretów na poziomie platformy. GitHub Enterprise i inne systemy oferują funkcje skanowania commitów pod kątem haseł i kluczy. Warto włączyć je domyślnie i wymusić polityką.
• Monitorowanie kont zewnętrznych. Organizacje powinny mieć możliwość wykrywania, gdy pracownik lub kontraktor loguje się do swojego prywatnego konta GitHub z sieci firmowej lub używa go do synchronizacji plików.
• Szkolenia i jasne procedury. Każda osoba z dostępem do kodów źródłowych i systemów produkcyjnych powinna wiedzieć, że przechowywanie haseł w publicznych repozytoriach jest niedozwolone. Warto regularnie przeprowadzać audyty i testy, np. z użyciem narzędzi takich jak TruffleHog.
• Segmentacja dostępu. Nawet jeśli dojdzie do wycieku, ograniczenie zakresu uprawnień poszczególnych kont może zmniejszyć potencjalne szkody. W przypadku CISA jeden klucz dawał dostęp do wszystkich repozytoriów w organizacji – to zbyt szeroki zakres.

Co dalej?

Sprawa CISA nie jest odosobniona. Podobne incydenty zdarzają się regularnie w firmach i instytucjach na całym świecie. Warto obserwować, jakie zmiany w procedurach wprowadzi amerykańska agencja – mogą one stać się wzorem dla innych organizacji. Na razie najważniejszy wniosek jest prosty: technologia nie zastąpi kultury bezpieczeństwa, a każdy przypadek wycieku to sygnał, by przyjrzeć się nie tylko systemom, ale też ludziom, którzy z nich korzystają.