Archiwa: DevSecOps - Strona 6 z 11

TeamPCP kompromituje GitHub Actions Checkmarx, wykorzystując skradzione poświadczenia CI

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania coraz częściej uderzają w środowiska CI/CD, ponieważ to właśnie tam przetwarzane są tokeny, sekrety oraz poświadczenia do repozytoriów i usług chmurowych. Najnowszy incydent przypisywany grupie TeamPCP pokazuje, że przejęcie zaufanego elementu pipeline’u może stać się punktem wyjścia do dalszej kompromitacji projektów, narzędzi deweloperskich i infrastruktury organizacji.

W opisywanym przypadku celem były workflowy GitHub Actions utrzymywane przez Checkmarx. Atakujący mieli wykorzystać złośliwy ładunek kradnący dane z runnerów CI, co wpisuje się w rosnący trend nadużywania zaufanych komponentów automatyzacji do przejmowania kolejnych etapów procesu wytwarzania oprogramowania.

W skrócie

TeamPCP miało skompromitować dwa workflowy GitHub Actions powiązane z Checkmarx.
Złośliwy kod służył do kradzieży poświadczeń i sekretów z runnerów CI.
Atak przypomina wcześniejsze działania obserwowane w kampanii związanej z Trivy.
Napastnicy mogli wykorzystywać przejęte dane do modyfikacji tagów, publikacji skażonych artefaktów i dalszej eksfiltracji informacji.
Dodatkowym elementem operacji były trojanizowane rozszerzenia publikowane w ekosystemie Open VSX.

Kontekst / historia

Incydent nie wygląda na odosobnione zdarzenie. Z dostępnych analiz wynika, że TeamPCP było wcześniej łączone z kompromitacją innych elementów ekosystemu bezpieczeństwa i DevSecOps, w tym komponentów związanych z Trivy. Wspólne cechy obejmują podobny typ malware kradnącego dane, zbliżony sposób eksfiltracji oraz schemat działania skoncentrowany na środowiskach chmurowych, pipeline’ach buildów i repozytoriach kodu.

W przypadku Checkmarx wskazano dwa projekty GitHub Actions jako dotknięte kompromitacją. Pojawiły się także informacje o przejęciu konta usługowego używanego do publikacji komponentów oraz o wypuszczeniu złośliwych wersji rozszerzeń deweloperskich. Jednocześnie komunikaty producenta sugerowały brak wpływu na dane klientów i środowiska produkcyjne, co nie zmienia faktu, że organizacje korzystające z zagrożonych artefaktów powinny traktować zdarzenie jako pełnoprawny incydent bezpieczeństwa.

Analiza techniczna

Trzonem ataku był złośliwy skrypt typu stealer osadzony w zaufanych akcjach GitHub poprzez manipulację tagami i przekierowanie ich na złośliwe commity. Taka technika jest szczególnie skuteczna w organizacjach, które przypinają zależności CI/CD do tagów wersji zamiast do pełnych identyfikatorów commitów. W efekcie pipeline może uruchomić zmodyfikowaną akcję bez jakichkolwiek zmian widocznych w konfiguracji.

Zadaniem ładunku było pozyskiwanie danych z runnera CI, w tym kluczy SSH, tokenów GitHub, poświadczeń do AWS, Google Cloud i Microsoft Azure, konfiguracji Kubernetes i Dockera, plików środowiskowych oraz innych sekretów używanych w trakcie budowania i testowania oprogramowania. Taki zakres zbieranych informacji sugeruje, że celem operacji nie było tylko przejęcie pojedynczego repozytorium, ale uzyskanie możliwości dalszego poruszania się po infrastrukturze ofiary.

Istotnym elementem było także ukrywanie eksfiltracji danych. Ruch wychodzący miał być kierowany do infrastruktury podszywającej się pod legalny zasób związany z ofiarą, co utrudnia wykrycie podczas pobieżnej analizy logów. Dodatkowo malware mogło tworzyć repozytorium zapasowe z wykorzystaniem tokena ofiary, aby przechowywać wykradzione dane wtedy, gdy bezpośrednia eksfiltracja do serwera kontrolowanego przez napastników nie była możliwa.

Najgroźniejszy był jednak efekt kaskadowy. Jeśli runner CI uruchamiał skażoną akcję i jednocześnie dysponował tokenem z uprawnieniami zapisu do innych repozytoriów, napastnicy mogli wykorzystać przejęte dane do kompromitacji kolejnych projektów. W praktyce taki model prowadzi do samonapędzającego się ataku supply chain, w którym jedno zatrute ogniwo umożliwia skażenie następnych.

Dodatkowym wektorem były zainfekowane rozszerzenia dla środowisk programistycznych publikowane w Open VSX. Po instalacji taki komponent miał sprawdzać obecność poświadczeń do usług chmurowych i platform deweloperskich, a następnie pobierać kolejny etap ładunku. Na systemach niebędących runnerami CI złośliwe oprogramowanie mogło również ustanawiać mechanizm przetrwania, rozszerzając zagrożenie na stacje robocze programistów.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tego typu incydentu jest utrata integralności zaufanych komponentów procesu wytwarzania oprogramowania. Jeżeli organizacja korzystała z zainfekowanych GitHub Actions lub trojanizowanych rozszerzeń, mogło dojść do wycieku tokenów, kluczy oraz danych dostępowych do środowisk chmurowych i repozytoriów kodu.

Ryzyko nie kończy się na samym wycieku. Przejęte poświadczenia mogą zostać użyte do modyfikacji kodu źródłowego, publikacji złośliwych artefaktów, przejmowania nowych repozytoriów, a nawet uzyskania dostępu do systemów uruchomieniowych. W środowiskach wielochmurowych oraz zintegrowanych z Kubernetes konsekwencje mogą obejmować eskalację do kontroli nad kontenerami, klastrami i usługami produkcyjnymi.

Dodatkowym problemem jest niska wykrywalność takiej operacji. Tradycyjne przeglądy kodu i skanowanie zależności nie zawsze wychwytują kompromitację, jeśli złośliwy kod został wstrzyknięty bezpośrednio do zaufanej akcji u źródła. Organizacja może więc przez dłuższy czas uruchamiać legalnie wyglądający komponent, który poza deklarowaną funkcją potajemnie kradnie sekrety.

Rekomendacje

Organizacje, które mogły korzystać z zagrożonych artefaktów, powinny w pierwszej kolejności przeprowadzić pełną rotację wszystkich sekretów dostępnych dla runnerów CI w okresie potencjalnej kompromitacji. Obejmuje to tokeny GitHub, klucze SSH, dane dostępowe do chmury, sekrety Kubernetes, poświadczenia bazodanowe oraz wartości przechowywane w zmiennych środowiskowych.

Przejrzeć logi workflowów pod kątem nietypowych połączeń wychodzących, archiwów i nowych repozytoriów tworzonych automatycznie.
Zweryfikować historię tagów wersji i sprawdzić, czy nie doszło do force-push lub nieautoryzowanych zmian wskaźników.
Przypinać GitHub Actions do pełnych SHA commitów zamiast do tagów lub ruchomych wersji.
Ograniczyć uprawnienia tokenów i kont serwisowych zgodnie z zasadą najmniejszych uprawnień.
Segmentować sieć runnerów oraz ograniczyć ruch wychodzący wyłącznie do zatwierdzonych lokalizacji.
Monitorować tworzenie nietypowych repozytoriów, publikację nowych artefaktów i rozszerzeń poza zatwierdzonym pipeline’em.
Sprawdzić stacje deweloperskie pod kątem mechanizmów trwałości i podejrzanych rozszerzeń.

Z perspektywy strategicznej kluczowe jest traktowanie runnerów CI jako systemów uprzywilejowanych o wysokiej wartości. Każdy sekret dostępny podczas builda może mieć skutki wykraczające daleko poza jedno repozytorium, dlatego ochrona integralności pipeline’u powinna być priorytetem zarówno dla zespołów bezpieczeństwa, jak i dla inżynierów platformowych.

Podsumowanie

Incydent przypisywany TeamPCP pokazuje, że nowoczesna kompromitacja łańcucha dostaw nie musi zaczynać się od wykorzystania klasycznej podatności. Wystarczy przejęcie poświadczeń CI i możliwość manipulacji zaufanym artefaktem, aby uruchomić efekt domina obejmujący repozytoria, rozszerzenia deweloperskie i środowiska chmurowe.

Dla organizacji najważniejszą lekcją jest konieczność wdrożenia twardych kontroli integralności, ograniczonych uprawnień, monitoringu anomalii oraz szybkiej rotacji sekretów po każdym podejrzeniu kompromitacji. CI/CD nie może być traktowane wyłącznie jako warstwa automatyzacji — to dziś jeden z najbardziej krytycznych elementów całego krajobrazu bezpieczeństwa.

Źródła

CanisterWorm: destrukcyjny wiper wymierzony w środowiska powiązane z Iranem

Wprowadzenie do problemu / definicja

CanisterWorm to nazwa kampanii destrukcyjnej przypisywanej grupie TeamPCP, w której wykorzystano komponent typu wiper do bezpowrotnego usuwania danych. Operacja zwraca uwagę połączeniem technik typowych dla cyberprzestępczości nastawionej na zysk z selektywnym niszczeniem systemów na podstawie ustawień regionalnych, takich jak strefa czasowa Iranu czy domyślny język perski.

To ważny przykład zmiany charakteru zagrożeń w środowiskach chmurowych i kontenerowych. Ataki nie kończą się już wyłącznie na kradzieży poświadczeń, eksfiltracji danych lub wymuszeniu okupu, ale coraz częściej obejmują również działania sabotażowe nastawione na trwałe zniszczenie zasobów.

W skrócie

Kampania CanisterWorm została zaobserwowana w marcu 2026 roku i jest łączona z grupą TeamPCP, znaną z automatyzacji ataków na źle zabezpieczone usługi chmurowe. W przeszłości aktor ten koncentrował się na przejmowaniu środowisk z wystawionymi interfejsami Docker API, klastrami Kubernetes, serwerami Redis oraz na wykorzystywaniu podatności takich jak React2Shell.

W najnowszej odsłonie operatorzy wdrożyli ładunek destrukcyjny, który aktywował się po wykryciu powiązania systemu z Iranem. Jeśli malware uznał środowisko za zgodne z określonym profilem, uruchamiał proces usuwania danych lokalnie lub na poziomie całego klastra Kubernetes.

Kampania łączy elementy kradzieży danych, utrzymania dostępu i destrukcji.
Selekcja ofiar odbywa się m.in. na podstawie ustawień regionalnych systemu.
Ryzyko szczególnie dotyczy środowisk cloud-native i słabo zabezpieczonych usług administracyjnych.

Kontekst / historia

TeamPCP pojawił się pod koniec 2025 roku jako grupa działająca przede wszystkim w modelu cloud-first. Zamiast koncentrować się na stacjach roboczych użytkowników, atakujący skupiali uwagę na publicznie dostępnym zapleczu infrastrukturalnym, w tym na błędnie skonfigurowanych usługach administracyjnych oraz elementach orkiestracji kontenerów.

Z czasem działalność grupy zaczęła obejmować kilka równoległych celów: budowę botnetu, przejmowanie infrastruktury, kradzież poświadczeń, eksfiltrację danych i wymuszenia. Kampania CanisterWorm wpisuje się w tę ewolucję, ale idzie krok dalej, ponieważ końcowym etapem może być trwałe niszczenie danych.

Istotnym tłem dla tej operacji są wcześniejsze incydenty związane z kompromitacją łańcucha dostaw. Pojawiły się informacje o złośliwych modyfikacjach dystrybuowanych przez komponenty powiązane z narzędziami Trivy i KICS, których celem miała być kradzież kluczy SSH, poświadczeń chmurowych, tokenów Kubernetes oraz innych sekretów. To pokazuje, że TeamPCP nie ogranicza się do prostego skanowania internetu pod kątem błędnych konfiguracji, ale potrafi również zwiększać skalę działania poprzez naruszenie zaufanych kanałów dostarczania oprogramowania.

Analiza techniczna

Od strony technicznej kampania opiera się na znanych, ale skutecznie zautomatyzowanych metodach. TeamPCP wykorzystuje skrypty i narzędzia do masowego wyszukiwania podatnych lub niewłaściwie skonfigurowanych usług, a następnie wdraża komponenty odpowiedzialne za utrzymanie dostępu, ruch boczny, tunelowanie oraz dalsze skanowanie internetu.

W analizach aktywności grupy wskazywano m.in. na nadużywanie wystawionych Docker API, serwerów Redis, dashboardów Ray oraz podatności React2Shell. To zestaw technik szczególnie groźnych dla organizacji, które intensywnie korzystają z konteneryzacji, automatyzacji i rozproszonych środowisk uruchomieniowych.

Najważniejszym elementem CanisterWorm był jednak warunkowo aktywowany ładunek destrukcyjny. Mechanizm sprawdzał ustawienia regionalne systemu, zwłaszcza strefę czasową oraz konfigurację językową. Jeśli host odpowiadał profilowi ofiary powiązanej z Iranem, malware inicjowało proces wymazywania danych.

W przypadku uzyskania dostępu do klastra Kubernetes skutki mogły wykraczać poza pojedynczą maszynę. Zniszczenie mogło objąć wiele węzłów, wolumenów i usług, co oznacza przejście od incydentu ograniczonego do jednego hosta do sabotażu na poziomie całego środowiska kontenerowego.

Dodatkowo infrastruktura grupy miała wykorzystywać tzw. canistery oparte na Internet Computer Protocol do orkiestracji kampanii i hostowania złośliwych komponentów. Z perspektywy obrony ma to znaczenie praktyczne, ponieważ rozproszony model publikacji utrudnia szybkie wyłączenie infrastruktury i osłabia skuteczność klasycznych działań typu takedown. Atakujący mieli też dynamicznie modyfikować ładunki i tymczasowo usuwać je z dystrybucji, co utrudnia analizę oraz oszacowanie pełnej skali kompromitacji.

Wzorzec działania sugeruje więc nie pojedynczy malware, lecz szerszy ekosystem operacyjny obejmujący kilka etapów:

uzyskanie dostępu do infrastruktury,
kradzież poświadczeń i sekretów,
utrzymanie trwałości w środowisku,
eksfiltrację danych,
uruchomienie komponentu destrukcyjnego jako etapu końcowego.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem kampanii jest ryzyko nieodwracalnej utraty danych. W środowiskach Kubernetes konsekwencje mogą objąć jednocześnie wiele węzłów, wolumenów i usług, co przekłada się na długotrwałe przestoje operacyjne, utratę integralności danych oraz kosztowny proces odtwarzania.

Jeśli przed uruchomieniem wipera doszło do kradzieży poświadczeń, organizacja może jednocześnie mierzyć się z dwiema kategoriami incydentu: zniszczeniem systemów i wtórnym wykorzystaniem wykradzionych sekretów. Taki scenariusz znacząco komplikuje reakcję, ponieważ samo odtworzenie środowiska nie eliminuje ryzyka dalszych nadużyć.

Dla organizacji korzystających z pipeline’ów CI/CD oraz zautomatyzowanego pobierania artefaktów zagrożenie ma dodatkowy wymiar. Kompromitacja narzędzia bezpieczeństwa lub skanera może stać się wektorem wejścia do środowiska produkcyjnego, co podważa tradycyjne założenie wysokiego zaufania do narzędzi DevSecOps.

Podwyższone ryzyko dotyczy szczególnie organizacji, które:

eksponują usługi administracyjne bez silnego uwierzytelniania i segmentacji,
przechowują sekrety w pipeline’ach w sposób niewystarczająco chroniony,
nie ograniczają uprawnień dla mechanizmów automatyzacji, takich jak workflow CI/CD,
nie monitorują aktywności w klastrach Kubernetes pod kątem anomalii destrukcyjnych,
nie posiadają przetestowanych kopii zapasowych odpornych na manipulację przez napastnika.

Rekomendacje

W pierwszej kolejności organizacje powinny przeprowadzić przegląd ekspozycji usług chmurowych i kontenerowych. Wystawione Docker API, niezabezpieczone panele zarządzania, otwarte Redisy oraz publicznie dostępne interfejsy orkiestracji powinny zostać natychmiast zidentyfikowane, ograniczone sieciowo lub wyłączone.

W środowiskach Kubernetes warto zweryfikować uprawnienia kont serwisowych, rotację tokenów, polityki RBAC oraz możliwość wykonywania operacji destrukcyjnych przez nieautoryzowane workloady. Szczególne znaczenie ma wdrożenie zasady najmniejszych uprawnień oraz segmentacja dostępu między komponentami środowiska.

Drugim filarem obrony powinno być bezpieczeństwo łańcucha dostaw oprogramowania. Dobre praktyki obejmują:

pinowanie wersji zależności i akcji CI/CD,
weryfikację integralności artefaktów,
ograniczenie uprawnień tokenów wykorzystywanych przez workflow,
monitorowanie nieautoryzowanych zmian w repozytoriach i pipeline’ach,
regularny przegląd zaufanych źródeł oprogramowania i automatyzacji.

Na poziomie detekcji należy zwiększyć widoczność telemetryczną dla zdarzeń, które mogą wskazywać na przygotowanie lub realizację ataku destrukcyjnego:

masowe kasowanie plików i wolumenów,
nietypowe operacje wobec API Kubernetes,
pobieranie skryptów z niezaufanych lokalizacji podczas działania kontenerów,
uruchamianie narzędzi tunelujących i proxy,
nagłe zmiany konfiguracji językowej, regionalnej lub środowiskowej wykorzystywanej do selekcji ofiar.

Niezbędne są również kopie zapasowe odseparowane logicznie lub fizycznie od produkcji oraz regularnie testowane pod kątem odtwarzania pełnych środowisk kontenerowych. Sam backup nie wystarczy, jeśli napastnik może usunąć snapshoty, zaszyfrować repozytorium kopii albo wykorzystać skradzione poświadczenia do sabotażu procesu odzyskiwania.

Podsumowanie

CanisterWorm pokazuje, że współczesne kampanie wymierzone w infrastrukturę chmurową coraz częściej łączą automatyzację, kompromitację łańcucha dostaw, kradzież sekretów i destrukcyjne payloady. TeamPCP nie musi stosować przełomowych technik, aby osiągać wysoki poziom skuteczności — wystarczy industrializacja znanych metod oraz ich sprawne skalowanie w środowiskach cloud-native.

Dla obrońców najważniejszy wniosek jest jednoznaczny: bezpieczeństwo chmury i kontenerów wymaga nie tylko ochrony perymetru, ale także ścisłej kontroli pipeline’ów, ograniczania zaufania do zależności oraz gotowości do szybkiego odtworzenia środowiska po incydencie destrukcyjnym.

Źródła

Krebs on Security — CanisterWorm Springs Wiper Attack Targeting Iran — https://krebsonsecurity.com/2026/03/canisterworm-springs-wiper-attack-targeting-iran/
Flare — Threat Alert: TeamPCP, An Emerging Force — https://flare.io/learn/resources/blog/teampcp-cloud-native-ransomware
Wiz — TeamPCP actor profile — https://threats.wiz.io/all-actors/teampcp

Atak na Trivy rozszerza zasięg: złośliwe obrazy Docker, kradzież sekretów i zagrożenie dla Kubernetes

Wprowadzenie do problemu / definicja

Ataki na łańcuch dostaw oprogramowania należą dziś do najgroźniejszych zagrożeń dla środowisk DevSecOps. Najnowszy incydent związany z Trivy pokazuje, że kompromitacja popularnego narzędzia bezpieczeństwa może błyskawicznie przełożyć się na przejęcie pipeline’ów CI/CD, wyciek sekretów oraz dalszą propagację złośliwego kodu do środowisk kontenerowych i klastrów Kubernetes.

W tym przypadku problem nie dotyczy wyłącznie pojedynczego artefaktu, lecz całego zaufanego łańcucha dystrybucji, obejmującego obrazy Docker, repozytoria GitHub oraz GitHub Actions. To szczególnie niebezpieczne, ponieważ Trivy jest powszechnie wykorzystywany do skanowania podatności, konfiguracji i sekretów, a więc działa w miejscach, gdzie ma dostęp do wrażliwych danych.

W skrócie

Incydent objął trojanizację wybranych wersji Trivy publikowanych jako obrazy Docker oraz wcześniejsze naruszenie powiązanych komponentów GitHub Actions. Złośliwe artefakty zawierały infostealera, którego celem była kradzież danych uwierzytelniających, zmiennych środowiskowych i innych sekretów obecnych w środowiskach deweloperskich oraz CI/CD.

Złośliwe wersje Trivy mogły przechwytywać sekrety wykorzystywane w pipeline’ach.
Atak wykorzystał zaufanie do popularnego narzędzia bezpieczeństwa.
W dalszej fazie kampanii odnotowano działania typu worm oraz aktywność destrukcyjną wymierzoną w Kubernetes.
Najbardziej narażone były organizacje automatycznie pobierające najnowsze tagi lub korzystające z workflow bez twardego przypięcia wersji.

Kontekst / historia

Trivy to otwartoźródłowy skaner bezpieczeństwa szeroko używany w procesach CI/CD, analizie obrazów kontenerowych i audycie zasobów Kubernetes. Ze względu na swoją rolę często działa z dostępem do rejestrów kontenerowych, repozytoriów kodu, tokenów chmurowych oraz danych wykorzystywanych podczas budowania i wdrażania aplikacji.

Według ujawnionych informacji ostatnią znaną czystą wersją obrazu Trivy w Docker Hub była 0.69.3. Z kolei tagi 0.69.4, 0.69.5 i 0.69.6 zostały uznane za złośliwe i usunięte. Równolegle wskazano również na wcześniejsze naruszenie komponentów GitHub Actions wykorzystywanych do uruchamiania Trivy w workflow, co znacząco poszerzyło zasięg incydentu.

Badacze powiązali kampanię z grupą TeamPCP, która miała używać skradzionych poświadczeń do rozszerzania dostępu w środowiskach ofiar. Doniesienia o kompromitacji dodatkowych repozytoriów i komponentów sugerują, że incydent mógł mieć dłuższy i bardziej złożony przebieg niż początkowo zakładano.

Analiza techniczna

Technicznie mamy do czynienia z klasycznym atakiem na software supply chain, ale dostosowanym do realiów środowisk cloud-native. Atakujący mieli uzyskać możliwość publikacji lub podmiany zaufanych artefaktów, a następnie osadzić w nich kod odpowiedzialny za kradzież danych. Ponieważ Trivy działa często wewnątrz pipeline’ów z szerokimi uprawnieniami, skutki takiej kompromitacji są wyjątkowo poważne.

W przypadku złośliwych obrazów Docker mechanizm infekcji polegał na uruchomieniu trojanizowanej wersji skanera zamiast legalnego komponentu. Taki obraz mógł wykonywać dodatkowe operacje, w tym zbierać informacje o środowisku, wykradać sekrety oraz komunikować się z infrastrukturą kontrolowaną przez napastników. Szczególnie alarmującym sygnałem były tagi opublikowane bez odpowiadających im releasów i tagów w repozytorium kodu.

W warstwie GitHub Actions opisano scenariusz, w którym atakujący mogli zmienić znaczenie zaufanych tagów wersji i skierować workflow do uruchomienia złośliwego kodu. To krytyczny problem, ponieważ wiele organizacji nadal odwołuje się do akcji po tagu wersji, a nie po niezmiennym commit SHA.

Kolejna faza kampanii miała charakter post-exploitation. Przechwycone sekrety mogły zostać wykorzystane do dalszego kompromitowania usług, pakietów i środowisk developerskich. Badacze wskazali także na komponent typu worm, określany jako CanisterWorm, zdolny do samopropagacji. W wariancie wymierzonym w Kubernetes malware miało wdrażać uprzywilejowane DaemonSety, umożliwiające sabotaż, utrzymanie dostępu i dalszy ruch boczny w infrastrukturze.

Dodatkowo raportowano wykorzystanie skradzionych kluczy SSH oraz skanowanie sieci lokalnych pod kątem otwartych interfejsów Docker API na porcie 2375. To pokazuje, że atak nie kończył się na kradzieży danych, lecz był zaprojektowany jako wieloetapowa operacja nastawiona na szybkie rozszerzanie zasięgu.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem tego incydentu jest utrata zaufania do narzędzia, które samo pełni funkcję kontrolną w procesie bezpieczeństwa. Jeżeli zainfekowany skaner działał w pipeline’ie, wyciekowi mogły ulec tokeny GitHub, dane dostępowe do rejestrów kontenerowych, poświadczenia chmurowe, sekrety aplikacyjne oraz materiały wykorzystywane do podpisywania buildów.

Ryzyko dla środowisk Kubernetes jest jeszcze większe. Uprzywilejowane kontenery mogą umożliwiać dostęp do hosta, przejęcie dodatkowych sekretów, modyfikację usług systemowych i trwałe osadzenie malware. W wariancie destrukcyjnym możliwe są także przerwy w działaniu klastra, utrata danych oraz sabotaż operacyjny.

Nawet jeśli organizacja nie zaobserwowała bezpośrednich szkód, samo uruchomienie złośliwego obrazu Trivy należy traktować jako potencjalne pełne naruszenie bezpieczeństwa. Oznacza to konieczność przeglądu integralności pipeline’ów, analizy logów oraz rotacji wszystkich dostępnych sekretów.

Rekomendacje

Organizacje korzystające z Trivy powinny w pierwszej kolejności ustalić, czy pobierały lub uruchamiały obrazy oznaczone tagami 0.69.4, 0.69.5 lub 0.69.6. Należy też zweryfikować, czy workflow wykorzystywały naruszone warianty powiązanych GitHub Actions. Jeśli tak, trzeba założyć możliwość wycieku sekretów i rozpocząć kontrolowaną rotację poświadczeń.

Przypinać GitHub Actions do commit SHA zamiast do ruchomych tagów wersji.
Pinować obrazy kontenerowe do digestów, a nie tylko do tagów semantycznych.
Weryfikować integralność artefaktów, podpisy i provenance przed użyciem w pipeline’ach.
Przeanalizować logi CI/CD pod kątem nietypowych połączeń sieciowych i zmian tagów.
Ograniczyć uprawnienia kont botów i tokenów usługowych do absolutnego minimum.
Segmentować runnery CI/CD i odseparować je od środowisk produkcyjnych.
Monitorować Kubernetes pod kątem uprzywilejowanych DaemonSetów, anomalii systemowych i nietypowych restartów węzłów.
Zabezpieczyć lub całkowicie zablokować dostęp do niezabezpieczonych interfejsów Docker API.

Z perspektywy bezpieczeństwa długofalowego incydent ten potwierdza, że narzędzia używane w procesie budowania i skanowania muszą być traktowane z taką samą ostrożnością jak systemy produkcyjne. Każdy element automatyzacji, który ma dostęp do sekretów, może stać się punktem wejścia dla ataku o bardzo dużym promieniu rażenia.

Podsumowanie

Kompromitacja Trivy i powiązanych komponentów to poważny przykład nowoczesnego ataku na software supply chain w środowiskach cloud-native. Złośliwe obrazy Docker, nadużycie zaufanych tagów GitHub Actions, kradzież sekretów oraz późniejsza aktywność typu worm i działania destrukcyjne wobec Kubernetes pokazują, jak szybko lokalny incydent może przekształcić się w wieloetapową kampanię obejmującą cały ekosystem developerski.

Dla zespołów bezpieczeństwa najważniejsze wnioski są jednoznaczne: nie ufać ruchomym tagom, minimalizować uprawnienia kont usługowych, stale monitorować integralność narzędzi w pipeline’ach oraz przyjmować, że kompromitacja jednego komponentu automatyzacji może prowadzić do przejęcia znacznie większej części infrastruktury.

Źródła

The Hacker News — https://thehackernews.com/2026/03/trivy-hack-spreads-infostealer-via.html
GitHub – aquasecurity/trivy — https://github.com/aquasecurity/trivy
GitHub – aquasecurity/trivy-action — https://github.com/aquasecurity/trivy-action

Naruszenie Trivy GitHub Actions: przejęte tagi umożliwiły kradzież sekretów CI/CD

Wprowadzenie do problemu / definicja

Incydent związany z Trivy pokazuje, że współczesne ataki na łańcuch dostaw oprogramowania coraz częściej koncentrują się na automatyzacji CI/CD. W tym przypadku celem nie były wyłącznie pakiety czy artefakty, ale również zaufane akcje GitHub Actions, które w wielu organizacjach stanowią integralny element procesu budowania, testowania i wdrażania aplikacji.

Kluczowym mechanizmem wykorzystanym przez napastników było przejęcie tagów wersji i skierowanie ich na złośliwe commity. Taka technika pozwala uruchomić nieautoryzowany kod w pipeline’ach bez konieczności modyfikowania samej konfiguracji workflow po stronie ofiary.

W skrócie

Naruszenie objęło oficjalne repozytoria aquasecurity/trivy-action oraz aquasecurity/setup-trivy. Z dostępnych ustaleń wynika, że napastnik przepisał większość tagów wersji w tych projektach, tak aby wskazywały na złośliwe rewizje.

Po uruchomieniu w środowisku GitHub Actions złośliwy kod próbował pozyskiwać sekrety i dane uwierzytelniające obecne w runnerach CI/CD. Zakres potencjalnie przejętych informacji obejmował między innymi klucze SSH, tokeny GitHub, dane dostępowe do usług chmurowych, rejestrów kontenerów, baz danych oraz środowisk Kubernetes.

atak dotknął zaufanych akcji używanych w pipeline’ach bezpieczeństwa,
wektor opierał się na zatruciu tagów wersji,
celem była kradzież sekretów z runnerów CI/CD,
incydent wpisuje się w szerszy łańcuch wcześniejszych naruszeń wokół Trivy.

Kontekst / historia

Sprawa nie pojawiła się w próżni. To kolejny incydent dotyczący ekosystemu Trivy w krótkim czasie. Wcześniejsze doniesienia wskazywały na kompromitację środowiska projektu i przejęcie poświadczeń, które mogły zostać następnie wykorzystane do dalszych działań ofensywnych.

Jednym z wcześniejszych sygnałów ostrzegawczych była publikacja podejrzanej wersji narzędzia, która łączyła prawidłowe funkcje skanera z dodatkowym kodem służącym do kradzieży danych. Obecny przypadek rozszerzył jednak skalę problemu, ponieważ objął GitHub Actions, czyli komponenty automatyzacji powszechnie uruchamiane z wysokimi uprawnieniami w środowiskach deweloperskich i produkcyjnych.

Szczególnie istotne jest to, że wiele organizacji odnosi się do akcji po tagach wersji, zakładając ich stabilność i niezmienność. Incydent pokazał, że jeśli atakujący zdobędzie odpowiednie poświadczenia, może przesunąć tag na inny commit i w praktyce przejąć wykonanie w cudzych pipeline’ach.

Analiza techniczna

Technika użyta w ataku jest określana jako tag poisoning. Zamiast klasycznej kompromitacji głównej gałęzi kodu źródłowego napastnik nadpisuje istniejące tagi Git, przez co odwołania typu @v1 lub @vX.Y.Z zaczynają wskazywać na złośliwy commit. Dla użytkownika workflow wygląda poprawnie, ale pobierana zawartość nie jest już tą samą rewizją, której wcześniej ufał.

W praktyce oznacza to, że każdy pipeline odwołujący się do skompromitowanego tagu mógł pobrać i uruchomić nieautoryzowaną akcję. To bardzo niebezpieczny scenariusz, ponieważ działania wykonywane przez runnera często obejmują dostęp do sekretów, repozytoriów, artefaktów oraz infrastruktur chmurowych.

Analizy wskazują, że malware działał etapowo. Najpierw zbierał zmienne środowiskowe i dane z systemu plików runnera, następnie przygotowywał je do eksfiltracji i próbował przesłać do infrastruktury kontrolowanej przez napastnika. Wśród poszukiwanych danych znajdowały się:

sekrety GitHub Actions,
klucze SSH,
poświadczenia do usług chmurowych,
konfiguracje Git i Docker,
tokeny Kubernetes,
inne wrażliwe dane obecne w środowisku uruchomieniowym.

W części analiz opisywano również mechanizm awaryjny: jeśli standardowa eksfiltracja nie była możliwa, złośliwy kod miał wykorzystywać przejęte poświadczenia GitHub do publikacji skradzionych danych w publicznym repozytorium. Taki model zwiększa odporność operacji i utrudnia wykrywanie oparte wyłącznie na blokadzie pojedynczych hostów lub domen.

Konsekwencje / ryzyko

Skutki kompromitacji pipeline’u CI/CD mogą wykraczać daleko poza sam wyciek sekretów. Runner budujący oprogramowanie często posiada szeroki dostęp do repozytoriów, środowisk testowych, rejestrów kontenerów, a niekiedy również do produkcji. To czyni go atrakcyjnym punktem wejścia do dalszej eskalacji i ruchu bocznego.

Najważniejsze ryzyka obejmują przejęcie poświadczeń wykorzystywanych do wdrożeń, modyfikację artefaktów produkcyjnych, wstrzyknięcie backdoora do obrazów kontenerów oraz trwałe naruszenie zaufania do procesu dostarczania oprogramowania. W skrajnym scenariuszu organizacja może nieświadomie podpisywać i publikować złośliwe komponenty jako własne, legalne wydania.

Niepokojące jest również to, że atak nie wymagał luki w samym GitHubie. Wystarczyło wykorzystanie prawidłowych, lecz skompromitowanych poświadczeń z odpowiednim zakresem uprawnień. Oznacza to, że bezpieczeństwo łańcucha dostaw zależy dziś nie tylko od jakości kodu, ale również od kontroli dostępu, integralności referencji i praktyk operacyjnych wokół automatyzacji.

Rekomendacje

Organizacje korzystające z Trivy oraz innych akcji GitHub powinny potraktować ten incydent jako impuls do przeglądu zabezpieczeń CI/CD. W praktyce warto wdrożyć następujące działania:

Pinowanie akcji do pełnych hashy commitów zamiast odwołań do tagów wersji.
Natychmiastową rotację sekretów, jeśli istnieje choćby cień podejrzenia uruchomienia skompromitowanej akcji.
Przegląd logów workflow i artefaktów pod kątem nietypowych połączeń wychodzących, nowych repozytoriów i użycia tokenów.
Ograniczenie uprawnień tokenów oraz runnerów zgodnie z zasadą najmniejszych uprawnień.
Monitorowanie operacji na tagach i repozytoriach, w tym force-pushy i nietypowych zmian referencji.
Kontrolę integralności zależności pipeline’u poprzez listy zatwierdzonych SHA i regularne audyty konfiguracji.
Pełne działania containment po incydencie, wykonywane w sposób skoordynowany i kompleksowy.

Z perspektywy bezpieczeństwa najważniejsza lekcja jest prosta: tag wersji nie powinien być traktowany jako gwarancja niezmienności. W krytycznych workflow jedynym rozsądnym podejściem jest przypinanie zależności do konkretnych commitów i cykliczna weryfikacja ich integralności.

Podsumowanie

Naruszenie Trivy GitHub Actions to kolejny przykład dojrzałego ataku na łańcuch dostaw oprogramowania, w którym kluczową rolę odegrało przejęcie poświadczeń oraz podmiana zaufanych referencji. Incydent pokazuje, że nawet narzędzia bezpieczeństwa mogą stać się skutecznym wektorem kompromitacji, jeśli są osadzone w wysoko uprzywilejowanych pipeline’ach.

Dla zespołów bezpieczeństwa i DevSecOps oznacza to konieczność zmiany podejścia do zaufania w CI/CD. Ochrona musi obejmować nie tylko kod aplikacji, ale również akcje, skrypty bootstrapujące, system zarządzania sekretami, integralność tagów oraz bieżące monitorowanie zachowań runnerów.

Źródła

The Hacker News — https://thehackernews.com/2026/03/trivy-security-scanner-github-actions.html
GitHub Advisory from Aqua Security — https://github.com/aquasecurity/trivy/security
Socket Research — https://socket.dev
Wiz Research — https://www.wiz.io
GitHub Repository: aquasecurity/trivy-action — https://github.com/aquasecurity/trivy-action

CrackArmor: krytyczne luki w AppArmor umożliwiają eskalację uprawnień do roota w Linuksie

Wprowadzenie do problemu / definicja

CrackArmor to zbiorcza nazwa grupy dziewięciu podatności ujawnionych w mechanizmie AppArmor, wykorzystywanym w systemach Linux do egzekwowania obowiązkowej kontroli dostępu. Problem dotyczy błędów typu confused deputy, w których zaufany komponent wykonuje operacje bezpieczeństwa w sposób możliwy do nadużycia przez lokalnego użytkownika bez uprawnień administracyjnych.

W praktyce oznacza to ryzyko obejścia polityk ochronnych, manipulacji profilami AppArmor, a w najpoważniejszych scenariuszach także eskalacji uprawnień do poziomu root. To szczególnie istotne w środowiskach, gdzie AppArmor stanowi ważną warstwę ochrony serwerów, stacji roboczych i kontenerów.

W skrócie

CrackArmor obejmuje dziewięć podatności wpływających na mechanizm AppArmor w systemach Linux.
Luki mogą umożliwiać lokalnemu użytkownikowi obejście polityk bezpieczeństwa i uzyskanie uprawnień roota.
Zagrożenie dotyczy zwłaszcza systemów opartych na Ubuntu, Debianie i środowisk kontenerowych korzystających z AppArmor.
Problem ma charakter logiczny i wiąże się z niewłaściwą obsługą operacji administracyjnych na profilach bezpieczeństwa.
Kluczowym działaniem obronnym jest szybkie wdrożenie poprawek dostawcy oraz weryfikacja skuteczności polityk po aktualizacji.

Kontekst / historia

AppArmor od lat pozostaje jednym z podstawowych mechanizmów hardeningu w ekosystemie Linux. Jego zadaniem jest ograniczanie procesom dostępu do plików, zasobów systemowych, interfejsów jądra oraz wybranych przestrzeni nazw na podstawie przypisanych profili bezpieczeństwa.

Framework ten jest szeroko stosowany szczególnie w dystrybucjach z rodziny Ubuntu, ale także w wielu wdrożeniach kontenerowych, gdzie pełni rolę dodatkowej warstwy izolacji. Dzięki temu ma ograniczać skutki kompromitacji pojedynczej usługi i utrudniać dalszą eskalację uprawnień po uzyskaniu wstępnego dostępu.

CrackArmor pokazuje jednak, że nawet rozwiązania zaprojektowane jako mechanizmy obronne mogą same stać się źródłem krytycznego ryzyka. Ujawnione błędy logiczne wpisują się w szerszy trend, w którym rosnąca złożoność warstw bezpieczeństwa zwiększa potrzebę rygorystycznego audytu zarówno kodu jądra, jak i interfejsów zarządzających politykami ochronnymi.

Analiza techniczna

Z technicznego punktu widzenia CrackArmor to zestaw luk typu confused deputy vulnerabilities. Sedno problemu polega na tym, że nieuprzywilejowany użytkownik może nadużyć sposobu, w jaki AppArmor obsługuje wybrane operacje na interfejsach związanych z ładowaniem, podmianą lub usuwaniem profili bezpieczeństwa.

Opisane scenariusze wskazują na możliwość wpływania na profile AppArmor poprzez interfejsy w przestrzeni /sys/kernel/security/apparmor/. Jeśli operacje administracyjne na tych zasobach zostaną niewłaściwie powiązane z kontekstem wykonania lub zaufaniem do procesu wywołującego, mechanizm ochronny może zostać wykorzystany przeciwko własnemu przeznaczeniu.

W efekcie atakujący może doprowadzić do osłabienia lub wyłączenia egzekwowania polityk, uzyskać dostęp do wcześniej blokowanych zasobów i stworzyć warunki do lokalnej eskalacji uprawnień. To klasyczny przykład naruszenia rozdziału obowiązków między procesem ograniczonym a komponentem odpowiedzialnym za zarządzanie polityką bezpieczeństwa.

Dodatkowym aspektem jest wpływ na izolację kontenerów. Ponieważ AppArmor bywa wykorzystywany jako element confinement dla procesów uruchamianych w kontenerach, możliwość osłabienia lub usunięcia profilu może zwiększać ryzyko lateral movement między workloadami albo ucieczki z kontenera do hosta.

Według opublikowanych informacji podatności mogły pozostawać obecne od jądra Linux 4.11, czyli od 2017 roku. Długi okres ekspozycji zwiększa wagę problemu, ponieważ oznacza potencjalnie wieloletnią obecność luki w środowiskach produkcyjnych.

Konsekwencje / ryzyko

Najpoważniejszą konsekwencją CrackArmor jest możliwość lokalnej eskalacji uprawnień do roota. Oznacza to, że atakujący, który uzyskał już dostęp do niskoprzywilejowanego konta, podatnej aplikacji lub procesu działającego w ograniczonym kontekście, może przejąć pełną kontrolę nad systemem.

Drugim ważnym skutkiem jest obejście polityk bezpieczeństwa. Jeśli AppArmor przestaje skutecznie egzekwować swoje profile, organizacja traci jedną z głównych warstw defense-in-depth. To może ułatwić kradzież danych, utrzymanie trwałości w systemie, modyfikację konfiguracji usług czy dalszą eskalację w infrastrukturze.

W środowiskach kontenerowych ryzyko rośnie jeszcze bardziej, ponieważ AppArmor jest tam często traktowany jako istotny element separacji workloadów. Lokalna możliwość obchodzenia ograniczeń może podważyć założenia bezpieczeństwa dla platform kontenerowych i orkiestracyjnych, zwłaszcza gdy wcześniejszy etap ataku zapewnił już wykonanie kodu wewnątrz kontenera.

Nie można też wykluczyć skutków operacyjnych, takich jak destabilizacja systemu czy lokalny denial of service. Dla zespołów bezpieczeństwa oznacza to konieczność nie tylko szybkiego patchowania, ale również testów regresyjnych po wdrożeniu aktualizacji.

Rekomendacje

Organizacje korzystające z AppArmor powinny w pierwszej kolejności ustalić, które systemy wykorzystują ten framework jako aktywną warstwę ochronną. Priorytetem powinny być serwery Linux, stacje robocze administratorów oraz środowiska kontenerowe, w których profile AppArmor mają znaczenie dla izolacji procesów.

Najważniejszym krokiem jest niezwłoczne wdrożenie aktualizacji jądra i pakietów bezpieczeństwa publikowanych przez dostawców dystrybucji. Po zastosowaniu poprawek należy przeprowadzić restart zgodnie z polityką utrzymaniową i upewnić się, że nowe wersje komponentów rzeczywiście zostały załadowane.

ograniczyć możliwość lokalnego uruchamiania niezatwierdzonego kodu przez użytkowników niskoprzywilejowanych,
monitorować próby zapisu do ścieżek związanych z /sys/kernel/security/,
włączyć dodatkową telemetrię EDR lub auditd pod kątem zmian w profilach AppArmor,
zweryfikować, czy kontenery korzystają również z innych warstw ochrony, takich jak seccomp, capability dropping i user namespaces,
sprawdzić, czy na podatnych hostach nie ma oznak wcześniejszego wykorzystania lokalnych wektorów privilege escalation.

W środowiskach wysokiego ryzyka warto czasowo zwiększyć poziom monitoringu oraz przeglądnąć architekturę defense-in-depth. AppArmor nie powinien być jedynym filarem bezpieczeństwa – musi współpracować z segmentacją sieci, kontrolą dostępu uprzywilejowanego, minimalizacją uprawnień i dodatkowymi mechanizmami izolacji.

Podsumowanie

CrackArmor to poważne ostrzeżenie dla administratorów Linuksa, zespołów SecOps i DevSecOps oraz operatorów środowisk kontenerowych. Zestaw dziewięciu błędów w AppArmor pokazuje, że podatności w samych mechanizmach bezpieczeństwa mogą mieć bardzo duży wpływ na integralność całego systemu.

Najważniejsze działania po stronie organizacji to szybka identyfikacja systemów korzystających z AppArmor, pilne wdrożenie poprawek dostawcy oraz potwierdzenie, że profile bezpieczeństwa po aktualizacji nadal działają zgodnie z założeniami. Sprawa CrackArmor przypomina, że skuteczna ochrona zależy nie tylko od obecności mechanizmu bezpieczeństwa, lecz także od jakości jego implementacji, procesu aktualizacji i ciągłego monitoringu.

Źródła

Betterleaks: nowe narzędzie open source do wykrywania sekretów ma zastąpić Gitleaks

Wprowadzenie do problemu / definicja

Skanowanie sekretów to jeden z kluczowych elementów nowoczesnego bezpieczeństwa aplikacji. Narzędzia tego typu analizują repozytoria kodu, pliki i katalogi w poszukiwaniu wrażliwych danych, takich jak klucze API, tokeny dostępowe, hasła, prywatne klucze kryptograficzne czy poświadczenia do usług chmurowych. Nawet pojedynczy ujawniony sekret może otworzyć drogę do przejęcia kont, eskalacji uprawnień, naruszenia danych lub kompromitacji środowiska produkcyjnego.

Na tym tle pojawia się Betterleaks — nowe narzędzie open source stworzone z myślą o zastąpieniu Gitleaks. Projekt ma poprawić skuteczność wykrywania, ograniczyć liczbę fałszywych alarmów i uprościć wdrożenie w środowiskach DevSecOps.

W skrócie

Betterleaks to otwartoźródłowy skaner sekretów rozwijany jako nowocześniejsza kontynuacja Gitleaks. Za projektem stoi Zach Rice, czyli twórca pierwotnego narzędzia, a nowa inicjatywa ma zaoferować bardziej elastyczną logikę reguł, wyższą wydajność i lepszą detekcję trudniejszych przypadków wycieku poświadczeń.

wykorzystuje walidację reguł opartą na CEL,
stosuje tokenizację BPE zamiast klasycznej analizy entropii,
jest napisany natywnie w Go bez zależności od CGO i Hyperscan,
obsługuje wielokrotnie kodowane sekrety,
ma działać szybciej i dokładniej w dużych repozytoriach.

Kontekst / historia

Problem wycieku sekretów z kodu źródłowego od lat pozostaje jednym z najczęstszych błędów popełnianych w procesie tworzenia i utrzymania aplikacji. Wrażliwe dane trafiają do repozytoriów przez pomyłkę, pośpiech, niewłaściwe praktyki w CI/CD albo używanie plików konfiguracyjnych i środowiskowych jako tymczasowego magazynu poświadczeń. Atakujący od dawna automatyzują wyszukiwanie takich danych w publicznych i źle zabezpieczonych zasobach.

Przez długi czas Gitleaks należało do najpopularniejszych narzędzi wykorzystywanych do wykrywania tego typu problemów. Betterleaks powstał jako niezależny projekt rozwijany na licencji MIT, z ambicją przejęcia tej roli i rozwinięcia koncepcji secret scanningu w kierunku większej precyzji oraz nowocześniejszej architektury.

Analiza techniczna

Najważniejszą zmianą w Betterleaks jest podejście do reguł wykrywania. Zamiast opierać się wyłącznie na tradycyjnych metodach dopasowań i heurystykach, narzędzie wykorzystuje CEL, czyli Common Expression Language. Dzięki temu możliwe jest bardziej precyzyjne definiowanie logiki walidacji i skuteczniejsze odróżnianie realnych sekretów od ciągów znaków, które jedynie je przypominają.

Drugą istotną innowacją jest zastosowanie Token Efficiency Scanning bazującego na tokenizacji BPE. To odejście od klasycznego modelu opartego na entropii, który przez lata był standardem w wielu skanerach. Analiza entropii dobrze wykrywa losowe ciągi znaków, ale często generuje zarówno false positive, jak i false negative. Tokenizacja ma poprawiać wykrywalność niestandardowych tokenów i lepiej radzić sobie z nowoczesnymi formatami sekretów.

Ważnym atutem operacyjnym jest również implementacja w czystym Go. Brak zależności od CGO i Hyperscan upraszcza budowanie binariów, dystrybucję i uruchamianie narzędzia w różnych środowiskach, w tym w kontenerach, pipeline’ach CI/CD i systemach wieloplatformowych. Dla zespołów platformowych oznacza to mniejszą złożoność utrzymania.

Betterleaks ma także automatycznie wykrywać sekrety zakodowane wielokrotnie, na przykład po podwójnym lub potrójnym kodowaniu. To szczególnie ważne w sytuacjach, gdy poświadczenia są ukryte w zserializowanych strukturach, osadzone w danych konfiguracyjnych albo przekształcone do postaci trudniejszej do wykrycia przez prostsze mechanizmy. Rozszerzony zestaw reguł dla wielu dostawców usług i równoległa analiza repozytoriów Git mają dodatkowo poprawić szybkość skanowania większych baz kodu.

Istotne są również zapowiedzi dalszego rozwoju projektu. W planach znajdują się kolejne źródła danych poza repozytoriami Git i plikami, analiza wspomagana przez modele językowe, dodatkowe filtry detekcji, automatyczne unieważnianie sekretów przez API dostawców oraz mapowanie uprawnień. Jeśli te funkcje zostaną wdrożone w dojrzałej formie, Betterleaks może stać się nie tylko skanerem, ale elementem szerszej automatyzacji reakcji na incydenty związane z wyciekiem poświadczeń.

Konsekwencje / ryzyko

Pojawienie się Betterleaks nie oznacza incydentu, ale odpowiada na bardzo realny problem bezpieczeństwa. Wycieki sekretów należą do najbardziej kosztownych i najczęściej ignorowanych zagrożeń w cyklu życia oprogramowania. Dotyczą zarówno repozytoriów publicznych, jak i prywatnych, gdzie poświadczenia mogą pozostawać niewykryte przez długi czas.

Skutki ujawnienia sekretów są poważne. Mogą obejmować przejęcie zasobów chmurowych, nieautoryzowany dostęp do systemów produkcyjnych, kradzież danych, wykorzystanie infrastruktury do dalszych ataków, a także problemy zgodności regulacyjnej. Dodatkowym wyzwaniem jest jakość detekcji. Jeśli skaner generuje zbyt wiele błędnych alarmów, zespoły zaczynają ignorować wyniki. Jeśli z kolei wykrywalność jest zbyt niska, rośnie ryzyko przeoczenia rzeczywistego zagrożenia.

W tym kontekście Betterleaks może zainteresować organizacje, które utrzymują rozbudowane środowiska developerskie, liczne repozytoria, monorepo i intensywne pipeline’y CI/CD. Ma to szczególne znaczenie tam, gdzie kod powstaje szybko, także z udziałem narzędzi AI, a czas od napisania do wdrożenia jest bardzo krótki.

Rekomendacje

Organizacje powinny traktować skanowanie sekretów jako obowiązkową kontrolę bezpieczeństwa realizowaną na wielu etapach jednocześnie. Samo jednorazowe przeskanowanie repozytorium nie wystarcza, ponieważ nowe sekrety mogą pojawiać się wraz z kolejnymi commitami, zmianami konfiguracji i automatyzacją procesów dostarczania oprogramowania.

uruchamiać skanowanie przed każdym commitem oraz przy każdym merge request lub pull request,
analizować nie tylko aktualny stan repozytorium, ale także pełną historię Git,
regularnie rotować klucze, tokeny i poświadczenia, nawet po niewielkich incydentach,
utrzymywać centralny proces unieważniania i odtwarzania sekretów,
ograniczać uprawnienia zgodnie z zasadą najmniejszych uprawnień,
zastępować stałe sekrety krótkotrwałymi tokenami i federacją tożsamości tam, gdzie to możliwe,
szkolić zespoły developerskie z bezpiecznego zarządzania poświadczeniami,
korzystać z menedżerów sekretów zamiast przechowywania danych w kodzie, plikach środowiskowych i skryptach wdrożeniowych.

Warto też regularnie przeglądać reguły detekcji pod kątem używanych dostawców chmurowych, narzędzi CI/CD, platform SaaS oraz wewnętrznych systemów. Nawet najlepszy silnik nie zapewni skuteczności, jeśli zestaw reguł nie nadąża za zmianami w środowisku.

Podsumowanie

Betterleaks to nowy projekt open source, który ma ambicję stać się następcą Gitleaks i jednocześnie podnieść standard wykrywania sekretów w zespołach DevSecOps. Kluczowe elementy wyróżniające narzędzie to walidacja reguł oparta na CEL, skanowanie z użyciem tokenizacji BPE, uproszczona implementacja w Go oraz lepsza obsługa złożonych przypadków ukrywania poświadczeń.

Dla zespołów bezpieczeństwa i inżynierów platformowych to wyraźny sygnał, że obszar secret scanningu nadal szybko się rozwija. Niezależnie od wyboru konkretnego narzędzia najważniejsze pozostaje jednak podejście procesowe: ciągłe wykrywanie, szybka rotacja poświadczeń, minimalizacja uprawnień i automatyzacja reakcji. To właśnie sekrety wciąż należą do najłatwiejszych do przeoczenia, a zarazem najgroźniejszych wektorów kompromitacji.

Źródła

Agenci AI do programowania powielają wieloletnie błędy bezpieczeństwa

Wprowadzenie do problemu / definicja

Rosnąca popularność agentów AI wspierających tworzenie oprogramowania zmienia sposób pracy zespołów developerskich, ale jednocześnie ujawnia nową klasę ryzyka operacyjnego. Narzędzia tego typu potrafią szybko generować działający kod, jednak tempo wytwarzania nie oznacza automatycznie zgodności z dobrymi praktykami secure by design. Coraz więcej obserwacji wskazuje, że agenci kodujący często odtwarzają dobrze znane, klasyczne błędy bezpieczeństwa, szczególnie w obszarach uwierzytelniania, autoryzacji i logiki biznesowej.

W skrócie

Badanie przeprowadzone na trzech agentach AI wykazało wysoki odsetek podatności w kodzie generowanym podczas normalnego procesu wytwarzania aplikacji. W ramach 38 skanów obejmujących 30 pull requestów wykryto 143 problemy bezpieczeństwa, a 26 z 30 PR-ów zawierało co najmniej jedną lukę.

Najczęściej powtarzały się błędy kontroli dostępu, nieprawidłowe wdrożenia OAuth, brak ochrony WebSocketów, słabe zarządzanie sekretami JWT oraz brak skutecznego rate limitingu. Wniosek jest jednoznaczny: kod wygenerowany przez AI wymaga pełnoprawnej weryfikacji bezpieczeństwa, tak samo jak kod pisany ręcznie.

Kontekst / historia

Badanie objęło trzy popularne klasy agentów AI wykorzystywanych do programowania: rozwiązania od Anthropic, OpenAI oraz Google. Każdy z nich otrzymał zadanie stworzenia od podstaw dwóch realistycznych aplikacji, bez sztucznie uproszczonych scenariuszy testowych i bez dodatkowych wskazówek bezpieczeństwa w promptach.

Pierwsza aplikacja była webową platformą do zarządzania informacjami o alergiach dzieci i kontaktach rodzinnych. Druga stanowiła przeglądarkową grę wyścigową z backendowym API, rankingiem wyników oraz funkcjami multiplayer. Taki dobór przypadków użycia odzwierciedlał typowe środowiska produkcyjne, w których pojawiają się zarówno mechanizmy kont użytkowników, jak i złożona logika aplikacyjna.

Proces tworzenia przebiegał iteracyjnie, z wykorzystaniem pull requestów, które były skanowane na bieżąco. Dodatkowo wykonywano skan bazowy przed rozpoczęciem developmentu oraz końcowy przegląd całego kodu po scaleniu wszystkich zmian. Dzięki temu możliwe było prześledzenie nie tylko końcowego stanu aplikacji, ale również momentu, w którym podatności były wprowadzane i utrwalane.

Analiza techniczna

Najbardziej powtarzalną klasą problemów okazało się broken access control. W praktyce oznaczało to obecność endpointów umożliwiających wykonywanie wrażliwych lub destrukcyjnych operacji bez odpowiedniego uwierzytelnienia albo autoryzacji. Tego rodzaju błędy należą do najgroźniejszych, ponieważ umożliwiają bezpośrednie nadużycia funkcji aplikacji przez nieuprawnionych użytkowników.

Drugim silnym wzorcem były błędy logiki biznesowej. W aplikacji growej agenci akceptowali od klienta takie dane jak wynik, saldo czy stan odblokowanych elementów bez wystarczającej walidacji po stronie serwera. To klasyczny przykład nadmiernego zaufania do danych wejściowych z frontendu, który prowadzi do manipulacji stanem gry, oszustw oraz eskalacji uprawnień w modelu biznesowym aplikacji.

W obszarze OAuth odnotowano powtarzalne braki związane z parametrem state oraz z niebezpiecznym łączeniem kont. Takie problemy mogą skutkować atakami typu CSRF w procesie logowania federacyjnego lub przejęciem powiązań między tożsamościami użytkownika. Istotne jest to, że błędy nie wynikały z pojedynczej implementacji, lecz pojawiały się w pracach wszystkich badanych agentów.

Kolejny problem dotyczył WebSocketów. Agenci poprawnie implementowali middleware uwierzytelniające dla REST API, ale nie podłączali analogicznej ochrony do procesu upgrade połączenia WebSocket. W efekcie część komunikacji czasu rzeczywistego pozostawała poza egzekwowaniem polityki dostępu. To szczególnie niebezpieczne w aplikacjach multiplayer, czatach, panelach operacyjnych i systemach telemetrycznych.

Badanie wykazało także systematyczne problemy z rate limitingiem. Middleware ograniczające liczbę żądań bywało obecne w kodzie, ale nie było faktycznie aktywowane w aplikacji. Taki błąd jest podstępny, ponieważ przy pobieżnym przeglądzie kodu można odnieść wrażenie, że zabezpieczenie istnieje, mimo że nie działa w ścieżce wykonywania programu.

W wielu przypadkach wykryto również słabe zarządzanie sekretami JWT, w tym twardo zakodowane wartości zapasowe. Jeśli napastnik jest w stanie przewidzieć lub poznać taki sekret, może generować poprawne tokeny i obchodzić mechanizmy uwierzytelniania. W praktyce jest to błąd krytyczny, ponieważ podważa zaufanie do całego modelu sesji.

Szczególnie istotny jest wniosek dotyczący narzędzi detekcji. Znaczna część błędów miała charakter kontekstowy i logiczny, a nie składniowy. Oznacza to, że klasyczne mechanizmy SAST oparte głównie na sygnaturach, regexach i znanych antywzorcach mogą nie wykrywać najważniejszych podatności generowanych przez agentów AI.

Konsekwencje / ryzyko

Z perspektywy bezpieczeństwa organizacji najważniejsze ryzyko polega na fałszywym poczuciu pewności. Kod wygenerowany przez AI często działa funkcjonalnie, przechodzi podstawowe testy i bywa akceptowany szybciej z uwagi na wysokie tempo dostarczania zmian. To jednak nie oznacza, że spełnia wymagania bezpieczeństwa produkcyjnego.

W praktyce opisane podatności mogą prowadzić do nieautoryzowanego dostępu do danych, przejęcia kont, obchodzenia mechanizmów MFA, manipulacji stanem aplikacji, nadużyć API, ataków brute force oraz eskalacji wpływu pojedynczego błędu na cały system. Szczególnie niebezpieczne są luki obecne od wczesnych pull requestów, które następnie pozostają nierozwiązane do końca projektu.

Dla zespołów DevSecOps oznacza to także wzrost presji na proces przeglądu zmian. Jeśli agent AI generuje większą liczbę commitów i PR-ów, organizacja może szybciej akumulować dług bezpieczeństwa niż w klasycznym cyklu developmentu. Im większa automatyzacja kodowania, tym większa musi być automatyzacja i dojrzałość kontroli bezpieczeństwa.

Rekomendacje

Organizacje korzystające z agentów AI do programowania powinny traktować każdy wygenerowany fragment kodu jako nieufny do momentu przejścia pełnej walidacji bezpieczeństwa. Skanowanie wyłącznie końcowego buildu jest niewystarczające; analiza powinna obejmować każdy pull request, aby wychwytywać ryzyko na etapie wprowadzania zmian.

Konieczne jest również włączenie wymagań bezpieczeństwa już do etapu planowania funkcji. Jeżeli agent otrzymuje jedynie specyfikację biznesową, najczęściej zoptymalizuje rozwiązanie pod kątem działania, a nie ochrony. Dlatego prompt engineering i wymagania produktowe powinny zawierać jawne oczekiwania dotyczące autoryzacji, walidacji serwerowej, obsługi sesji, ochrony przed nadużyciami oraz bezpiecznego zarządzania sekretami.

obowiązkowe przeglądy PR-ów z perspektywy bezpieczeństwa,
analizę kontekstową kodu uwzględniającą przepływ danych i granice zaufania,
testy kontroli dostępu dla każdego endpointu i kanału komunikacji, w tym WebSocket,
walidację po stronie serwera dla wszystkich decyzji biznesowych,
centralne zarządzanie sekretami bez fallbacków w kodzie,
obowiązkowy rate limiting i ochronę przed brute force dla interfejsów logowania oraz API,
testy regresji bezpieczeństwa dla OAuth, JWT, sesji i mechanizmów odświeżania tokenów.

Dobrym podejściem jest również stworzenie listy kontrolnej najczęściej powtarzających się błędów agentów AI. Powinny się na niej znaleźć: nieautoryzowane endpointy, brak state w OAuth, brak egzekwowania autoryzacji dla WebSocketów, zaufanie do danych klienta, niewłączony rate limiting, nieodwoływalne refresh tokeny oraz słabe sekrety JWT.

Podsumowanie

Agenci AI do programowania przyspieszają development, ale nie eliminują podstawowych problemów bezpieczeństwa aplikacji. Wręcz przeciwnie, obserwacje pokazują, że potrafią systematycznie odtwarzać znane od lat wzorce podatności, szczególnie tam, gdzie wymagane jest rozumienie kontekstu biznesowego i granic zaufania.

Dla organizacji oznacza to konieczność dostosowania procesów AppSec i DevSecOps do realiów kodu generowanego maszynowo. Skuteczność agentów AI należy oceniać nie tylko przez pryzmat szybkości dostarczania funkcji, ale również przez poziom ryzyka, jaki wnoszą do pipeline’u wytwarzania oprogramowania.

Źródła

Help Net Security – AI coding agents keep repeating decade-old security mistakes – https://www.helpnetsecurity.com/2026/03/13/claude-code-openai-codex-google-gemini-ai-coding-agent-security/