Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania pozostają jednym z najpoważniejszych zagrożeń dla środowisk DevSecOps. Ich istota polega na przejęciu zaufanego komponentu, takiego jak wtyczka CI/CD, pakiet, obraz kontenera lub workflow automatyzacji, a następnie wykorzystaniu go do dystrybucji złośliwych zmian przez legalny kanał aktualizacji. Najnowszy incydent dotyczący Checkmarx i wtyczki AST dla Jenkins wpisuje się dokładnie w ten scenariusz.
W tym przypadku problem dotyczy komponentu używanego w procesach skanowania bezpieczeństwa aplikacji. To szczególnie wrażliwy obszar, ponieważ wtyczki działające w pipeline’ach mają często dostęp do kodu źródłowego, sekretów, tokenów API oraz mechanizmów publikacji artefaktów.
W skrócie
Zmodyfikowana wersja wtyczki Checkmarx Jenkins AST została opublikowana w Jenkins Marketplace. Producent potwierdził incydent i wskazał, że organizacje powinny korzystać z wersji 2.0.13-829.vc72453fa_1c16 z 17 grudnia 2025 roku lub wcześniejszej, a następnie udostępniono nowsze wydanie 2.0.13-848.v76e89de8a_053.
- Incydent został powiązany z aktywnością grupy TeamPCP.
- Doszło do publikacji nieautoryzowanego wydania w zaufanym kanale dystrybucji.
- Zagrożone mogły być sekrety, kod źródłowy oraz integralność procesów CI/CD.
- Zdarzenie wpisuje się w szerszą serię naruszeń dotyczących ekosystemu Checkmarx.
Kontekst / historia
To nie jest odosobnione zdarzenie. TeamPCP była wcześniej łączona z naruszeniami obejmującymi obraz Docker KICS, rozszerzenia do Visual Studio Code oraz workflow GitHub Actions. Wspólnym mianownikiem tych incydentów było uderzenie w zaufane komponenty wykorzystywane przez deweloperów i zespoły bezpieczeństwa.
Wtyczka Checkmarx AST Scanner dla Jenkins służy do integracji skanowania bezpieczeństwa aplikacji z pipeline’ami budowania. Jej kompromitacja może oznaczać nie tylko wyciek danych, ale również wpływ na sam proces oceny bezpieczeństwa kodu. To sprawia, że skutki incydentu mogą wykraczać daleko poza pojedynczy serwer Jenkins.
Niepokojący jest również fakt, że kolejne zdarzenie pojawiło się po wcześniejszych problemach bezpieczeństwa związanych z zasobami Checkmarx. Z perspektywy operacyjnej może to sugerować niepełną remediację, utrzymanie dostępu przez napastników albo niewystarczającą rotację poświadczeń po poprzednich incydentach.
Analiza techniczna
Z dostępnych informacji wynika, że atakujący uzyskali nieautoryzowany dostęp do repozytorium lub procesu wydawniczego powiązanego z wtyczką. W rezultacie w oficjalnym kanale dystrybucji pojawiło się zmodyfikowane wydanie pluginu. To kluczowy element tego incydentu, ponieważ użytkownicy nie musieli pobierać pliku z podejrzanego źródła — złośliwa wersja była rozpowszechniana przez legalny kanał.
Wtyczka AST Scanner działa jako pomost między Jenkins a platformą bezpieczeństwa aplikacji Checkmarx. Taki komponent może przetwarzać archiwa kodu źródłowego, obsługiwać wyniki skanowania, korzystać z danych uwierzytelniających i wykonywać operacje w kontekście procesu CI/CD. W praktyce oznacza to szerokie możliwości nadużyć po stronie napastnika.
- wyciek tokenów, sekretów i poświadczeń przechowywanych w Jenkins,
- kopiowanie lub eksfiltrację kodu źródłowego z pipeline’ów,
- manipulację wynikami skanowania bezpieczeństwa,
- uruchamianie dodatkowego kodu na agentach build,
- utrzymywanie trwałości poprzez dalsze modyfikacje procesu automatyzacji.
Szczególnie istotny jest komunikat wskazujący na publikację „rogue release published outside the official release pipeline”. Taki zapis sugeruje, że problem nie ograniczał się do samej bazy kodu, lecz mógł dotyczyć poświadczeń wydawniczych, tokenów maintainerów, sekretów używanych przez workflow automatyzujące release albo braku odpowiedniej separacji między środowiskiem developerskim a publikacyjnym.
Z technicznego punktu widzenia najgroźniejsze jest to, że złośliwa wersja mogła wyglądać jak standardowa aktualizacja. W organizacjach, które ufają automatycznym aktualizacjom i nie prowadzą dodatkowej walidacji krytycznych zależności, takie wydanie może zostać wdrożone szybko i bez wzbudzania podejrzeń.
Konsekwencje / ryzyko
Ryzyko związane z kompromitacją wtyczki Jenkins należy oceniać jako wysokie. Jenkins w wielu organizacjach posiada szerokie uprawnienia do repozytoriów kodu, rejestrów artefaktów, środowisk chmurowych, narzędzi bezpieczeństwa oraz systemów wdrożeniowych. Naruszenie jednego elementu tego ekosystemu może więc doprowadzić do efektu domina.
- kradzież sekretów deweloperskich i poświadczeń usługowych,
- wyciek własności intelektualnej poprzez dostęp do kodu źródłowego,
- wstrzyknięcie złośliwych zmian do budowanych artefaktów,
- obniżenie wiarygodności wyników skanowania bezpieczeństwa,
- ryzyko wtórnych naruszeń u klientów i partnerów korzystających z tych artefaktów.
Najbardziej narażone pozostają organizacje, które automatycznie aktualizują wtyczki lub nie stosują ścisłej kontroli integralności komponentów używanych przez Jenkins. W takich środowiskach złośliwe wydanie może zostać rozprowadzone na dużą skalę, zanim zespół bezpieczeństwa zauważy anomalię.
Długofalowo tego typu incydenty osłabiają także zaufanie do narzędzi AppSec i DevSecOps. Jeżeli komponent bezpieczeństwa sam staje się wektorem ataku, organizacje muszą ponownie ocenić ryzyko wynikające z używania zewnętrznych integracji w krytycznych procesach wytwarzania oprogramowania.
Rekomendacje
Organizacje korzystające z Checkmarx AST Scanner w Jenkins powinny w pierwszej kolejności ustalić, jaka wersja wtyczki była zainstalowana oraz kiedy doszło do jej aktualizacji. Następnie należy porównać historię zmian z oficjalnymi komunikatami producenta i przeanalizować logi pod kątem nietypowych zdarzeń związanych z instalacją, wykonaniem i konfiguracją pluginu.
- zweryfikować wersję wtyczki i odizolować systemy z podejrzanym wydaniem,
- przeprowadzić pełną rotację sekretów dostępnych z poziomu Jenkins,
- sprawdzić logi pipeline’ów, agentów build i hostów Jenkins,
- zweryfikować integralność wygenerowanych artefaktów, obrazów i paczek,
- przeanalizować workflow automatyzacji oraz konfiguracje pluginów zależnych.
W warstwie prewencyjnej warto ograniczyć automatyczne aktualizacje krytycznych wtyczek bez etapu akceptacji, wymusić wieloskładnikowe uwierzytelnianie dla maintainerów i kont publikacyjnych, stosować krótkotrwałe tokeny oraz regularną rotację sekretów. Równie istotna jest separacja ról między tworzeniem kodu, utrzymaniem repozytorium i publikacją release’ów.
Dodatkową warstwę ochrony powinny zapewnić mechanizmy walidacji pochodzenia komponentów, podpisywania artefaktów, lista dozwolonych wersji oraz monitoring anomalii w procesach CI/CD. Każda kompromitacja komponentu używanego w pipeline’ach powinna być traktowana jak potencjalne pełne naruszenie środowiska deweloperskiego.
Podsumowanie
Kompromitacja wtyczki Checkmarx AST dla Jenkins to kolejny wyraźny sygnał, że ataki na łańcuch dostaw oprogramowania stają się coraz bardziej dojrzałe i precyzyjne. Napastnicy nie koncentrują się już wyłącznie na aplikacjach końcowych, lecz coraz częściej celują w narzędzia odpowiedzialne za budowanie, skanowanie i publikację kodu.
Dla zespołów bezpieczeństwa oznacza to konieczność traktowania środowisk CI/CD jako infrastruktury krytycznej. Ochrona sekretów, ścisła kontrola dostępu, walidacja integralności zależności oraz dojrzałe procedury reagowania na incydenty stają się dziś równie ważne jak bezpieczeństwo samego produktu końcowego.