Łańcuch dostaw to powierzchnia ataku

title: “Łańcuch dostaw jest powierzchnią ataku” slug: the-supply-chain-is-the-attack-surface date: 2026-03-25 description: “Trivy został skompromitowany. Potem LiteLLM. Potem 47 000 instalacji w 46 minut. Łańcuch dostaw AI zadziałał dokładnie tak, jak został zaprojektowany.” tags: [ai, security, supply-chain, agents, engineering, trust, infrastructure] author: Blake Crosley category: AI & Technology series: “AI Engineering”

19 marca 2026 roku grupa zagrożeń o nazwie TeamPCP wykonała force-push 76 z 77 tagów wersji w repozytorium GitHub trivy-action firmy Aqua Security. Trivy jest najszerzej wdrożonym skanerem podatności open source w branży. Nowe tagi wskazywały na złośliwe commity zawierające program kradnący dane uwierzytelniające. Ponieważ większość pipeline’ów CI/CD odwołuje się do GitHub Actions za pomocą zmiennych tagów wersji zamiast przypiętych SHA commitów, każda organizacja uruchamiająca Trivy w swoim pipeline budowania natychmiast zaczęła wykonywać skompromitowany kod. Skany nadal wyglądały na udane. Skaner nadal raportował podatności. Jednocześnie cicho zbierał każdy sekret w środowisku runnera.¹

Pięć dni później, 24 marca, TeamPCP użył tokena publikacji PyPI skradzionego z jednego z tych środowisk CI, aby opublikować dwie wersje LiteLLM z backdoorem — popularnej biblioteki proxy AI obecnej w 36% środowisk chmurowych.² Wersja 1.82.8 zawierała plik .pth, który wykonuje się automatycznie przy każdym uruchomieniu Pythona, przed jakimkolwiek importem, przed jakimkolwiek sandboxem na poziomie aplikacji. Ładunek zbierał klucze SSH, dane uwierzytelniające chmury, hasła do baz danych, portfele kryptowalut i sekrety CI/CD, szyfrował je za pomocą zakodowanego na stałe klucza publicznego RSA i wysyłał archiwum do domeny kontrolowanej przez atakującego, zarejestrowanej dzień wcześniej.³

PyPI poddał kwarantannie obie wersje po 46 minutach. W tym oknie nastąpiło 46 996 instalacji.⁴ Opiekun LiteLLM usunął swoje konto GitHub, dokonał rotacji wszystkich kluczy i zaangażował Mandiant.⁵

Skaner bezpieczeństwa skanował. Pipeline budowania budował. Menedżer pakietów instalował. Każdy komponent zrobił dokładnie to, do czego został upoważniony.

TL;DR

• Łańcuch: Trivy (skaner bezpieczeństwa) skompromitowany 19 marca poprzez przejęcie tagów GitHub Actions. LiteLLM (proxy AI) skompromitowany 24 marca za pomocą tokena PyPI skradzionego ze środowiska CI zainfekowanego przez Trivy. 46 996 pobrań w 46 minut.⁴
• Technika: Wersja 1.82.8 wykorzystuje mechanizm .pth Pythona do uruchamiania programu kradnącego dane uwierzytelniające przy każdym wywołaniu python3 na zainfekowanym systemie, bez importowania LiteLLM.³
• Promień rażenia: 2 337 pakietów PyPI zależy od LiteLLM. 88% miało specyfikacje wersji pozwalające na zainstalowanie skompromitowanych wersji. Potwierdzony wpływ downstream na Google ADK, Stanford DSPy, MLflow, Guardrails AI i Cisco AI Defense SDK.⁴
• Kampania: TeamPCP uderzył w pięć ekosystemów w jednym tygodniu: GitHub Actions, Docker Hub, npm (CanisterWorm, 28+ pakietów), Open VSX (Checkmarx KICS) i PyPI (LiteLLM).⁶
• Lekcja strukturalna: Każde ogniwo w łańcuchu działało w ramach swojego autoryzowanego zakresu. Kompozycja autoryzowanych operacji wytworzyła nieautoryzowane zachowanie. To ta sama luka kompozycji, która umożliwia cichy wyciek na poziomie agenta i Clinejection na poziomie CI/CD. Ataki na łańcuch dostaw są atakami kompozycji.
• Co można zrobić: Przypiąć zależności do niezmiennych referencji. Odizolować dane uwierzytelniające publikacji od runnerów CI. Monitorować wychodzące żądania sieciowe na poziomie systemu operacyjnego. Traktować pip install jako wykonanie kodu, bo właśnie tym jest.

Skaner bezpieczeństwa wchodzi do Pana/Pani pipeline’u budowania

Atak rozpoczął się od błędnej konfiguracji w środowisku GitHub Actions Trivy pod koniec lutego 2026 roku. Atakujący wykorzystał podatny workflow pull_request_target, aby wyeksfiltrować osobisty token dostępu aqua-bot firmy Aqua Security. Aqua dokonała rotacji niektórych danych uwierzytelniających 1 marca, ale rotacja była niepełna. TeamPCP zachował ważne tokeny.¹

19 marca użyli tych tokenów do force-push 76 z 77 tagów wersji w repozytorium trivy-action i wszystkich 7 tagów w setup-trivy, przekierowując każdą zmienną referencję tagu na złośliwe commity. Uruchomili również automatyzację wydawania, aby opublikować złośliwy plik binarny Trivy jako v0.69.4.¹

Ładunkiem był program kradnący dane uwierzytelniające, który zrzucał pamięć procesu Runner.Worker, zbierał klucze SSH, dane uwierzytelniające chmury, sekrety Kubernetes, konfiguracje Docker, dane uwierzytelniające Git i pliki .env. Dane były szyfrowane AES-256 i 4096-bitowym kluczem RSA, a następnie wysyłane na serwery kontrolowane przez atakującego. Złośliwy kod działał równolegle z legalną funkcjonalnością Trivy. Skany kończyły się powodzeniem. Podatności były raportowane. Program kradzący działał w tle.⁷

Między 19 a 23 marca obrazy Docker Hub z tagami trivy:0.69.4, trivy:0.69.5, trivy:0.69.6 i trivy:latest były skompromitowane. CrowdStrike, Microsoft, Wiz i Palo Alto opublikowali analizy techniczne w ciągu kilku dni.⁷⁸⁹

Ironia jest strukturalna: organizacje najbardziej świadome bezpieczeństwa były najbardziej narażone. Jeśli uruchamiałeś/uruchamiałaś Trivy w CI, ponieważ zależy Ci na skanowaniu podatności, Twój pipeline budowania był tym, który zbierał dane uwierzytelniające.

Od skanera do złodzieja do proxy AI

Pipeline CI LiteLLM uruchamiał Trivy. Konkretnie, ci_cd/security_scans.sh instalował Trivy przez apt z repozytorium Aqua bez przypinania wersji.¹⁰ Podczas okna kompromitacji uruchomienie CI zainstalowało zatruty plik binarny Trivy, który zebrał PYPI_PUBLISH_PASSWORD ze środowiska GitHub Actions.

23 marca atakujący zarejestrował litellm.cloud. 24 marca o 10:39 UTC opublikował litellm==1.82.7 na PyPI używając skradzionych danych uwierzytelniających. Wersja 1.82.8 pojawiła się o 10:52 UTC.⁴

Dwie wersje używały różnych technik ataku. Wersja 1.82.7 osadziła ładunek w proxy_server.py, który uruchamia się przy import litellm.proxy. Wersja 1.82.8 dodała plik .pth do site-packages/, który uruchamia się przy każdym starcie interpretera Python. Mechanizm .pth jest legalną funkcją Pythona do konfiguracji ścieżek. Każdy plik kończący się na .pth umieszczony w site-packages/ jest automatycznie wykonywany przez site.py Pythona podczas inicjalizacji interpretera. Większość programistów Pythona nie wie, że ta funkcja istnieje.³

Ładunek w obu wersjach zbierał zmienne środowiskowe, klucze SSH, dane uwierzytelniające AWS/GCP/Azure, konfiguracje Kubernetes, hasła do baz danych, portfele kryptowalut i sekrety CI/CD. Szyfrował kolekcję AES-256-CBC używając losowego klucza sesji, opakowywał klucz sesji zakodowanym na stałe 4096-bitowym kluczem publicznym RSA i wysyłał archiwum przez HTTPS POST. Tylko atakujący może odszyfrować skradzione dane.³

Błąd w malware 1.82.8 uczynił go widocznym. Plik .pth uruchamia proces potomny Pythona, który ponownie wyzwala plik .pth, tworząc wykładniczą fork bomb. Andrej Karpathy zauważył błąd na X. Bez fork bomb program kradzący działałby cicho przy każdym wywołaniu Pythona na każdym zainfekowanym systemie, potencjalnie przez tygodnie przed wykryciem.⁴

PyPI poddał kwarantannie obie wersje o 11:25 UTC. Całkowity czas ekspozycji: 46 minut. Całkowita liczba pobrań: 46 996.⁴

Promień rażenia

LiteLLM jest pobierany około 3,4 miliona razy dziennie. Wiz informuje, że jest obecny w 36% środowisk chmurowych.² 46-minutowe okno ekspozycji wystarczyło.

FutureSearch przeanalizował logi pobrań BigQuery PyPI i stwierdził, że podczas okna ataku wersja 1.82.8 była pobierana 6 razy częściej niż jakakolwiek bezpieczna wersja. Pobrania zdecydowanie przechylały się w stronę pip (który rozpoznaje najnowszą wersję) w porównaniu z uv (który używa plików blokady). Z 46 996 pobrań 23 142 to instalacje pip v1.82.8, z których każda wykonała ładunek podczas samej instalacji, ponieważ plik .pth uruchamia się w procesie Pythona samego pip.⁴

2 337 pakietów na PyPI zależy od LiteLLM. 88% (2 054 pakiety) miało specyfikacje wersji pozwalające na instalację skompromitowanych wersji. Ekspozycja downstream obejmuje:⁴

Użytkownicy LiteLLM Cloud i Docker proxy nie zostali dotkńięci, ponieważ ich zależności były przypięte w requirements.txt. Różnica między „przypiętymi” a „nieprzypiętymi” była różnicą między skompromitowaniem a bezpieczeństwem.⁵

Pięć ekosystemów w jednym tygodniu

TeamPCP nie zatrzymał się na PyPI. Kampania uderzyła w pięć ekosystemów pakietów w szybkiej sekwencji:⁶

GitHub Actions (19 marca): 76 tagów trivy-action i wszystkie 7 tagów setup-trivy przejęte. Złośliwe pliki binarne Trivy v0.69.4 do v0.69.6 opublikowane.

Docker Hub (19-22 marca): Skompromitowane obrazy Trivy opublikowane jako aquasec/trivy:latest i tagi specyficzne dla wersji. Propagacja do mirror.gcr.io.

Open VSX (23 marca): GitHub Action Checkmarx KICS skompromitowany. 35 tagów przejętych między 12:58 a 16:50 UTC.²

npm (23-24 marca): CanisterWorm, samorozprzestrzeniający się robak, wdrożony w ponad 28 pakietach npm.

PyPI (24 marca): Wersje LiteLLM 1.82.7 i 1.82.8 opublikowane z ładunkami kradzącymi dane uwierzytelniające.

Każda kompromitacja ekosystemu wykorzystywała dane uwierzytelniające zebrane z poprzedniej. Kampania była skierowanym grafem eksploatacji zaufania, gdzie każdy skompromitowany węzeł dostarczał klucze do następnego.

Ataki na łańcuch dostaw są atakami kompozycji

Wzór strukturalny w kampanii TeamPCP jest tym samym wzorem, który opisałem w kontekście bezpieczeństwa agentów i cichego wycieku: indywidualnie autoryzowane komponenty składające się w nieautoryzowane zachowanie.

Trivy był autoryzowany do działania w CI. CI było autoryzowane do przechowywania danych uwierzytelniających publikacji. Menedżer pakietów był autoryzowany do instalowania pakietów. Każdy plik .pth był autoryzowany do konfigurowania ścieżek Pythona. Każde ogniwo w łańcuchu działało w ramach swojego zdefiniowanego zakresu. Kompozycja tych autoryzowanych operacji wytworzyła eksfiltracji danych uwierzytelniających na dużą skalę.

Atak Clinejection zademonstrował ten sam wzór na poziomie CI/CD: tytuł issue wstrzyknął adversarialny tekst do zautomatyzowanego pipeline’u Cline, który wykonał skrypt npm preinstall, który zatrował cache budowania, który skaził artefakty między-workflow. Każdy krok był indywidualnie autoryzowany.¹¹

Benchmark MCPTox zademonstrował to na poziomie agenta: złośliwe instrukcje osadzone w opisach narzędzi przekierowały agenty do eksfiltracji danych uwierzytelniających za pomocą legalnych narzędzi już obecnych na serwerze. Agent nigdy nie wykonał samego zatrutego narzędzia. Przeczytał zatruty opis i użył swoich własnych autoryzowanych narzędzi do przeprowadzenia ataku.¹²

Cichy wyciek demonstruje to na poziomie runtime: adversarialne instrukcje w metadanych stron internetowych skłaniają agenta do eksfiltracji kontekstu runtime poprzez wychodzące żądanie HTTP, które agent jest autoryzowany do wykonania.¹³

Powierzchnia ataku nie jest pojedynczym podatnym komponentem. Powierzchnia ataku jest kompozycją zaufanych komponentów. Zabezpieczenie poszczególnych ogniw nie zabezpiecza łańcucha. Trivy nie był podatnością. LiteLLM nie był podatnością. Podatnością była relacja zaufania między nimi, pośredniczona przez zmienne tagi wersji i nieprzypięte zależności.

Co naprawdę pomaga

Środki obrony, które zapobiegłyby każdemu etapowi tego ataku, są nudne. Są też tymi, które większość organizacji pomija.

Przypiąć do niezmiennych referencji. LiteLLM instalował Trivy przez apt bez przypinania wersji. Gdyby security_scans.sh przypiął do konkretnej wersji lub SHA commita, zatruty plik binarny v0.69.4 nigdy nie zostałby uruchomiony. GitHub Actions powinny odwoływać się do SHA commitów, nie zmiennych tagów. Różnica między uses: aquasecurity/[email protected] (skompromitowany) a uses: aquasecurity/trivy-action@57a97c7 (bezpieczny) to różnica między utratą danych uwierzytelniających publikacji a ich zachowaniem.¹

Odizolować dane uwierzytelniające publikacji od runnerów CI. PYPI_PUBLISH_PASSWORD było dostępne jako zmienna środowiskowa w runnerze GitHub Actions, w którym działał Trivy. Gdyby dane uwierzytelniające publikacji były odizolowane w oddzielnym workflow bez zależności od akcji stron trzecich, kompromitacja Trivy nie dostarczyłaby dostępu do PyPI. Trusted Publishers (OIDC) PyPI całkowicie eliminują przechowywane tokeny.⁵

Monitorować wychodzące żądania sieciowe. Program kradzący dane uwierzytelniające wyeksfiltrował dane przez HTTPS POST do models.litellm.cloud, domeny zarejestrowanej 24 godziny przed atakiem. Monitoring egressu flagujący żądania do nowo zarejestrowanych domen wykryłby to. Mój własny system hooków blokuje wychodzące żądania do domen nieumieszczonych na liście dozwolonych — ten sam wzór, który przechwyciłby tę eksfiltracji.¹⁴

Tę samą lekcję w produkcji nauczyłem się na własnej skórze. Zaufana ścieżka purge cache Cloudflare wywołała autoryzowane żądanie API, a mimo to wytworzyła błędny wynik, ponieważ otaczające zabezpieczenia były zbyt luźne. Ta porażka skłoniła mnie do dodania zatwierdzeń destrukcyjnych akcji i hooków preflight dla operacji o dużym wpływie, nie tylko list dozwolonych domen.

Traktować pip install jako wykonanie kodu. Plik .pth w site-packages/ wykonuje się przy każdym uruchomieniu Pythona. Nie ma rezygnacji. Nie ma sandboxa. Jeśli uruchamiasz pip install w środowisku CI z dostępem do danych uwierzytelniających, udzielasz dowolnego wykonania kodu każdej przechodniej zależności w pakiecie. Rozwiązaniem jest uruchomienie pip install w środowisku bez dostępu do danych uwierzytelniających, a następnie skopiowanie zainstalowanych pakietów do środowiska, które ich potrzebuje.

Używać plików blokady. Analiza FutureSearch wykazała, że pobrania przez uv (który używa plików blokady) znacznie rzadziej instalowały skompromitowane wersje niż pobrania przez pip (który rozpoznaje najnowszą wersję). Pliki blokady nie są pełną obroną, ale zapobiegają najczęstszej ekspozycji: nieprzypiętemu ograniczeniu wersji >= cicho aktualizującemu się do skompromitowanego wydania.⁴

Niewygodna implikacja

Kampania TeamPCP pokazuje, że bezpieczeństwo łańcucha dostaw nie jest drugorzędnym zagadnieniem stojącym za bezpieczeństwem aplikacji, bezpieczeństwem sieci i ochroną punktów końcowych. Dla organizacji uruchamiających agenty AI z dostępem do narzędzi, łańcuch dostaw jest główną powierzchnią ataku.

Agent AI wywołujący pip install w środowisku CI, pobierający URLe lub instalujący serwery MCP komponuje relacje zaufania w czasie działania. Każda operacja jest autoryzowana. Kompozycja może nie być. Paradoks wdrażania i obrony to przyspiesza: organizacje wdrażają agenty szybciej niż audytują łańcuchy zaufania, które ci agenci komponują.

Błąd fork bomb w LiteLLM 1.82.8 był jedynym powodem, dla którego ten atak został szybko wykryty. Bez tego błędu implementacji program kradzący dane uwierzytelniające działałby cicho przy każdym wywołaniu Pythona na każdym zainfekowanym systemie. 46 996 instalacji w 46 minut. 36% środowisk chmurowych. 2 337 downstream pakietów. Atakujący popełnił błąd. Następnym razem może tego nie zrobić.

Aktualizacja — 31 marca 2026: inny wektor, ten sam rezultat

Sześć dni po publikacji tego wpisu npm doświadczył kolejnego incydentu. 31 marca Jason Saayman, opiekun pakietu axios, ujawnił, że jego osobisty komputer został skompromitowany w wyniku ukierunkowanej kampanii socjotechnicznej, po której nastąpiła infekcja złośliwym oprogramowaniem typu remote access trojan. Napastnicy wykorzystali jego dane uwierzytelniające npm do opublikowania axios 1.14.1 oraz 0.30.4 — obie wersje wprowadzały nową zależność o nazwie [email protected], która instalowała wieloplatformowego RAT-a na systemach macOS, Windows i Linux. Złośliwe wersje były dostępne przez około trzy godziny, zanim społeczność przeprowadziła triage incydentu, a npm je usunął.¹⁶

Wektor ataku na axios różnił się od TeamPCP. Nie było skompromitowanego runnera CI, żadnych danych uwierzytelniających wykradzionych ze skanera bezpieczeństwa strony trzeciej, żadnego wieloekosystemowego robaka. Kampania wymierzona w Saaymana trwała mniej więcej dwa tygodnie przed publikacją, a kompromitacja przeszła przez osobiste urządzenie opiekuna prosto do potoku publikacyjnego npm. Remediacja wymagała całkowitego wyczyszczenia wszystkich jego urządzeń oraz rotacji każdego poświadczenia na każdej platformie, z jakiej kiedykolwiek korzystał — osobistej czy innej. Infrastrukturą C2 była domena sfrclak[.]com pod adresem 142.11.206.73:8000.¹⁶

Wniosek strukturalny pozostaje ten sam. Łańcuch zaufania obejmuje obecnie uwagę i czujność opiekuna jako swoje ogniwa — indywidualnie autoryzowane operacje składające się na nieautoryzowane zachowanie, gdy manipulacji ulega człowiek będący częścią tego łańcucha. Środki zaradcze przyjmowane przez zespół axios (publikowanie z wykorzystaniem OIDC, niezmienne wydania, izolacja urządzeń)¹⁶ adresują tę samą lukę kompozycyjną, którą obnażyła sekwencja od Trivy do LiteLLM: poświadczenia publikacyjne przechowywane w miejscach, do których mogą dotrzeć przeciwnicy, którzy już skompromitowali coś sąsiedniego.

Trzy godziny. 46 minut. Takie są obecnie okna czasowe, w których operują nowoczesne ataki na łańcuch dostaw. Pinning i pliki lock pozostają podstawową linią obrony — użytkownicy axios, którzy wykonali świeże instalacje poza oknem 00:21–03:15 UTC 31 marca, pozostali nietknięci.¹⁶

FAQ

Jak sprawdzić, czy zostałem/zostałam dotknIęta/dotknIęty?

Przeszukaj logi CI i lokalne środowiska pod kątem wersji LiteLLM 1.82.7 lub 1.82.8 zainstalowanych między 10:39 a 11:25 UTC 24 marca 2026 roku. Jeśli którakolwiek wersja została zainstalowana, dokonaj rotacji wszystkich danych uwierzytelniających, które były dostępne jako zmienne środowiskowe, klucze SSH lub pliki konfiguracyjne na tym systemie. Oficjalne wytyczne LiteLLM zalecają traktowanie każdego systemu, który uruchomił skompromitowane wersje, jako w pełni skompromitowanego.⁵

Który identyfikator ostrzeżenia powinienem/powinnam śledzić?

Śledź PYSEC-2026-2 w OSV i bazie danych ostrzeżeń PyPA. OSV wymienia również incydent jako MAL-2026-2144. Na dzień 25 marca 2026 roku publiczna strona ostrzeżeń OSV nie wymienia aliasu CVE dla złośliwych wydań LiteLLM, dlatego zespoły reagowania na incydenty powinny opierać się na wersjach, których dotyczy problem, oknie instalacji i PYSEC-2026-2.¹⁵

Czy użytkownicy LiteLLM Cloud lub Docker proxy zostali dotknIęci?

Nie. LiteLLM Cloud i oficjalny obraz Docker proxy przypinają zależności w requirements.txt, zapobiegając automatycznemu rozpoznawaniu do skompromitowanych wersji. Tylko użytkownicy, którzy zainstalowali LiteLLM przez pip install litellm (nieprzypięty) podczas 46-minutowego okna, zostali dotknIęci.⁵

Co to jest plik .pth i dlaczego jest niebezpieczny?

Plik .pth jest funkcją Pythona do konfigurowania ścieżek wyszukiwania modułów. Każdy plik kończący się na .pth umieszczony w katalogu site-packages/ jest odczytywany i wykonywany przez moduł site.py Pythona podczas inicjalizacji interpretera. Dzieje się to przed jakimkolwiek instrukcją import, przed jakimkolwiek kodem aplikacji i przed jakimkolwiek sandboxem na poziomie Pythona. Mechanizm jest udokumentowany w standardowej bibliotece Pythona, ale nie jest powszechnie znany wśród programistów aplikacji. Jest to legalna funkcja używana jako wektor ataku.³

Czy to jest związane z atakiem na łańcuch dostaw Trivy?

Tak. Kompromitacja LiteLLM była bezpośrednią konsekwencją kompromitacji Trivy. TeamPCP skompromitował GitHub Actions Trivy 19 marca, co pozwoliło na zebranie danych uwierzytelniających CI/CD od organizacji uruchamiających Trivy w swoich pipeline’ach budowania. Jednym z tych danych uwierzytelniających był token publikacji PyPI LiteLLM. Atakujący użył tego tokena do opublikowania złośliwych wersji LiteLLM pięć dni później.¹⁰

Co to jest TeamPCP?

TeamPCP (również śledzony jako DeadCatx3, PCPcat, ShellForce, CipherForce) jest grupą zagrożeń, która przeprowadziła wieloekosystemową kampanię ataku na łańcuch dostaw w marcu 2026 roku, kompromitując pakiety w GitHub Actions, Docker Hub, npm, Open VSX i PyPI. Grupa użyła technik zbierania danych uwierzytelniających, przejmowania tagów i samorozprzestrzeniających się robaków w pięciu ekosystemach pakietów w ciągu około jednego tygodnia.⁶

Jak to się ma do bezpieczeństwa agentów AI?

Agenty AI instalujące pakiety, pobierające URLe lub łączące się z serwerami MCP komponują relacje zaufania w czasie działania. Każda operacja jest indywidualnie autoryzowana. Kompozycja tych operacji może wytworzyć nieautoryzowane zachowanie, jak pokazują cichy wyciek (poziom agenta), Clinejection (poziom CI/CD) i ten atak (poziom łańcucha dostaw). Monitoring zachowania w czasie działania, listy dozwolonych domen i izolacja danych uwierzytelniających odpowiadają na lukę kompozycji na różnych warstwach stosu.¹⁴

Źródła