Agencja, która broni amerykańskiej infrastruktury krytycznej, miała własnego wykonawcę, który wyłączył skanowanie sekretów GitHuba i wrzucił klucze AWS GovCloud, hasła w czystym tekście oraz klucz prywatny RSA do publicznego repozytorium. Repo siedziało tam przez sześć miesięcy. Nikt nie zauważył, dopóki GitGuardian nie wpadł na nie w maju.

Wykonawca utworzył na GitHubie profil o nazwie "Private-CISA" w listopadzie 2025 i wypełnił go plikami o nazwach AWS-Workspace-Firefox-Passwords.csv, Important AWS Tokens.txt i kube-config.txt (KrebsOnSecurity). Nic nie było zakodowane. Nic nie było szyfrowane. Eksporty haseł z menedżera Firefoksa w czystym tekście, w publicznym repo, które każdy mógł sklonować.

Ale fragment, który powinien sprawić, że każdy inżynier DevOps się skrzywi: wykonawca celowo wyłączył wbudowane skanowanie sekretów GitHuba przed wrzuceniem poświadczeń. Logi commitów to potwierdzają (KrebsOnSecurity). Jedyne automatyczne zabezpieczenie, które oznaczyłoby ten wyciek, zostało wyłączone przez osobę, której zadaniem było administrowanie platformą kodową CISA.

Najgroźniejszą ekspozycją był klucz prywatny RSA powiązany z aplikacją GitHub App mającą pełny dostęp do organizacji CISA-IT. Ten jeden klucz pozwalał czytać każde prywatne repozytorium, rejestrować fałszywe runnery CI/CD do przejęcia pipeline'ów budowania i modyfikować reguły ochrony gałęzi oraz deploy keys. Dylan Ayrey z TruffleHog znalazł ten klucz wciąż aktywny dwa dni po początkowym raporcie KrebsOnSecurity z 18 maja (TruffleHog). Repo było już wtedy powszechnie znane. Każdy, kto monitoruje publiczny strumień zdarzeń GitHuba, mógł na nim siedzieć przez tygodnie.

Oficjalna odpowiedź CISA: "Nie ma wskazań, że w wyniku incydentu skompromitowano jakiekolwiek wrażliwe dane" (KrebsOnSecurity). Repo z dziesiątkami poświadczeń w czystym tekście było publiczne przez sześć miesięcy, ale CISA zapewnia, że nic się nie stało. Społeczność na Hacker News nie dała się przekonać: wątek zdobył 476 punktów i 183 komentarze, a wielokrotnie wskazywano, że publiczny strumień zdarzeń GitHuba jest monitorowany zarówno przez badaczy, jak i aktorów zagrożeń.

Ponad tydzień po powiadomieniu CISA nadal rotowała poświadczenia (KrebsOnSecurity). Przerwa między "repo usunięte" a "sekrety faktycznie unieważnione" okazała się znacznie szersza, niż sugeruje oświadczenie agencji.

Trzy lekcje dla programistów warto z tego wyciągnąć:

  1. Skanowanie sekretów nie jest opcjonalne. Jeśli Twoja organizacja pozwala je wyłączyć, masz problem z polityką, nie z narzędziami. Wymuszaj skanowanie na poziomie organizacji i blokuj możliwość obejścia.

  2. Czas rotacji poświadczeń jest ważniejszy niż czas wykrycia. Znalezienie wycieku w kilka godzin nic nie znaczy, jeśli unieważnienie dostępu trwa dni. Zmapuj procedury rotacji i przetestuj je, zanim będą potrzebne.

  3. Współdzielone poświadczenia w plikach CSV to systemowa porażka. AWS Organizations pozwala każdemu administratorowi na indywidualną autentykację krótkotrwałymi tokenami z pełnym śledzeniem audytowym. Argument "potrzebujemy wspólnych haseł" nie przetrwa konfrontacji z nowoczesnym IAM.

CISA nie jest tu wyjątkiem: ten sam wzorzec CSV-w-repo pojawia się w raportach o włamaniach od startupów, banków i dostawców chmury. Różnica polega na tym, że CISA ma być agencją, która uczy wszystkich innych, jak to robić dobrze.