TeamPCP: jak Trivy, KICS, LiteLLM i axios zatruły zaufanie do CI/CD

Między 19 a 31 marca 2026 roku seria incydentów pokazała, że narzędzie bezpieczeństwa uruchamiane w CI/CD może stać się najskuteczniejszym złodziejem sekretów. Kampania przypisywana jako TeamPCP objęła komponenty związane z Trivy, Checkmarx KICS i LiteLLM, a pod koniec miesiąca ekosystem JavaScript mierzył się także ze skompromitowanymi wydaniami axios. Wspólną cechą nie był język programowania, lecz implicit trust pipeline’u do tagu, pakietu i skryptu instalacyjnego.

Według podsumowania GitLab, 19 marca przejęte credentiale posłużyły do force-push złośliwego kodu do 76 z 77 tagów aquasecurity/trivy-action i wszystkich siedmiu tagów aquasecurity/setup-trivy. Trojanizowany Trivy 0.69.4 trafił też do oficjalnych kanałów. Payload zbierał zmienne środowiskowe, tokeny chmurowe, klucze SSH i sekrety pipeline’u. Incydent otrzymał CVE-2026-33634.

23 marca podobny mechanizm dotknął akcji KICS. 24 marca pojawiły się złośliwe wydania LiteLLM 1.82.7 i 1.82.8. Pierwsze uruchamiało payload przy imporcie modułu, drugie używało pliku .pth, który Python przetwarza podczas startu interpretera. 31 marca skompromitowane wydania axios 1.14.1 i 0.30.4 wprowadzały złośliwą zależność i wieloplatformowy RAT. Daty, wersje i opis techniczny pochodzą z komunikatów dostawców i podsumowania GitLab; przed reakcją trzeba sprawdzić bieżące advisory każdego projektu.

Dlaczego skaner ma dostęp do wszystkiego

Job bezpieczeństwa często działa wcześnie, skanuje cały checkout, czyta obraz kontenera i publikuje wynik. Dostaje token repozytorium, dane registry, cache, czasem credential chmurowy oraz prawo zapisu artefaktów. Zespół zakłada, że skaner jest kontrolą, więc nadaje mu więcej zaufania niż zwykłemu dependency.

Gdy tag GitHub Action jest mutable, zapis uses: vendor/action@v1 nie określa kodu kryptograficznie. Maintainer albo napastnik z jego tokenem może przesunąć tag. Pipeline pobierze nowy commit bez zmiany w repozytorium użytkownika i bez code review. To różnica między wersją czytelną dla człowieka a identyfikatorem niezmiennym.

LiteLLM pokazał drugi mechanizm. Instalacja pakietu Pythona może wykonywać kod nie tylko przez jawną aplikację. Plik .pth w site-packages może zawierać instrukcję importu uruchamianą podczas inicjalizacji interpretera. Oznacza to, że „nie wystartowaliśmy serwera LiteLLM” nie wyklucza wykonania payloadu, jeżeli środowisko uruchomiło Pythona po instalacji.

Jak ustalić, czy pipeline był narażony

Przeszukaj wszystkie repozytoria, reusable workflows, szablony organizacyjne i obrazy runnerów pod kątem:

• aquasecurity/trivy-action oraz aquasecurity/setup-trivy wskazanych tagami;
• obrazów i binariów Trivy 0.69.4–0.69.6 zgodnie z aktualnym advisory;
• akcji KICS użytych w oknie incydentu;
• litellm==1.82.7 lub 1.82.8 w lockfile, cache i warstwach obrazu;
• axios 1.14.1 lub 0.30.4 oraz złośliwej zależności opisanej przez projekt;
• nieznanych .pth zawierających import, exec, subprocess albo sieć;
• pobrań i ruchu do lookalike domain models.litellm.cloud.

Samo poprawienie manifestu nie wystarcza. Trzeba znaleźć każde wykonanie podatnego joba i ustalić, jakie sekrety były w tym momencie dostępne. Runner może eksponować zmienne organizacyjne tylko na chronionej gałęzi, inne tokeny przez OIDC, a jeszcze inne przez pliki lub credential helper. Buduj macierz pipeline run → commit → runner → secrets → systems.

Rotacja sekretów po kompromitacji CI/CD

Jeżeli złośliwy komponent wykonał się w jobie, załóż ekspozycję wszystkich dostępnych mu sekretów. Rotacja powinna być atomowa: najpierw utwórz nowy sekret i zaktualizuj zależne systemy, następnie unieważnij stary, a w krótkim oknie monitoruj użycie obu. Jeżeli nowy token zostanie wstrzyknięty do nadal zainfekowanego runnera przed oczyszczeniem, atakujący ukradnie go ponownie.

Kolejność praktyczna:

1. wstrzymaj dotknięte pipeline’y i odłącz samohostowane runnery;
2. zabezpiecz logi, cache, obrazy i metadane jobów;
3. odbuduj runner z zaufanego, zweryfikowanego obrazu;
4. usuń złośliwe pakiety i przypnij poprawione artefakty;
5. rotuj tokeny repozytoriów, chmur, registry, SSH, signing i deployment;
6. przejrzyj systemy docelowe pod kątem użycia starych tokenów;
7. wznow pipeline dopiero po negatywnym teście egress i integralności.

Kontrole, które zatrzymują ten wzorzec

Pinning do pełnego SHA lub digestu. GitHub Actions powinny wskazywać pełny commit, obrazy OCI — digest sha256, a binaria — zweryfikowany checksum lub podpis. Tag może pozostać komentarzem informacyjnym.

Krótko żyjące tożsamości. OIDC federation do chmury ogranicza wartość wycieku w czasie, o ile polityka sub, repo, branch i audience jest zawężona. Stały access key w secret store ma znacznie większy blast radius.

Egress deny by default. Job skanera zwykle potrzebuje kilku repozytoriów i API. Nie powinien dowolnie łączyć się z internetem. DNS i proxy egress dają zarówno blokadę, jak i ślad.

Ephemeral runners. Jednorazowy runner ogranicza trwałość, lecz nie zapobiega kradzieży sekretu podczas joba. Musi działać z minimalną tożsamością, czystym obrazem i kontrolowanym cache.

Lockfile i pre-execution gate. Weryfikuj SRI, nowe zależności, pliki .pth, skrypty instalacyjne i zawartość pakietu przed uruchomieniem. Skaner bezpieczeństwa nie może sam zatwierdzać własnej integralności; kontrola powinna działać w osobnej warstwie z inną relacją zaufania.

Długoterminowa zmiana architektury

CI/CD jest środowiskiem produkcyjnym, nawet gdy tylko buduje kod. Wprowadź osobne konta dla build i deploy, podpisuj artefakty, generuj provenance, egzekwuj SLSA, używaj SBOM i promuj ten sam digest między środowiskami. Każda aktualizacja akcji lub narzędzia powinna przechodzić review, test w kwarantannie i kontrolę wydawcy.

Rozszerz ochronę łańcucha dostaw o Sigstore i SLSA, OIDC dla CI/CD i zarządzanie sekretami. Jeśli chcesz sprawdzić, co złośliwy job może dziś wykraść z Twojej organizacji, BreachRoad przeprowadzi kontrolowany audyt pipeline’ów.

---

Źródła: GitLab — analiza incydentów i polityk pipeline, Aqua Security — komunikat o Trivy, CISA KEV, repozytorium LiteLLM, repozytorium axios. Szczegóły poszczególnych incydentów należy weryfikować w aktualnych komunikatach projektów.