Na pierwszy rzut oka incydent wokół Trivy wygląda jak klasyczny supply chain attack: przejęte poświadczenia, złośliwe wydania, skażone akcje GitHub Actions, kradzież sekretów z pipeline’ów. To wszystko jest prawdą. Ale jeśli spojrzeć głębiej, widać coś ciekawszego: to nie był tylko atak na narzędzie. To był atak na zaufanie do automatyzacji. Aqua podała, że 19 marca 2026 napastnik użył skompromitowanych poświadczeń do opublikowania złośliwego wydania Trivy 0.69.4, a także podmienił tagi w trivy-action i setup-trivy. GitHub advisory potwierdza, że tego samego dnia przestawiono praktycznie wszystkie tagi wersji trivy-action na commity ze credential-stealing malware.
I właśnie dlatego ten case warto czytać nie tylko jako historię o kompromitacji open source, ale jako Contagious Interview przeniesione do CI/CD. W tamtej kampanii wykonawcą był developer, który w zaufanym workflow uruchamiał obcy kod, bo wszystko wyglądało jak normalna praca. W incydencie Trivy wykonawcą staje się pipeline. Nadal działa zgodnie ze swoją rolą. Nadal używa legalnych narzędzi. Nadal robi to, do czego został zaprojektowany. Problem polega na tym, że ktoś podmienił elementy kontekstu, którym pipeline ufał. To wystarczyło, by z automatyzacji zrobić kanał wykonania.
Nie złośliwy plik, tylko zaufany proces
Najmocniejsza lekcja z Trivy jest taka, że ofiara nie musiała zrobić niczego niezwykłego. Nie trzeba było nikogo przekonywać do pobrania podejrzanego pliku z egzotycznego źródła. Wystarczyło, że organizacje dalej korzystały z oficjalnych referencji do akcji GitHub Actions, które nagle zaczęły wskazywać na złośliwą treść. Socket i The Hacker News opisały, że w aquasecurity/trivy-action napastnik force-pushował 75 z 76 tagów wersji, zamieniając zaufane odniesienia w mechanizm dystrybucji infostealera. GitHub advisory mówi nawet o 76 z 77 tagów, więc bezpieczniej pisać, że przejęto praktycznie cały zestaw tagów wersji.
To ważne rozróżnienie. W klasycznym myśleniu o supply chain security zwykle skupiamy się na artefakcie: pakiecie, obrazie, release’ie, zależności. Tutaj jednak realna siła ataku wzięła się z tego, że normalny proces CI/CD sam uruchomił to, czego nie powinien. Nie dlatego, że pipeline „zwariował”, ale dlatego, że nadal ufał oficjalnie wyglądającym punktom odniesienia. To bardzo współczesny typ kompromitacji: nie łamiesz automatyzacji brutalnie, tylko podstawiasz jej kontekst, który wygląda na własny.
Pipeline jako wykonawca
I tu analogia do Contagious Interview robi się naprawdę użyteczna. W tamtym scenariuszu developer nie wykonywał jawnie podejrzanej czynności. Klonował repozytorium, uruchamiał projekt, przechodził przez coś, co wyglądało jak zwykły test techniczny. W Trivy pipeline też nie robi nic „dziwnego”. Odpala akcję, pobiera zależność, uruchamia skaner, korzysta z sekretów potrzebnych do pracy. Tyle że cały ten zdrowy workflow zostaje wykorzystany jako kanał sterowania. W efekcie automatyzacja nie tyle zawodzi, co wiernie realizuje skażony kontekst.
To nie jest tylko efektowna metafora. The Hacker News opisał, że payload wykonywany w runnerach GitHub Actions był zaprojektowany do kradzieży cennych sekretów deweloperskich, w tym kluczy SSH, poświadczeń dostawców chmurowych, konfiguracji Git i Dockera, tokenów Kubernetes, a nawet portfeli kryptowalutowych. CrowdStrike potwierdza, że kompromitacja obejmowała oficjalne skrypty i binaria Trivy oraz że złośliwe artefakty zostały szybko usunięte po wykryciu.
Zaufane referencje stają się interfejsem ataku
I właśnie tu zaczyna się najciekawsza część tej historii. W dobrze działającym CI/CD tag, release albo oficjalna akcja to nie tylko wygoda. To element porządkujący zaufanie. Mówi zespołowi: „to jest właściwe miejsce, z którego wolno korzystać”. W incydencie Trivy to właśnie te znaczniki zostały wykorzystane jako mechanizm dostarczenia malware. Czyli rzeczy, które miały porządkować automatyzację, nagle stały się jej interfejsem ataku.
To powinno mocno wybrzmieć w security: problemem nie jest już wyłącznie pytanie co uruchamiasz, ale też komu i czemu w procesie wykonania przyznałeś zaufanie. Jeśli pipeline działa na podstawie tagów, zewnętrznych akcji i sekretów środowiskowych, to nie jest neutralną rurą. To aktywny wykonawca z realną mocą sprawczą. A każdy wykonawca z przywilejami, tokenami i dostępem do środowisk staje się atrakcyjnym celem.
Blast radius był większy niż jeden release
Ta historia robi się jeszcze ciekawsza, gdy spojrzeć na jej dalszy ciąg. GitHub advisory podał, że 22 marca 2026 napastnik użył skompromitowanych poświadczeń do opublikowania także złośliwych obrazów Docker Hub 0.69.5 i 0.69.6, a The Hacker News opisał, że ostatnią znaną czystą wersją na Docker Hub było 0.69.3. W tej samej analizie wskazano, że modyfikacje w repozytoriach zostały wykonane skryptowo w bardzo krótkim oknie czasowym, a z wysokim prawdopodobieństwem użyto przejętego konta serwisowego Argon-DevOps-Mgt.
To ważne, bo pokazuje długi ogon takich kompromitacji. Nie chodzi tylko o jeden złośliwy release. Chodzi o to, że raz przejęte zaufanie w automatyzacji może później służyć do ruchów bocznych, persistence i rozszerzania blast radius. W praktyce incydent przestał być problemem jednego artefaktu i stał się problemem całego układu zależności: GitHub Actions, tagów, obrazów, kont serwisowych i sekretów dostępnych dla runnerów.
Czego Trivy uczy o nowoczesnym security
I tu dochodzimy do właściwej lekcji. W CI/CD nie wystarczy już pytać: „czy ten artefakt jest czysty?”. Trzeba pytać szerzej:
czy ten workflow ma zbyt szerokie zaufanie?
czy ten runner widzi za dużo sekretów?
czy konto serwisowe łączy zbyt wiele środowisk?
czy zewnętrzna akcja może zostać podmieniona bez zmiany, którą zauważy człowiek?
Incydent Trivy pokazuje, że standardowe założenie „to oficjalna akcja, więc jest bezpieczna” jest dziś zbyt słabe. Oficjalność nie chroni przed kompromitacją, jeśli atakujący przejmie sam mechanizm odniesienia.
To jest dokładnie ta sama zmiana paradygmatu, którą widać dziś także w atakach na agentów AI. Nie wystarczy analizować złośliwy input. Trzeba patrzeć na wykonawcę, jego możliwości i jego kontekst. W przypadku agentów mówimy o prompt injection i uprawnieniach. W przypadku CI/CD mówimy o tagach, akcjach, runnerach, secretach i kontach serwisowych. Ale wzór pozostaje ten sam:
zaufany kontekst → legalne narzędzie → wykonawca działający zgodnie z rolą → szkodliwy efekt.
Ten właśnie wzór robi z Trivy coś więcej niż kolejny incydent supply chain. Robi z niego bardzo dobrą lekcję o tym, jak dziś działa kompromitacja zaufania.
Podsumowanie
Contagious Interview pokazało, że można wykorzystać naturalny workflow developera.
Trivy pokazuje, że dokładnie to samo można zrobić z naturalnym workflow CI/CD.
Zmienia się wykonawca. Wzór zostaje ten sam. A to oznacza, że bezpieczeństwo coraz mniej dotyczy wyłącznie „złośliwego pliku”, a coraz bardziej tego, jakie procesy wykonują cudzą logikę pod przykrywką własnego, legalnego działania.
Źródła
- Aqua Security — Trivy Supply Chain Attack: What Happened and What You Need to Know. Aqua opisuje, że 19 marca 2026 użyto skompromitowanych poświadczeń do publikacji złośliwego Trivy 0.69.4, trivy-action i setup-trivy, a incydent był częścią szerszego, wieloetapowego ataku.
- GitHub Security Advisory — Trivy ecosystem supply chain temporarily compromised. Advisory potwierdza przejęcie tagów trivy-action, podmianę wszystkich tagów setup-trivy oraz późniejsze złośliwe obrazy Docker Hub 0.69.5 i 0.69.6.
- The Hacker News — Trivy Security Scanner GitHub Actions Breached, 75 Tags Hijacked to Steal CI/CD Secrets. Opis przejęcia tagów, działania payloadu w GitHub Actions oraz kradzieży sekretów z pipeline’ów.
- The Hacker News — Trivy Hack Spreads Infostealer via Docker, Triggers Worm and Kubernetes Wiper. Materiał o dalszym rozszerzaniu blast radius przez Docker Hub i kompromitację konta serwisowego.
- CrowdStrike — From Scanner to Stealer: Inside the trivy-action Supply Chain Compromise. Techniczny opis ataku, payloadu i reakcji po stronie Aqua.
