Archiwa: AI - Strona 20 z 49 - Security Bez Tabu

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

GlassWorm eskaluje ataki supply chain: złośliwe rozszerzenia Open VSX uderzają w deweloperów

Wprowadzenie do problemu / definicja

Kampania GlassWorm pokazuje, jak szybko ewoluują ataki na łańcuch dostaw oprogramowania. W najnowszej odsłonie przestępcy wykorzystali ekosystem Open VSX, czyli otwarty rejestr rozszerzeń zgodnych z Visual Studio Code i jego pochodnymi, aby dostarczać złośliwe komponenty do środowisk deweloperskich.

Kluczową cechą tej operacji jest nadużycie zaufania do rozszerzeń oraz mechanizmów zależności między nimi. Dzięki temu malware może trafić do ofiary pośrednio, za pośrednictwem dodatku, który na pierwszy rzut oka wygląda na legalny i przydatny.

W skrócie

W marcu 2026 roku badacze opisali falę aktywności GlassWorm wymierzoną w użytkowników Open VSX. Zidentyfikowano co najmniej 72 złośliwe rozszerzenia podszywające się pod popularne narzędzia programistyczne, w tym linery, formatery, uruchamiacze kodu oraz dodatki związane z narzędziami AI.

Najważniejszym elementem kampanii było wykorzystanie pól extensionPack i extensionDependencies, które pozwalają jednemu rozszerzeniu automatycznie instalować inne. To właśnie w tych dodatkowych komponentach umieszczano właściwy ładunek malware, co znacząco utrudniało wykrycie zagrożenia.

atak objął dziesiątki rozszerzeń w Open VSX,
złośliwy kod dostarczano pośrednio przez zależności,
kampania była powiązana z aktywnością obserwowaną również w GitHub i npm,
celem były tokeny, sekrety, dane uwierzytelniające i informacje ze stacji roboczych deweloperów.

Kontekst / historia

GlassWorm był już wcześniej łączony z atakami na narzędzia używane przez programistów. Operatorzy tej kampanii konsekwentnie koncentrują się na punktach, w których powstaje kod, przechowywane są sekrety i uruchamiane są procesy publikacyjne.

To podejście jest szczególnie niebezpieczne, ponieważ kompromitacja środowiska deweloperskiego może otworzyć drogę nie tylko do kradzieży danych, ale także do dalszego skażenia repozytoriów, pipeline’ów CI/CD i finalnych wydań oprogramowania. W praktyce jeden zainfekowany komponent może uruchomić znacznie szerszy incydent organizacyjny.

Nowa fala wpisuje się też w rosnący trend ataków na supply chain, w których przestępcy nie opierają się już wyłącznie na klasycznych plikach wykonywalnych. Coraz częściej wykorzystują legalne aktualizacje, zależności, commity i rozszerzenia, które wyglądają na autentyczne i zgodne z normalnym workflow zespołu.

Analiza techniczna

Najważniejsza zmiana techniczna w kampanii polega na odejściu od prostego modelu, w którym każde złośliwe rozszerzenie zawiera własny loader. Atakujący wykorzystali natywne funkcje Open VSX, pozwalające deklarować pakiety rozszerzeń oraz zależności wymagane do działania.

W efekcie rozszerzenie o pozornie nieszkodliwej funkcji mogło automatycznie pobierać kolejny komponent zawierający właściwy payload. Taki model jest szczególnie trudny do wychwycenia, ponieważ pierwotny dodatek może zachowywać się zgodnie z opisem i jednocześnie pełnić rolę kanału dostarczania malware.

Badacze zwrócili również uwagę na kontynuację wcześniejszych technik charakterystycznych dla GlassWorm. Należą do nich kontrole ustawień regionalnych systemu, wykorzystywane do unikania infekowania wybranych środowisk, a także bardziej zaawansowana obfuskacja kodu.

Istotnym wyróżnikiem kampanii jest także użycie transakcji Solana jako mechanizmu typu dead drop resolver. Zamiast odwoływać się do na stałe wpisanego serwera C2, złośliwy komponent może pobierać aktualne dane o infrastrukturze sterującej z informacji zapisanych w blockchainie. Z perspektywy obrońców zwiększa to odporność operacji na blokowanie i utrudnia budowanie trwałych wskaźników kompromitacji.

Równolegle zauważono stosowanie niewidocznych znaków Unicode do ukrywania fragmentów odpowiedzialnych za dekodowanie i pobieranie kolejnych etapów infekcji. Tego rodzaju technika sprawia, że część kodu może wyglądać na pustą lub neutralną, mimo że interpreter odczytuje ją jako aktywny element łańcucha ataku.

Na poziomie funkcjonalnym malware koncentruje się na kradzieży danych o wysokiej wartości operacyjnej:

tokenów dostępowych do repozytoriów i rejestrów,
sekretów przechowywanych w zmiennych środowiskowych,
kluczy API i poświadczeń usług chmurowych,
danych CI/CD,
informacji systemowych przydatnych do dalszego profilowania ofiary.

Konsekwencje / ryzyko

Ryzyko związane z tą kampanią jest wysokie, ponieważ atak trafia bezpośrednio w proces wytwarzania oprogramowania. Jeśli przestępcy przejmą sekrety lub tokeny publikacyjne dewelopera, mogą wykorzystać je do dalszego rozprzestrzeniania złośliwego kodu w obrębie organizacji lub poza nią.

Szczególnie narażone są zespoły korzystające z dużej liczby pluginów, alternatywnych dystrybucji edytorów oraz dodatków wspierających AI. W takich środowiskach rozszerzenia są integralną częścią codziennej pracy, więc złośliwa aktywność może długo pozostawać niezauważona.

Dodatkowym problemem jest wieloplatformowy charakter operacji. Powiązania między Open VSX, GitHub i npm sugerują, że sprawcy budują cały ekosystem infekcji, w którym kompromitacja jednego elementu wspiera kolejne etapy ataku. To zwiększa skalę ryzyka dla organizacji opierających development na wielu zewnętrznych źródłach komponentów.

Rekomendacje

Organizacje powinny traktować rozszerzenia IDE jako pełnoprawny element powierzchni ataku. Oznacza to potrzebę wdrożenia podobnych mechanizmów kontroli, jakie stosuje się wobec bibliotek, kontenerów i pakietów systemowych.

ograniczyć instalację rozszerzeń wyłącznie do zatwierdzonej listy,
monitorować zmiany w zależnościach rozszerzeń, zwłaszcza w polach extensionPack i extensionDependencies,
regularnie audytować zainstalowane pluginy i ich uprawnienia,
weryfikować rozszerzenia publikowane przez mało znanych autorów,
skanować stacje deweloperskie pod kątem kradzieży sekretów i nietypowych procesów uruchamianych przez edytory,
wdrożyć wykrywanie ukrytych znaków Unicode w kodzie, konfiguracjach i paczkach publikacyjnych,
stosować zasadę minimalnych uprawnień dla tokenów oraz regularną rotację sekretów,
wymuszać MFA dla kont w rejestrach, repozytoriach i platformach CI/CD,
segmentować środowiska deweloperskie od systemów produkcyjnych,
przygotować procedury szybkiego unieważniania tokenów po wykryciu kompromitacji.

Podsumowanie

GlassWorm potwierdza, że nowoczesne ataki supply chain coraz częściej opierają się na legalnych funkcjach ekosystemów programistycznych. Nadużycie zależności w Open VSX, wykorzystanie ukrywania kodu z pomocą Unicode oraz odwołania do blockchainu jako warstwy pośredniej dla infrastruktury C2 świadczą o dojrzałej i elastycznej operacji wymierzonej w deweloperów.

Dla organizacji to wyraźny sygnał, że bezpieczeństwo procesu tworzenia oprogramowania nie może kończyć się na skanowaniu bibliotek i repozytoriów. Taki sam poziom kontroli musi objąć edytory, rozszerzenia, konta deweloperskie i wszystkie zewnętrzne komponenty używane podczas pracy nad kodem.

Źródła

The Hacker News – GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers — https://thehackernews.com/2026/03/glassworm-supply-chain-attack-abuses-72.html
Socket – GlassWorm Loader Hits Open VSX via Suspected Developer Account Compromise — https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise
Aikido – The Return of the Invisible Threat: Hidden PUA Unicode Hits GitHub Repositories — https://www.aikido.dev/blog/the-return-of-the-invisible-threat-hidden-pua-unicode-hits-github-repositorties
Eclipse Foundation Staff Blogs – Open VSX security update, October 2025 — https://blogs.eclipse.org/post/mika%C3%ABl-barbero/open-vsx-security-update-october-2025
Endor Labs – PhantomRaven or Research Experiment? — https://www.endorlabs.com/learn/phantomraven-or-research-experiment

Luki w agencie AI OpenClaw mogą prowadzić do prompt injection i eksfiltracji danych

Wprowadzenie do problemu / definicja

OpenClaw to otwartoźródłowy, samodzielnie hostowany agent AI zaprojektowany do autonomicznego wykonywania zadań na stacjach roboczych i serwerach. Tego typu rozwiązania łączą możliwości modelu językowego z realnym dostępem do systemu operacyjnego, plików, aplikacji oraz zasobów sieciowych, co znacząco zwiększa ich użyteczność, ale jednocześnie podnosi poziom ryzyka bezpieczeństwa.

W przypadku OpenClaw główne obawy dotyczą podatności na prompt injection, ryzyka eksfiltracji danych, możliwości nadużycia mechanizmów rozszerzeń oraz skutków błędnej interpretacji poleceń przez agenta. W praktyce oznacza to, że słabo zabezpieczone wdrożenie może stać się punktem wejścia do naruszenia poufności, integralności i dostępności środowiska.

W skrócie

OpenClaw może być podatny na bezpośredni i pośredni prompt injection.
Złośliwe treści osadzone w stronach WWW, dokumentach lub wiadomościach mogą wpłynąć na zachowanie agenta.
Mechanizmy skills i rozszerzeń mogą zostać wykorzystane do uruchamiania nieautoryzowanych poleceń.
Nieprawidłowa konfiguracja lub ekspozycja usług zarządzających do internetu zwiększa powierzchnię ataku.
Błędna interpretacja poleceń może prowadzić do usunięcia danych lub zakłócenia pracy systemu.

Kontekst / historia

Rosnąca popularność agentów AI sprawia, że bezpieczeństwo takich narzędzi staje się osobną kategorią ryzyka operacyjnego. W odróżnieniu od klasycznych chatbotów agenci nie ograniczają się do generowania odpowiedzi, lecz samodzielnie analizują treści, odwiedzają zasoby online, wykonują komendy i podejmują działania w imieniu użytkownika.

W przypadku OpenClaw zwrócono uwagę na to, że szerokie uprawnienia i nieoptymalne ustawienia domyślne mogą stworzyć warunki do szybkiej eskalacji incydentu. Zagrożenia nie mają wyłącznie charakteru teoretycznego, ponieważ wcześniejsze analizy dotyczące pośredniego prompt injection pokazywały, że odpowiednio spreparowane treści zewnętrzne mogą skłonić agenta do ujawnienia danych lub wykonania niezamierzonych akcji.

Dodatkowym problemem jest rosnące zainteresowanie samym projektem, które przyciąga również cyberprzestępców. W ekosystemie narzędzi AI pojawiają się fałszywe repozytoria, instalatory i paczki podszywające się pod legalne projekty, co oznacza, że ryzyko obejmuje nie tylko architekturę samego agenta, ale także cały łańcuch dostaw oprogramowania.

Analiza techniczna

Najważniejszym wektorem ataku pozostaje pośredni prompt injection. W takim scenariuszu napastnik umieszcza złośliwe instrukcje w zewnętrznej treści analizowanej przez agenta, na przykład na stronie internetowej, w dokumencie albo wiadomości zawierającej odwołanie do zasobu online. Jeśli OpenClaw pobierze i przetworzy taką zawartość, model może potraktować ją jako wiążącą instrukcję i zmienić swoje zachowanie.

To z kolei otwiera drogę do eksfiltracji danych lokalnych, sekretów aplikacyjnych, tokenów dostępowych czy informacji biznesowych znajdujących się w kontekście pracy agenta. Szczególnie groźne są scenariusze, w których agent potrafi generować adresy URL, parametry zapytań lub inne elementy mogące zostać przesłane do zewnętrznych usług. W połączeniu z mechanizmami automatycznego podglądu linków może to ułatwić przekazanie danych do infrastruktury kontrolowanej przez atakującego.

Drugim obszarem ryzyka jest model rozszerzeń i skills. Jeśli agent może instalować lub aktywować komponenty o zbyt szerokich uprawnieniach, złośliwy moduł może wykonywać polecenia systemowe, pobierać dodatkowe ładunki, modyfikować pliki lub ustanawiać trwałość działania. To szczególnie niebezpieczne, ponieważ decyzja o użyciu danego modułu może zostać podjęta automatycznie przez samego agenta.

Nie można też pomijać klasycznych błędów konfiguracyjnych. Wystawienie panelu zarządzania, domyślnych portów lub innych interfejsów administracyjnych do internetu zwiększa ryzyko skanowania, identyfikacji wersji i prób wykorzystania znanych podatności. Jeżeli taki system działa z wysokimi uprawnieniami i ma dostęp do lokalnych zasobów, skuteczne naruszenie może szybko doprowadzić do kompromitacji hosta.

Ostatnią warstwą zagrożeń jest ryzyko semantyczne, czyli błędna interpretacja poleceń. Nawet bez klasycznej podatności technicznej agent może niewłaściwie zrozumieć niejednoznaczną instrukcję i wykonać działanie destrukcyjne, takie jak usunięcie plików, nadpisanie danych czy zmiana konfiguracji krytycznych usług.

Konsekwencje / ryzyko

Dla organizacji wdrażających OpenClaw w środowiskach operacyjnych skutki mogą być bardzo poważne. Pierwszym i najbardziej oczywistym zagrożeniem jest wyciek danych, obejmujący dokumenty wewnętrzne, kod źródłowy, dane klientów, poświadczenia i sekrety aplikacyjne. W branżach regulowanych taki incydent może dodatkowo prowadzić do naruszeń zgodności i kosztownych obowiązków raportowych.

Drugim scenariuszem jest kompromitacja hosta lub dalsza eskalacja w sieci wewnętrznej. Jeśli agent ma szeroki dostęp do zasobów, skuteczne wykorzystanie jego możliwości może umożliwić ruch boczny, wdrożenie malware, utworzenie kanałów komunikacji z infrastrukturą napastnika albo trwałe osadzenie się w środowisku.

Istotne są również skutki dla integralności i dostępności. Złośliwe rozszerzenie albo nieprawidłowa decyzja agenta mogą powodować modyfikację konfiguracji, zatrzymywanie usług, kasowanie danych lub zakłócenie procesów biznesowych. W praktyce oznacza to, że agent AI powinien być traktowany jak uprzywilejowana warstwa automatyzacji, a nie zwykła aplikacja użytkownika końcowego.

Dodatkowym ryzykiem pozostaje ekosystem dystrybucji. Użytkownicy poszukujący instalatorów, poradników lub repozytoriów mogą paść ofiarą kampanii podszywających się pod legalne źródła, co zamienia sam etap wdrożenia w wektor początkowego dostępu.

Rekomendacje

Podstawową zasadą powinno być ograniczenie uprawnień agenta do absolutnego minimum. OpenClaw należy uruchamiać w odizolowanym środowisku, najlepiej w kontenerze lub maszynie wirtualnej, z wyraźnie określonym zakresem dostępu do plików, procesów i sieci.

Interfejsy administracyjne nie powinny być wystawiane bezpośrednio do internetu. Dostęp do zarządzania warto ograniczyć przez segmentację sieci, listy kontroli dostępu, VPN oraz dodatkowe mechanizmy uwierzytelniania. Równie ważne jest regularne aktualizowanie samego agenta i jego zależności.

Organizacje powinny też wdrożyć ścisłe zasady zarządzania rozszerzeniami i skills. Obejmuje to korzystanie wyłącznie z zaufanych źródeł, ręczny przegląd komponentów, kontrolę uprawnień oraz monitorowanie zachowania modułów po wdrożeniu. Automatyczna instalacja i aktualizacja rozszerzeń bez walidacji bezpieczeństwa powinna być ograniczona.

W ochronie przed prompt injection konieczne jest podejście wielowarstwowe. Należy oddzielać instrukcje systemowe od danych wejściowych, filtrować treści zewnętrzne, walidować odpowiedzi modelu przed wykonaniem akcji oraz ograniczać możliwość automatycznego generowania i otwierania odwołań do zasobów zewnętrznych. Operacje wysokiego ryzyka powinny wymagać wyraźnego zatwierdzenia przez użytkownika.

Dobrym standardem jest również stosowanie menedżerów sekretów, krótkotrwałych tokenów oraz pełnej telemetrii obejmującej polecenia wykonywane przez agenta, ruch sieciowy, aktywację skills i nietypowe operacje na plikach. Równolegle warto przygotować procedury reagowania, takie jak szybka izolacja hosta, odwoływanie poświadczeń, kopie zapasowe i plan odtworzenia środowiska.

Podsumowanie

OpenClaw dobrze pokazuje, że wraz z rozwojem agentów AI zmienia się także krajobraz zagrożeń. Prompt injection, złośliwe rozszerzenia, nadmierne uprawnienia i błędy konfiguracyjne mogą połączyć się w łańcuch prowadzący od manipulacji zachowaniem modelu do wycieku danych lub pełnej kompromitacji endpointu.

Dla zespołów bezpieczeństwa najważniejszy wniosek jest jednoznaczny: agentów AI nie należy wdrażać jak standardowych aplikacji użytkowych. Wymagają one twardej kontroli uprawnień, segmentacji, audytu rozszerzeń, ciągłego monitoringu i dobrze przygotowanych procedur reagowania na incydenty.

Źródła

Bold Security pozyskuje 40 mln USD i stawia na ochronę endpointów wspieraną przez lokalne modele AI

Wprowadzenie do problemu / definicja

Rynek cyberbezpieczeństwa coraz wyraźniej przesuwa środek ciężkości w stronę ochrony urządzeń końcowych, ponieważ to właśnie endpointy pozostają miejscem, w którym użytkownicy pracują z danymi, aplikacjami SaaS oraz narzędziami opartymi na sztucznej inteligencji. W tym kontekście Bold Security ogłosił wyjście z trybu stealth i zaprezentował platformę, która wykorzystuje modele AI uruchamiane bezpośrednio na urządzeniach końcowych do analizy zachowań użytkownika, klasyfikacji danych oraz egzekwowania polityk bezpieczeństwa w czasie rzeczywistym.

To podejście wpisuje się w szerszy trend odchodzenia od wyłącznie pasywnego monitoringu na rzecz ochrony działającej bliżej użytkownika, z mniejszym opóźnieniem i większą kontrolą nad przetwarzaniem danych.

W skrócie

Bold Security wyszedł z trybu stealth i pozyskał 40 mln USD finansowania.
Firma rozwija platformę bezpieczeństwa endpointów wspieraną przez AI działającą lokalnie na urządzeniu.
Rozwiązanie ma łączyć analizę zachowań użytkownika, klasyfikację danych i egzekwowanie polityk bezpieczeństwa.
Celem jest ograniczenie opóźnień reakcji, poprawa prywatności oraz lepsza kontrola nad użyciem danych i narzędzi AI.
Producent pozycjonuje ofertę jako rozwiązanie dla dużych środowisk korporacyjnych.

Kontekst / historia

Segment ochrony endpointów przeszedł w ostatnich latach znaczącą ewolucję. Tradycyjne antywirusy ustąpiły miejsca platformom EDR i XDR, a obecnie rynek coraz częściej poszukuje rozwiązań łączących telemetrię, klasyfikację danych, kontrolę dostępu oraz mechanizmy sztucznej inteligencji. Zmiana ta została przyspieszona przez rozwój pracy hybrydowej, powszechne wykorzystanie chmury oraz rosnące znaczenie generatywnej AI w codziennej pracy.

Bold Security wpisuje się w ten trend jako firma z siedzibą w Nowym Jorku, współzałożona przez Natiego Hazuta, pełniącego funkcję CEO. Pozyskane 40 mln USD ma wesprzeć rozwój możliwości AI oraz ekspansję rynkową. Według deklaracji spółki, rozwiązanie zostało już wdrożone w dużych przedsiębiorstwach w Stanach Zjednoczonych, co wskazuje na silne ukierunkowanie na segment enterprise.

Analiza techniczna

Najbardziej charakterystycznym elementem platformy Bold Security jest architektura oparta na lokalnym uruchamianiu modeli AI na endpointach. Oznacza to odejście od modelu, w którym zdecydowana większość danych telemetrycznych trafia do centralnego backendu, gdzie dopiero następuje analiza i decyzja o reakcji.

Z technicznego punktu widzenia takie podejście przynosi kilka potencjalnych korzyści. Przede wszystkim pozwala skrócić czas między wykryciem ryzykownego działania a egzekwowaniem polityki bezpieczeństwa. Ma to znaczenie przy próbach kopiowania danych, nieautoryzowanym użyciu narzędzi AI, nietypowych działaniach użytkownika czy operacjach mogących prowadzić do eksfiltracji informacji.

Drugim ważnym aspektem jest prywatność. Analiza prowadzona bezpośrednio na urządzeniu może ograniczyć zakres danych przesyłanych do chmury, co może być szczególnie istotne dla organizacji objętych restrykcyjnymi wymaganiami regulacyjnymi lub wewnętrznymi politykami ochrony informacji. Firma podkreśla także, że analizowane dane nie są wykorzystywane do trenowania modeli, a kontrola nad przechowywaniem materiału dowodowego pozostaje po stronie klienta.

Funkcyjnie platforma próbuje połączyć kilka klas zabezpieczeń w jednym agencie endpointowym:

monitorowanie zachowań użytkownika,
klasyfikację danych w czasie rzeczywistym,
egzekwowanie polityk bezpieczeństwa,
kontrolę interakcji z aplikacjami i narzędziami AI.

To sugeruje próbę połączenia możliwości znanych z EDR, DLP oraz narzędzi governance dla AI w jednej warstwie ochronnej. Jeżeli modele rzeczywiście potrafią rozumieć nie tylko działania użytkownika, ale również kontekst biznesowy, mogą podejmować bardziej precyzyjne decyzje niż klasyczne systemy oparte wyłącznie na sygnaturach lub prostych regułach anomalii.

Jednocześnie skuteczność takiego modelu zależy od jakości lokalnych modeli AI, ich wpływu na zasoby urządzenia, sposobu aktualizacji oraz odporności na próby obejścia lub wyłączenia agenta. W praktyce to właśnie te czynniki zdecydują, czy architektura lokalna będzie przewagą, czy źródłem dodatkowych wyzwań operacyjnych.

Konsekwencje / ryzyko

Wejście na rynek platform takich jak Bold Security pokazuje, że granice między ochroną endpointów, DLP, analizą zachowań użytkowników oraz kontrolą użycia AI zaczynają się zacierać. Dla zespołów bezpieczeństwa może to oznaczać uproszczenie architektury ochronnej i możliwość objęcia jednym agentem kilku kategorii ryzyka jednocześnie.

Korzyści te nie eliminują jednak zagrożeń. Najważniejsze pytania dotyczą skuteczności modeli w środowisku produkcyjnym, liczby fałszywych alarmów, wpływu na wydajność stacji roboczych oraz odporności samego rozwiązania na manipulację. Agent, który działa lokalnie i blokuje działania użytkownika, staje się komponentem krytycznym. Jego obejście lub dezaktywacja może stworzyć napastnikowi dogodną ścieżkę do eksfiltracji danych albo ukrycia aktywności.

Istotne ryzyko dotyczy także warstwy zarządzania. Narzędzia analizujące zachowania użytkownika i kontekst danych muszą być bardzo precyzyjnie dopasowane do polityk organizacji. Zbyt restrykcyjna konfiguracja może zakłócać pracę, natomiast zbyt łagodne ustawienia obniżą wartość ochronną. W środowiskach korporacyjnych szczególne znaczenie będą miały również audytowalność decyzji podejmowanych przez modele AI, transparentność działania oraz zgodność z wymaganiami compliance.

Rekomendacje

Organizacje rozważające wdrożenie podobnych rozwiązań powinny rozpocząć od technicznej i operacyjnej oceny produktu. Kluczowe jest zrozumienie, jakie dane są analizowane lokalnie, jakie metadane opuszczają urządzenie oraz w jaki sposób realizowane jest przechowywanie materiału dowodowego.

Warto przeprowadzić pilotaż obejmujący realistyczne scenariusze użycia, takie jak kopiowanie danych między aplikacjami, korzystanie z narzędzi generatywnej AI, próby przesyłania wrażliwych informacji poza organizację oraz nietypowe zachowania użytkownika. Równie ważne jest porównanie wyników z istniejącymi systemami EDR, DLP, CASB, SIEM i procesami reagowania na incydenty.

Zweryfikować wpływ agenta na wydajność urządzeń końcowych.
Sprawdzić możliwości definiowania polityk i testowania ich przed włączeniem blokad.
Ocenić jakość mechanizmów wyjaśniania decyzji podejmowanych przez AI.
Przetestować odporność agenta na tampering i próby wyłączenia.
Przeanalizować model aktualizacji oraz czas reakcji producenta na nowe techniki obejścia.
Potwierdzić zgodność z wymaganiami prawnymi i wewnętrznymi zasadami ochrony danych.

Z perspektywy blue team tego typu narzędzia powinny być traktowane jako warstwa uzupełniająca, a nie pełne zastępstwo dla istniejących zabezpieczeń. Nawet zaawansowana analiza lokalna na endpointach nie eliminuje potrzeby stosowania architektury zero trust, kontroli tożsamości, segmentacji dostępu oraz ochrony danych na wielu poziomach.

Podsumowanie

Bold Security próbuje odpowiedzieć na rosnące potrzeby rynku, łącząc ochronę endpointów z lokalnie działającymi modelami AI. Pozyskanie 40 mln USD pokazuje, że inwestorzy dostrzegają potencjał w rozwiązaniach, które mają analizować zachowania użytkownika, klasyfikować dane i egzekwować polityki bezpieczeństwa bezpośrednio na urządzeniu.

Ostateczna wartość takiej platformy będzie jednak zależeć od jakości modeli, skuteczności operacyjnej, integracji z istniejącym ekosystemem bezpieczeństwa oraz zdolności do zachowania równowagi między ochroną, prywatnością i wygodą użytkownika końcowego.

Źródła

SecurityWeek — https://www.securityweek.com/bold-security-emerges-from-stealth-with-40-million-in-funding/
Bold Security — https://www.bold.security/

Google wypłacił 17,1 mln dolarów w bug bounty w 2025 roku

Wprowadzenie do problemu / definicja

Programy bug bounty od lat stanowią ważny element nowoczesnych strategii bezpieczeństwa. Ich celem jest motywowanie niezależnych badaczy do odpowiedzialnego zgłaszania podatności w zamian za wynagrodzenie finansowe. Dzięki temu producenci oprogramowania i usług cyfrowych mogą szybciej identyfikować błędy w przeglądarkach, chmurze, systemach mobilnych, komponentach open source i rozwiązaniach opartych na sztucznej inteligencji.

Najnowsze dane pokazują, że Google konsekwentnie rozwija ten model współpracy. W 2025 roku firma wyraźnie zwiększyła skalę wypłat, traktując zewnętrzne badania bezpieczeństwa jako integralny element ochrony swoich produktów i infrastruktury.

W skrócie

Google wypłacił w 2025 roku łącznie 17,1 mln dolarów w ramach programów Vulnerability Reward Program.
To wzrost o około 40% rok do roku względem 2024, gdy wypłaty wyniosły 12 mln dolarów.
Nagrody otrzymało ponad 700 badaczy bezpieczeństwa.
Największe obszary aktywności obejmowały Chrome, Google Cloud, Androida, AI, zgłoszenia dotyczące nadużyć oraz open source.
Łączna wartość wypłat od początku programu przekroczyła 81,6 mln dolarów.

Kontekst / historia

Google rozwija swoje programy nagród za podatności od 2010 roku. Przez lata bug bounty przestał być jedynie dodatkiem do procesu bezpieczeństwa i stał się jednym z filarów odpowiedzialnego ujawniania luk oraz wzmacniania odporności produktów. Firma sukcesywnie rozszerzała zakres programu, obejmując nim kolejne obszary infrastruktury i usług.

Już w 2024 roku widoczny był wyraźny wzrost skali programu, gdy wypłaty sięgnęły 12 mln dolarów i trafiły do 660 badaczy. Dane za 2025 rok pokazują jednak dalsze przyspieszenie. Szczególne znaczenie ma tu rozwój Cloud VRP, który po uruchomieniu pod koniec 2024 roku wszedł w pierwszy pełny rok działania. W praktyce oznacza to większą dojrzałość programu oraz rosnące znaczenie zgłoszeń obejmujących złożone scenariusze ataku.

Analiza techniczna

Największy pojedynczy obszar wypłat w 2025 roku dotyczył przeglądarki Chrome. Google przekazał ponad 3,7 mln dolarów ponad 100 badaczom raportującym błędy w tym ekosystemie. Najwyższe nagrody sięgały 250 tys. dolarów za kompletne łańcuchy ataku prowadzące do ucieczki z sandboxa. Tego typu zgłoszenia są szczególnie wartościowe, ponieważ pokazują możliwość obejścia wielowarstwowych mechanizmów izolacji i ochrony procesów.

Z technicznego punktu widzenia istotne jest to, że badania nad Chrome przełożyły się nie tylko na poprawki konkretnych błędów, ale również na dalsze wzmacnianie sandboxa w V8 oraz poprawę memory safety. To potwierdza trend widoczny w nowoczesnym bezpieczeństwie przeglądarek: coraz większe znaczenie mają zmiany architektoniczne utrudniające budowę stabilnych exploit chainów.

Drugim kluczowym segmentem było Google Cloud, gdzie wypłaty przekroczyły 3,5 mln dolarów. W ramach Cloud VRP przetworzono 1774 zgłoszenia od 143 badaczy. Część z tych raportów doprowadziła nie tylko do usunięcia krytycznych podatności, lecz także do zmian projektowych w wybranych produktach chmurowych. To ważny sygnał dla całej branży, ponieważ pokazuje, że bug bounty może służyć również do identyfikacji systemowych słabości architektury.

W obszarze Androida i urządzeń Google wypłaty przekroczyły 2,9 mln dolarów. Firma odnotowała wzrost liczby zgłoszeń dotyczących luk wysokiego i krytycznego ryzyka, mimo inwestycji w bezpieczniejsze języki programowania oraz zabezpieczenia sprzętowe. Może to oznaczać przesunięcie profilu wykrywanych podatności: mniej klasycznych błędów korupcji pamięci, a więcej złożonych obejść warstw defense-in-depth, podatności logicznych, błędów firmware i wieloetapowych łańcuchów ataku.

Coraz wyraźniej rośnie również znaczenie segmentu AI. Program AI VRP odpowiadał za ponad 890 tys. dolarów wypłat. Google nagradzał między innymi zgłoszenia dotyczące lokalnych implementacji Gemini działających na urządzeniach. Bezpieczeństwo AI obejmuje dziś już nie tylko klasyczne luki aplikacyjne, ale także odporność na nadużycia, kwestie integralności wejścia, sterowania zachowaniem systemu i izolacji modeli.

Dodatkowo firma wypłaciła 482 tys. dolarów w ramach Abuse VRP oraz ponad 327 tys. dolarów w OSS VRP. Pokazuje to, że ochrona ekosystemu bezpieczeństwa nie ogranicza się wyłącznie do komercyjnych produktów, lecz obejmuje również komponenty open source i mechanizmy przeciwdziałania nadużyciom.

Konsekwencje / ryzyko

Wzrost wartości wypłat nie musi oznaczać pogorszenia poziomu bezpieczeństwa produktów Google. Znacznie częściej jest to sygnał, że program działa skuteczniej, przyciąga bardziej zaawansowanych badaczy i lepiej premiuje złożone, wysokowartościowe zgłoszenia. Z perspektywy rynku oznacza to jednak również, że najbardziej ryzykowne obszary pozostają dobrze zdefiniowane: przeglądarki, chmura, urządzenia mobilne i rozwiązania AI.

Najpoważniejsze zagrożenia można podzielić na kilka grup. Luki w Chrome mogą prowadzić do zdalnego wykonania kodu, eskalacji uprawnień lub obejścia izolacji procesu. Podatności w chmurze wpływają na poufność danych, integralność usług i bezpieczeństwo środowisk wielodzierżawnych. Z kolei błędy w Androidzie i firmware mogą zwiększać ryzyko trwałej kompromitacji urządzeń oraz utrudniać wykrycie incydentu.

Istotnym wnioskiem jest także to, że coraz większa część wartościowych raportów nie kończy się na pojedynczym patchu. Wiele zgłoszeń wskazuje na potrzebę zmian architektonicznych, co powinno skłaniać organizacje do analizowania bug bounty jako źródła wiedzy o słabościach modelu zaufania, granic bezpieczeństwa i procesu projektowego.

Rekomendacje

Dla organizacji rozwijających własne programy bug bounty model Google stanowi istotny punkt odniesienia. Największą wartość przynoszą zgłoszenia, które nie tylko wskazują błąd, ale opisują pełny scenariusz wykorzystania, przyczynę źródłową i wpływ biznesowy.

Premiować raporty wysokiej jakości technicznej, szczególnie te zawierające pełny łańcuch ataku.
Inwestować w eliminowanie całych klas podatności, a nie wyłącznie pojedynczych błędów.
Traktować środowiska chmurowe jako odrębny obszar wymagający własnego modelu bug bounty.
Włączać bezpieczeństwo AI do standardowych procesów AppSec i Product Security.
Analizować powtarzające się wzorce zgłoszeń jako sygnał do szerszego przeglądu architektury i kontroli jakości.

Takie podejście zwiększa szansę, że program nagród za podatności będzie nie tylko narzędziem reagowania na zgłoszenia, ale także źródłem strategicznej wiedzy o odporności całej platformy.

Podsumowanie

Wypłata 17,1 mln dolarów w 2025 roku potwierdza, że bug bounty pozostaje dla Google strategicznym narzędziem wzmacniania bezpieczeństwa. Szczególnie istotne były zgłoszenia dotyczące Chrome, Google Cloud, Androida i AI, a część z nich doprowadziła do zmian architektonicznych, a nie tylko do usunięcia pojedynczych podatności.

Dla branży cyberbezpieczeństwa to wyraźny sygnał, że dojrzałe programy nagród za luki powinny być ściśle zintegrowane z procesami engineeringu, hardeningu oraz zarządzania ryzykiem. Rosnące wypłaty pokazują, że bezpieczeństwo staje się coraz bardziej procesem opartym na współpracy z zewnętrznymi badaczami i na ciągłym wzmacnianiu całych klas zabezpieczeń.

Źródła

SecurityWeek — Google Paid Out $17 Million in Bug Bounty Rewards in 2025 — https://www.securityweek.com/google-paid-out-17-million-in-bug-bounty-rewards-in-2025/
Google Bug Hunters — Vulnerability Reward Program statistics and announcements — https://bughunters.google.com/
Google Online Security Blog — Vulnerability Reward Program: 2024 in Review — https://security.googleblog.com/2025/03/vulnerability-reward-program-2024-in.html

Onyx Security pozyskuje 40 mln dolarów na ochronę autonomicznych agentów AI

Wprowadzenie do problemu / definicja

Rosnąca skala wdrożeń autonomicznych agentów AI tworzy nową kategorię wyzwań dla bezpieczeństwa przedsiębiorstw. W odróżnieniu od klasycznych modeli generatywnych, które głównie przetwarzają treści, agenci AI mogą wykonywać działania, korzystać z narzędzi, integrować się z usługami SaaS, środowiskami chmurowymi, repozytoriami kodu i systemami firmowymi. Oznacza to, że bezpieczeństwo nie ogranicza się już do ochrony danych wejściowych i wyjściowych, ale obejmuje także kontrolę decyzji podejmowanych przez AI, zakres przyznanych uprawnień i skutki operacyjne ich działań.

W skrócie

Onyx Security oficjalnie zadebiutował na rynku, informując o pozyskaniu 40 mln dolarów finansowania od funduszy Conviction i Cyberstarts. Firma rozwija platformę bezpieczeństwa dla agentów AI, która ma zapewniać przedsiębiorstwom widoczność aktywności agentów, możliwość nadzoru nad ich działaniami oraz egzekwowanie polityk bezpieczeństwa i governance.

Spółka pozyskała 40 mln dolarów finansowania.
Platforma ma wykrywać i monitorować autonomiczne agenty AI w środowisku firmowym.
Rozwiązanie wspiera zatwierdzanie, korygowanie i ograniczanie działań agentów.
Onyx deklaruje wykorzystanie własnych modeli AI i agentów nadzorczych do analizy zachowań w czasie rzeczywistym.

Kontekst / historia

Rynek cyberbezpieczeństwa coraz mocniej przesuwa uwagę z ochrony pojedynczych aplikacji AI na zabezpieczanie systemów agentowych. W pierwszej fali popularyzacji generatywnej sztucznej inteligencji dominowały obawy dotyczące wycieku danych do chatbotów, nieautoryzowanego użycia modeli czy zgodności regulacyjnej. Obecnie organizacje wdrażają jednak rozwiązania, które nie tylko generują treści, ale również wykonują zadania operacyjne, korzystają z API, analizują kod, modyfikują konfiguracje i współpracują z wieloma systemami jednocześnie.

W takim krajobrazie pojawia się potrzeba stworzenia warstwy kontrolnej porównywalnej do rozwiązań znanych z obszaru ochrony tożsamości uprzywilejowanych, EDR czy CSPM. Onyx Security pozycjonuje się właśnie jako dostawca takiej warstwy zabezpieczeń dla agentic AI. Firma została założona przez osoby związane z izraelskim sektorem obronnym i działa z Tel Awiwu oraz Nowego Jorku, rozwijając zespół w Izraelu, USA i Kanadzie.

Analiza techniczna

Z technicznego punktu widzenia model proponowany przez Onyx wpisuje się w nowo powstający segment zabezpieczeń dla środowisk agentowych. Kluczowym elementem jest centralna warstwa kontroli, która umożliwia wykrywanie agentów działających w organizacji i mapowanie ich możliwości operacyjnych. Obejmuje to identyfikację połączeń z usługami chmurowymi, stacjami roboczymi, repozytoriami kodu i platformami SaaS.

Istotna jest nie tylko sama inwentaryzacja, ale też analiza uprawnień oraz zachowania agentów. Jeżeli agent może wykonywać akcje w imieniu użytkownika lub procesu biznesowego, bezpieczeństwo zależy od tego, jakie dane może odczytać, jakie systemy może zmieniać, jak podejmuje decyzje i czy jego działania można zatrzymać lub skorygować przed wykonaniem. Onyx deklaruje, że jego platforma ma umożliwiać monitorowanie takich aktywności oraz zatwierdzanie lub poprawianie działań zgodnie z politykami organizacji.

Firma podkreśla również wykorzystanie agentów nadzorczych i własnych modeli AI do interpretowania rozumowania innych agentów. To ważne, ponieważ w środowiskach agentowych klasyczne logowanie akcji może nie wystarczać. Ryzyko może wynikać nie tylko z końcowego działania, ale także z błędnej sekwencji wnioskowania, niewłaściwego użycia narzędzia, eskalacji uprawnień przez integracje lub podatności na manipulację promptami i kontekstem. Warstwa nadzorcza działająca w czasie rzeczywistym ma ograniczać takie ryzyka jeszcze przed wystąpieniem szkody biznesowej.

W praktyce architektura tego typu przypomina połączenie kilku znanych klas zabezpieczeń:

discovery aktywów i agentów,
monitoringu zachowania,
egzekwowania polityk bezpieczeństwa,
analizy ryzyka,
mechanizmów human-in-the-loop dla działań wysokiego ryzyka.

Konsekwencje / ryzyko

Z perspektywy przedsiębiorstw rozwój takich platform pokazuje, że bezpieczeństwo agentów AI staje się samodzielnym obszarem ryzyka. Autonomiczne systemy mogą prowadzić do nieautoryzowanego dostępu do danych, błędnego wykonywania poleceń, niekontrolowanego użycia narzędzi, naruszeń zasad compliance oraz propagacji błędów między połączonymi systemami. Im większa autonomia agenta i im szerszy zakres integracji, tym większa staje się powierzchnia ataku.

Dodatkowym problemem jest skala. Pojedynczego agenta można jeszcze ocenić ręcznie, ale środowisko obejmujące setki lub tysiące agentów wymaga automatycznego nadzoru, klasyfikacji ryzyka i wymuszania polityk bezpieczeństwa. Bez centralnej widoczności organizacje mogą szybko utracić kontrolę nad tym, jakie agenty działają w infrastrukturze, jakie mają uprawnienia i jakie operacje faktycznie wykonują.

Z biznesowego punktu widzenia pozyskanie przez Onyx Security 40 mln dolarów wskazuje, że inwestorzy traktują bezpieczeństwo agentów AI jako strategiczny segment rynku. Może to przyspieszyć zarówno rozwój konkurencyjnych produktów, jak i wdrażanie narzędzi governance w dużych organizacjach.

Rekomendacje

Organizacje wdrażające agentów AI powinny traktować je jak uprzywilejowane byty wykonawcze, a nie tylko jako kolejne interfejsy użytkownika. W praktyce oznacza to konieczność pełnej inwentaryzacji agentów, ich integracji, źródeł danych i zakresu uprawnień.

Stosować zasadę najmniejszych uprawnień dla wszystkich agentów.
Ograniczać dostęp do narzędzi, API i repozytoriów wyłącznie do niezbędnego minimum.
Definiować jasny zakres działań, limity operacyjne i mechanizmy awaryjnego zatrzymania.
Budować monitoring skoncentrowany na zachowaniu agentów, a nie tylko na logach aplikacyjnych.
Wprowadzać zatwierdzanie przez człowieka dla operacji wysokiego ryzyka.
Tworzyć polityki governance obejmujące klasyfikację agentów, ocenę ryzyka, audyt i procedury reagowania na incydenty AI.

Podsumowanie

Onyx Security wchodzi na rynek z mocnym sygnałem, że zabezpieczanie autonomicznych agentów AI staje się jednym z najważniejszych nowych obszarów cyberbezpieczeństwa. Pozyskane 40 mln dolarów ma wesprzeć rozwój platformy zapewniającej wykrywanie, monitoring i kontrolę działań agentów w środowiskach przedsiębiorstw. Dla rynku to kolejny dowód, że wraz ze wzrostem autonomii systemów AI rośnie też potrzeba nowych mechanizmów nadzoru, egzekwowania polityk i ograniczania ryzyka operacyjnego.

Źródła

SecurityWeek – Onyx Security Launches With $40 Million in Funding — https://www.securityweek.com/onyx-security-launches-with-40-million-in-funding/
Onyx Security — https://onyx.security/

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/