Skala problemu której nie widać
GitGuardian w swoim raporcie za 2024 rok wykrył ponad 12,8 miliona sekretów wycieczonych do publicznych repozytoriów GitHub — wzrost o 28% rok do roku. Większość z nich nie trafiła tam przez atak. Trafiła przez zwykłe błędy konfiguracyjne, nieświadomość deweloperów lub nieprawidłowe założenia o tym jak działają pipeline’y CI/CD.
To co bardziej niepokojące: mediana czasu między opublikowaniem sekretu a jego pierwszym użyciem przez nieuprawnioną osobę wynosi według tych badań mniej niż 5 minut. Zautomatyzowane skanery nieustannie monitorują publiczne repozytoria w poszukiwaniu wzorców sekretów.
W repozytoriach prywatnych skala jest nieznana — ale mechanizmy wycieku są identyczne, a okno ekspozycji trwa do momentu wykrycia, które bez aktywnego monitoringu może nie nastąpić nigdy.
Mechanizm 1 — sekrety w logach buildu
GitHub Actions i podobne systemy CI/CD maskują wartości sekretów w logach — ale tylko tych sekretów które system zna. Sekrety obliczane dynamicznie w trakcie wykonania pipeline’u (np. dekodowane z Base64, generowane z innych zmiennych, pobierane z zewnętrznych systemów) nie są maskowane, bo system nie wie że są sekretami.
Logi buildu są często dostępne dla wszystkich członków organizacji, a nierzadko są eksportowane do zewnętrznych systemów logowania. Sekret który pojawi się w logu — istnieje w niezmienionym stanie tak długo jak długo przechowywany jest log.
Mechanizm 2 — zewnętrzne akcje z dostępem do środowiska
Ekosystem GitHub Actions bazuje na akcjach — gotowych blokach logiki hostowanych w repozytoriach GitHub. Akcje te są wykonywane w kontekście pipeline’u z dostępem do zmiennych środowiskowych, w tym sekretów. Jeśli repozytorium akcji zewnętrznej zostanie przejęte przez atakującego, każdy pipeline który jej używa — wykona złośliwy kod z pełnym dostępem do środowiska.
To nie jest scenariusz hipotetyczny. Kilka głośnych przypadków przejęcia popularnych akcji GitHub miało miejsce w ciągu ostatnich dwóch lat. Organizacje używające tych akcji nie miały żadnego mechanizmu wykrycia że kod który wykonują zmienił się między kolejnymi uruchomieniami pipeline’u.
Mechanizm 3 — Pull Request z forków zewnętrznych
W repozytoriach publicznych lub przy określonych konfiguracjach, workflow CI/CD mogą być uruchamiane dla pull requestów z zewnętrznych forków. Oznacza to że osoba bez dostępu do repozytorium może — przez modyfikację konfiguracji workflow w swoim forku — uruchomić kod w kontekście pipeline’u z dostępem do sekretów organizacji.
Dlaczego klasyczne narzędzia bezpieczeństwa nie wystarczą
Skaner podatności aplikacji nie analizuje konfiguracji pipeline’u. WAF nie monitoruje ruchu wewnątrz systemu CI/CD. Testy penetracyjne aplikacji zazwyczaj nie obejmują infrastruktury wytwórczej.
Bezpieczeństwo pipeline’u wymaga dedykowanych kontroli: analizy konfiguracji workflow, monitoringu sekretów, audytu dostępów i weryfikacji integralności zewnętrznych zależności. To odrębna dyscyplina od klasycznego application security — i często nieobecna w organizacjach które skupiają się wyłącznie na zabezpieczeniu aplikacji.
Czytaj również: