Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent dotyczący Grafana pokazuje, jak poważne skutki mogą wywołać ataki na łańcuch dostaw oprogramowania, szczególnie gdy obejmują zaufane zależności wykorzystywane automatycznie w procesach CI/CD. W tym przypadku źródłem problemu był złośliwy pakiet npm powiązany z kampanią Shai-Hulud, który doprowadził do przechwycenia tokenów workflow i nieautoryzowanego dostępu do repozytoriów GitHub.
Kluczowym elementem eskalacji nie było wyłącznie samo pierwotne naruszenie, lecz niepełna reakcja po jego wykryciu. Pominięcie rotacji jednego z tokenów umożliwiło napastnikom utrzymanie dostępu do prywatnych zasobów deweloperskich i pobranie kodu źródłowego oraz części informacji operacyjnych.
W skrócie
- Grafana potwierdziła nieautoryzowany dostęp do repozytoriów GitHub po kompromitacji środowiska CI/CD.
- Wektor wejścia był związany ze złośliwymi pakietami npm powiązanymi z ekosystemem TanStack.
- Podczas reakcji na incydent zrotowano wiele tokenów, ale jeden został pominięty.
- Niezrotowany token pozwolił atakującym uzyskać dalszy dostęp do prywatnych repozytoriów i pobrać dane.
- Według aktualnych ustaleń nie ma dowodów na kompromitację środowisk produkcyjnych ani danych klientów.
Kontekst / historia
Tło incydentu stanowi szersza kampania malware określana jako Shai-Hulud. W jej ramach do ekosystemu npm trafiły złośliwe pakiety zawierające funkcje kradzieży poświadczeń. To klasyczny przykład ataku na łańcuch dostaw, w którym przeciwnik nie uderza bezpośrednio w wybraną organizację, lecz kompromituje element wykorzystywany przez jej procesy budowania i automatyzacji.
Złośliwa aktywność została wykryta 11 maja 2026 roku. Następnie 16 maja 2026 roku firma potwierdziła, że miała do czynienia z ukierunkowanym atakiem oraz żądaniem okupu pod groźbą ujawnienia pozyskanych informacji. W toku dalszej analizy ustalono, że intruzi pobrali nie tylko kod źródłowy, ale również uzyskali dostęp do części repozytoriów wykorzystywanych do przechowywania informacji operacyjnych i biznesowych, w tym służbowych danych kontaktowych.
Analiza techniczna
Technicznie incydent rozpoczął się od uruchomienia złośliwego pakietu npm w środowisku CI/CD. Po pobraniu i wykonaniu zależności malware zadziałał w kontekście workflow, przechwytując tokeny używane przez automatyzację. Tego rodzaju poświadczenia często posiadają uprawnienia do odczytu repozytoriów, uruchamiania zadań, publikowania artefaktów oraz komunikacji z innymi systemami deweloperskimi.
Z perspektywy bezpieczeństwa oznacza to, że pojedynczy wyciek tokenu może otworzyć drogę do szerokiej ekspozycji środowiska inżynierskiego. Szczególnie niebezpieczne są sytuacje, w których organizacja nie posiada pełnej inwentaryzacji sekretów lub stosuje tokeny o zbyt szerokim zakresie uprawnień.
Po wykryciu incydentu Grafana przeprowadziła rotację wielu tokenów GitHub workflow. Problem polegał jednak na tym, że jeden z nich został błędnie uznany za niezagrożony i nie został unieważniony. Późniejsza analiza wykazała, że odpowiadający mu workflow również został dotknięty kompromitacją. W efekcie napastnicy wykorzystali nadal ważny token do uzyskania dostępu do prywatnych repozytoriów.
To klasyczny przykład wtórnej fazy naruszenia, w której pierwotny wektor ataku został rozpoznany, ale niepełna remediacja pozostawiła aktywny artefakt uwierzytelniający. W praktyce oznacza to, że skuteczność reakcji na incydent zależy nie tylko od szybkości działania, ale również od kompletności identyfikacji wszystkich sekretów, workflow, runnerów i integracji z systemami zewnętrznymi.
Firma podkreśliła, że nie stwierdzono modyfikacji kodu źródłowego podczas incydentu. To ogranicza ryzyko dostarczenia zmodyfikowanych artefaktów użytkownikom, ale nie eliminuje zagrożeń związanych z ujawnieniem własności intelektualnej, konfiguracji środowiska czy informacji wspierających kolejne etapy ataku.
Konsekwencje / ryzyko
Najbardziej bezpośrednią konsekwencją było pobranie kodu źródłowego oraz uzyskanie dostępu do prywatnych zasobów deweloperskich. Taki scenariusz zwiększa możliwości rozpoznania architektury, mechanizmów budowania, zależności oraz procesów operacyjnych organizacji.
Nawet bez modyfikacji kodu przejęte repozytoria mogą dostarczyć napastnikom wiedzy o słabych punktach pipeline’ów, sposobach zarządzania sekretami czy potencjalnych miejscach dalszej eskalacji. Dodatkowo wyciek informacji operacyjnych i kontaktowych może wspierać kolejne kampanie phishingowe, spear phishing oraz oszustwa typu business email compromise.
Incydent pokazuje również, że częściowa rotacja sekretów nie zamyka problemu. Jeśli choć jeden token, klucz API lub sekret CI/CD pozostanie aktywny, przeciwnik może utrzymać dostęp mimo formalnego uruchomienia procedur bezpieczeństwa.
Z perspektywy klientów istotne jest to, że według obecnych ustaleń nie doszło do kompromitacji systemów produkcyjnych ani platformy chmurowej firmy. Nie ma też przesłanek, by użytkownicy musieli podejmować natychmiastowe działania po swojej stronie. Mimo to incydent powinien zostać potraktowany jako ostrzeżenie dla wszystkich organizacji opierających dostarczanie oprogramowania na zautomatyzowanych pipeline’ach i zewnętrznych zależnościach.
Rekomendacje
Organizacje powinny traktować środowiska CI/CD jako systemy uprzywilejowane i chronić je na poziomie zbliżonym do infrastruktury produkcyjnej. W praktyce oznacza to konieczność wdrożenia pełnej inwentaryzacji sekretów używanych przez workflow, runnerów, systemy build oraz integracje z repozytoriami i usługami zewnętrznymi.
- Stosować zasadę najmniejszych uprawnień dla tokenów automatyzacji.
- Wdrażać krótkotrwałe poświadczenia i ograniczony zakres uprawnień.
- Monitorować pipeline’y pod kątem anomalii, nieoczekiwanych połączeń sieciowych i uruchamiania nieznanych skryptów.
- Kontrolować integralność łańcucha dostaw poprzez pinning wersji, weryfikację pochodzenia pakietów i skanowanie zależności.
- Uzupełnić procedury IR o checklisty pełnej rotacji wszystkich typów poświadczeń powiązanych z incydentem.
- Prowadzić audyt commitów, konfiguracji workflow i historii zmian po incydencie.
Szczególne znaczenie ma założenie, że szybka rotacja większości sekretów nie jest wystarczająca. Dopiero pełna i zweryfikowana rotacja wszystkich poświadczeń może ograniczyć ryzyko utrzymania dostępu przez napastnika.
Podsumowanie
Incydent Grafana jest kolejnym dowodem na to, że ataki na łańcuch dostaw npm i środowiska CI/CD należą dziś do najpoważniejszych zagrożeń dla procesu wytwarzania oprogramowania. Kompromitacja rozpoczęła się od złośliwej zależności, ale realny wpływ biznesowy wynikał z niepełnej remediacji i pozostawienia aktywnego tokenu workflow.
Najważniejsza lekcja jest jednoznaczna: po naruszeniu środowiska automatyzacji liczy się nie tylko szybka reakcja, lecz przede wszystkim kompletna, potwierdzona i udokumentowana rotacja wszystkich poświadczeń. Nawet pojedynczy pominięty sekret może utrzymać atak przy życiu i zamienić incydent operacyjny w pełnoskalowe naruszenie zasobów deweloperskich.
Źródła
- https://www.bleepingcomputer.com/news/security/grafana-breach-caused-by-missed-token-rotation-after-tanstack-attack/
- https://grafana.com/blog/grafana-labs-security-update-latest-on-tanstack-npm-supply-chain-ransomware-incident/
- https://www.bleepingcomputer.com/news/security/grafana-says-stolen-github-token-let-hackers-steal-codebase/
- https://www.bleepingcomputer.com/news/security/shai-hulud-attack-ships-signed-malicious-tanstack-mistral-npm-packages/