Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych zagrożeń dla środowisk DevSecOps oraz CI/CD. Ich istota polega na przejęciu zaufanego elementu procesu wytwarzania oprogramowania, takiego jak wtyczka, biblioteka, obraz kontenera czy workflow automatyzujący build i testy. W najnowszym incydencie ofiarą padła wtyczka Checkmarx AST Scanner dla Jenkins, do której trafiła zmodyfikowana, nieautoryzowana wersja.
To szczególnie niebezpieczny scenariusz, ponieważ komponent zintegrowany z pipeline’ami budowania ma zwykle dostęp do sekretów, tokenów API, poświadczeń chmurowych i danych uwierzytelniających wykorzystywanych przez zespoły deweloperskie oraz bezpieczeństwa. Kompromitacja takiego narzędzia może więc szybko przełożyć się na szerokie skutki operacyjne i bezpieczeństwa.
W skrócie
Checkmarx potwierdził, że w ekosystemie Jenkins pojawiła się zmodyfikowana wersja wtyczki AST Scanner. Producent zalecił użytkownikom sprawdzenie, czy korzystają z wersji 2.0.13-829.vc72453fa_1c16 opublikowanej 17 grudnia 2025 roku lub starszej, a następnie przejście na nowsze wydanie naprawcze 2.0.13-848.v76e89de8a_053.
Incydent jest łączony z aktywnością grupy TeamPCP, która była wcześniej wskazywana w kontekście naruszeń obejmujących inne artefakty Checkmarx, w tym obrazy Docker, rozszerzenia VS Code i workflow GitHub Actions. Zdarzenie wpisuje się w klasyczny model supply chain attack wymierzonego w narzędzia wykorzystywane bezpośrednio w procesie tworzenia i testowania oprogramowania.
Kontekst / historia
To nie jest pierwszy incydent związany z ekosystemem Checkmarx. W marcu 2026 roku firma informowała już o cyberincydencie dotyczącym wybranych komponentów dystrybuowanych przez kanały używane przez zespoły developerskie. Wówczas problem obejmował między innymi workflow GitHub Actions oraz dodatki związane z bezpieczeństwem aplikacji.
Nowy przypadek sugeruje, że przeciwnik mógł utrzymać dostęp do części zasobów albo ponownie wykorzystać słabości w obszarze zarządzania sekretami, repozytoriami i procesem publikacji artefaktów. Powtarzalność podobnych incydentów wskazuje na szerszą kampanię ukierunkowaną na przejmowanie zaufanych elementów łańcucha dostaw oprogramowania.
Analiza techniczna
W analizowanym scenariuszu doszło do opublikowania zmodyfikowanej wersji wtyczki Checkmarx AST Scanner w ekosystemie Jenkins. Z punktu widzenia atakującego jest to wyjątkowo efektywny wektor, ponieważ wiele organizacji ufa oficjalnym kanałom dystrybucji i instaluje aktualizacje bez dodatkowej walidacji pochodzenia artefaktów.
Wtyczka Checkmarx dla Jenkins integruje skanowanie bezpieczeństwa z pipeline’ami buildowymi, co oznacza, że może działać w kontekście bardzo wrażliwych procesów. W praktyce uzyskuje ona często dostęp do konfiguracji buildów, sekretów środowiskowych, tokenów do repozytoriów kodu, kluczy do usług chmurowych oraz wyników skanów bezpieczeństwa.
- przechwytywanie sekretów przekazywanych do procesu skanowania,
- uruchamianie dodatkowego kodu w kontekście joba Jenkins,
- modyfikację wyników skanowania lub telemetrii,
- komunikację z zewnętrzną infrastrukturą sterującą,
- rozszerzenie wpływu na kolejne elementy pipeline’u i środowiska.
W opisie incydentu pojawiały się również informacje o nieautoryzowanym dostępie do repozytorium powiązanego z projektem oraz o defacemencie. Taki sygnał oznacza, że problem nie ograniczał się wyłącznie do pojedynczego artefaktu, lecz mógł dotyczyć integralności całego procesu utrzymania i publikowania komponentu. Dodatkowo wcześniejsze ostrzeżenia dotyczące publikacji wydania poza oficjalnym pipeline’em wzmacniają podejrzenie naruszenia samego procesu release management.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem kompromitacji wtyczki Jenkins jest utrata zaufania do narzędzia znajdującego się w centrum procesu SDLC. Jeśli złośliwy komponent został uruchomiony w środowisku CI/CD, skutki mogą wykraczać daleko poza pojedynczy serwer Jenkins i obejmować wiele systemów zależnych.
- wyciek sekretów developerskich i chmurowych,
- przejęcie kont usługowych,
- kompromitację repozytoriów kodu źródłowego,
- modyfikację pipeline’ów oraz artefaktów budowania,
- ruch boczny do innych segmentów infrastruktury.
Ryzyko rośnie szczególnie tam, gdzie Jenkins ma szerokie uprawnienia sieciowe i integruje się jednocześnie z repozytoriami, systemami chmurowymi, skanerami bezpieczeństwa i mechanizmami wdrożeń. Nawet krótka ekspozycja na złośliwą wersję może prowadzić do długotrwałych konsekwencji, jeśli przechwycone tokeny lub klucze nadal pozostają aktywne.
Rekomendacje
Organizacje korzystające z Checkmarx AST Scanner w Jenkins powinny potraktować incydent jako potencjalne naruszenie bezpieczeństwa, a nie jedynie problem z aktualizacją wtyczki. Odpowiedź powinna obejmować zarówno działania natychmiastowe, jak i przegląd długoterminowych mechanizmów ochrony łańcucha dostaw.
- zweryfikować wersję zainstalowanej wtyczki na wszystkich kontrolerach Jenkins i agentach buildowych,
- przywrócić wersję uznaną za bezpieczną lub przejść na wydanie naprawcze,
- przeanalizować logi pod kątem nietypowych aktualizacji, zmian konfiguracji i podejrzanych połączeń wychodzących,
- przeprowadzić rotację wszystkich sekretów dostępnych dla pipeline’ów i integracji Checkmarx,
- sprawdzić integralność skryptów buildowych, bibliotek współdzielonych i ostatnio tworzonych artefaktów,
- wprowadzić pinowanie wersji wtyczek oraz dodatkową walidację pochodzenia komponentów,
- ograniczyć uprawnienia Jenkins zgodnie z zasadą najmniejszych przywilejów,
- wzmocnić monitoring procesów publikacji i aktualizacji oprogramowania.
Z perspektywy strategicznej incydent potwierdza potrzebę izolacji środowisk CI, segmentacji agentów, ograniczania dostępu do sekretów per job oraz wdrażania mechanizmów potwierdzania integralności artefaktów. Bez takich zabezpieczeń pojedyncza kompromitacja zaufanego komponentu może stać się punktem wyjścia do szerszego naruszenia organizacji.
Podsumowanie
Kompromitacja wtyczki Checkmarx AST dla Jenkins to kolejny przykład skutecznego ataku na zaufany element ekosystemu developerskiego. Uderzenie w narzędzie używane bezpośrednio w pipeline’ach CI/CD daje napastnikom dostęp do wyjątkowo cennych zasobów, w tym sekretów, poświadczeń i procesów budowania oprogramowania.
Dla organizacji oznacza to konieczność traktowania bezpieczeństwa wtyczek, workflow i artefaktów jako kluczowego elementu ochrony łańcucha dostaw. Samo usunięcie podejrzanej wersji nie wystarczy — niezbędne są analiza wpływu, rotacja sekretów oraz przegląd zaufania do procesu publikacji i aktualizacji komponentów.