Wprowadzenie do problemu / definicja
Ataki na łańcuch dostaw systemu coraz częściej uderzają nie w gotowe aplikacje, ale w narzędzia, którym zespoły DevOps i AppSec ufają na co dzień. Incydent związany z Trivy pokazuje, iż kompromitacja popularnego skanera bezpieczeństwa może otworzyć drogę do przejęcia sekretów wykorzystywanych w pipeline’ach CI/CD, w tym poświadczeń chmurowych, kluczy SSH, tokenów dostępowych i danych konfiguracyjnych.
To szczególnie niebezpieczny scenariusz, ponieważ narzędzia bezpieczeństwa działają zwykle z podwyższonymi uprawnieniami i mają szeroki dostęp do środowiska budowania, testowania i wdrażania. W efekcie jedno naruszenie może przełożyć się na znacznie szerszą kompromitację infrastruktury niż w przypadku klasycznego incydentu aplikacyjnego.
W skrócie
W kampanii wymierzonej w Trivy napastnik uzyskał dostęp do uprzywilejowanych elementów procesu wydawniczego i wykorzystał go do podmiany zaufanych tagów wersji oraz publikacji zmodyfikowanych komponentów powiązanych z GitHub Actions. Złośliwy kod działał jak infostealer, przeszukując środowisko wykonawcze pod kątem sekretów i plików zawierających dane uwierzytelniające.
- celem były środowiska CI/CD korzystające z Trivy i powiązanych akcji,
- atak wykorzystał zaufanie do istniejących wersji zamiast podejrzanego nowego wydania,
- payload wyszukiwał sekrety, konfiguracje chmurowe i tokeny dostępu,
- ryzyko objęło nie tylko GitHub Actions, ale także wybrane artefakty kontenerowe i binaria.
Kontekst / historia
Tło incydentu sięga lutego 2026 roku, kiedy doszło do wykorzystania błędnej konfiguracji w komponencie GitHub Action powiązanym z Trivy. Pozwoliło to na przejęcie tokenu o wysokich uprawnieniach i wejście do automatyzacji repozytorium oraz procesu release. Choć początkowe naruszenie zostało ujawnione na początku marca, późniejsze ustalenia wskazały, iż wcześniejsze działania naprawcze nie odcięły atakującego całkowicie od środowiska.
Kolejna faza nastąpiła 19 marca 2026 roku, gdy utrzymany dostęp został wykorzystany do zmiany wielu wcześniej opublikowanych wersji akcji używanych do uruchamiania skanów w pipeline’ach. Mechanizm ten okazał się szczególnie skuteczny, ponieważ wiele organizacji przypina workflow do tagów wersji, zakładając ich niezmienność i integralność.
Incydent wpisuje się w rosnący trend ataków na narzędzia bezpieczeństwa, integracje CI/CD i procesy automatyzacji wydawniczej. Dla obrońców to kolejny sygnał, iż systemy budowania i wdrażania należy traktować jak zasoby krytyczne o bardzo wysokiej wartości operacyjnej.
Analiza techniczna
Technicznie był to wieloetapowy atak na łańcuch dostaw. Początkowy dostęp do uprzywilejowanego tokenu pozwolił na ingerencję w proces publikacji, a następnie na modyfikację komponentów wykorzystywanych bezpośrednio w zautomatyzowanych workflow. Zamiast ograniczać się do pojedynczego artefaktu, napastnik uderzył w elementy uruchamiane bezpośrednio przez pipeline’y.
Najgroźniejszym elementem operacji było nadpisanie istniejących tagów wersji. Oznacza to, iż workflow wskazujący deklaratywnie znaną wersję mógł pobrać inny kod niż wcześniej, choćby jeżeli plik pipeline’u nie został zmieniony. To klasyczny przykład zatrucia zaufanego punktu dystrybucji przy zachowaniu pozorów poprawności procesu.
Z ujawnionych analiz wynika, iż złośliwy payload przeszukiwał system plików i środowisko wykonawcze w poszukiwaniu wrażliwych danych. Interesowały go przede wszystkim:
- klucze SSH,
- poświadczenia dostawców chmurowych, w tym AWS, Google Cloud i Azure,
- tokeny uwierzytelniające Kubernetes,
- konfiguracje Dockera,
- pliki środowiskowe,
- dane dostępowe do baz danych,
- artefakty mogące zawierać wrażliwe informacje operacyjne.
Dane miały być szyfrowane z użyciem hybrydowego schematu obejmującego AES-256-CBC i RSA-4096, a następnie eksfiltrowane do infrastruktury kontrolowanej przez napastnika. W scenariuszach z ograniczeniami sieciowymi malware mógł wykorzystywać alternatywną metodę polegającą na utworzeniu publicznego repozytorium na koncie ofiary i przesłaniu tam przechwyconych danych.
Co istotne, zagrożenie nie ograniczało się wyłącznie do akcji GitHub. Ujawniono również wpływ na wybrane obrazy kontenerowe oraz co najmniej jedną wersję samego narzędzia opublikowaną przez skompromitowane konto automatyzacyjne. To znacząco poszerzało powierzchnię ataku i zwiększało liczbę potencjalnie dotkniętych organizacji.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem incydentu jest możliwość kompromitacji wszystkich sekretów dostępnych dla pipeline’ów uruchamiających podatne komponenty. W praktyce może to oznaczać przejęcie dostępu do kont chmurowych, klastrów Kubernetes, rejestrów kontenerów, repozytoriów kodu, środowisk deploymentowych czy systemów bazodanowych.
Ryzyko nie kończy się na pojedynczym wycieku. Sekrety używane w CI/CD często posiadają szerokie uprawnienia, umożliwiają publikację artefaktów, wdrożenia, modyfikację kodu lub ruch boczny między środowiskami deweloperskimi, testowymi i produkcyjnymi. Oznacza to, iż jeden skuteczny atak może prowadzić do kolejnych kompromitacji downstream.
Szczególnie alarmujący jest fakt, iż ofiarą padło narzędzie bezpieczeństwa. Organizacje zwykle uruchamiają takie komponenty z wysokim poziomem zaufania, aby mogły analizować obrazy, repozytoria, konfiguracje IaC i sekrety. W efekcie mechanizm wdrożony w celu poprawy bezpieczeństwa sam staje się uprzywilejowanym wektorem ataku.
Problemem pozostaje również ograniczona widoczność incydentu. o ile workflow odwoływał się do istniejącego tagu, a sam plik pipeline’u nie uległ zmianie, klasyczne mechanizmy code review i monitoringu mogły nie wykryć naruszenia odpowiednio wcześnie.
Rekomendacje
Organizacje korzystające z Trivy w CI/CD powinny potraktować ten incydent jako potencjalną kompromitację wszystkich sekretów dostępnych dla uruchamianych workflow w okresie ekspozycji. Najważniejszym krokiem jest natychmiastowa rotacja wszystkich poświadczeń, które mogły znaleźć się w zasięgu podatnych komponentów.
- obrócić klucze SSH,
- wymienić tokeny GitHub i inne tokeny SCM,
- zresetować poświadczenia chmurowe,
- zmienić sekrety Kubernetes,
- odnowić dane dostępowe do baz danych,
- wymienić hasła i tokeny do registry,
- przeanalizować wszystkie inne sekrety dostępne w runnerach.
Równolegle warto przeprowadzić działania operacyjne, które pozwolą określić skalę ryzyka i ograniczyć dalszą ekspozycję:
- wykonać audyt workflow używających Trivy i powiązanych akcji,
- sprawdzić logi pipeline’ów pod kątem nietypowych połączeń sieciowych i anomalii w buildach,
- ustalić, czy pobrano lub uruchomiono podejrzane wersje akcji, obrazów i binariów,
- usunąć z cache runnerów oraz rejestrów potencjalnie skażone artefakty,
- przeanalizować uprawnienia tokenów używanych przez CI/CD,
- ograniczyć uprawnienia zgodnie z zasadą najmniejszych uprawnień.
W dłuższej perspektywie najważniejsze są zmiany architektoniczne. Zamiast polegać wyłącznie na tagach wersji, warto przypinać akcje i obrazy do niezmiennych identyfikatorów, takich jak commit SHA lub digest obrazu. Dodatkowo należy rozważyć separację sekretów między środowiskami, stosowanie krótkotrwałych poświadczeń, izolację runnerów, egzekwowanie polityk egress oraz monitorowanie integralności zależności wykorzystywanych w buildach.
Dobrą praktyką jest także utrzymywanie pełnego inwentarza wszystkich zewnętrznych GitHub Actions używanych w organizacji, ich właścicieli, sposobu wersjonowania i poziomu zaufania. Bez takiej widoczności szybka reakcja na podobne incydenty pozostaje bardzo trudna.
Podsumowanie
Incydent związany z Trivy to jeden z wyraźniejszych przykładów nowoczesnego ataku na software supply chain, w którym zaufane narzędzie bezpieczeństwa zostało wykorzystane do kradzieży sekretów z pipeline’ów CI/CD. O skali zagrożenia decydują zarówno popularność samego narzędzia, jak i technika nadpisywania istniejących tagów oraz wykorzystanie skompromitowanego procesu release.
Dla zespołów bezpieczeństwa i DevOps wniosek jest jednoznaczny: środowiska CI/CD muszą być traktowane jak systemy krytyczne. Każda zewnętrzna akcja, obraz i narzędzie używane w procesie budowania oraz wdrażania powinny podlegać rygorystycznej kontroli integralności, uprawnień i poziomu zaufania.
Źródła
- Dark Reading — Trivy Supply Chain Attack Targets CI/CD Secrets — https://www.darkreading.com/application-security/trivy-supply-chain-attack-targets-ci-cd-secrets
- GitHub Advisory Database — GHSA-9p44-j4g5-cfx5 / CVE-2026-26189 — https://github.com/aquasecurity/trivy-action/security/advisories/GHSA-9p44-j4g5-cfx5
- NVD — CVE-2026-26189 — https://nvd.nist.gov/vuln/detail/CVE-2026-26189
- GitHub Repository — aquasecurity/trivy-action — https://github.com/aquasecurity/trivy-action
- Aqua Security Blog — Security update on Trivy supply chain incident — https://www.aquasec.com/blog/
