AI coding agents a bezpieczeństwo łańcucha dostaw

Zespoły programistyczne, które oddały swoim deweloperom narzędzia AI do pisania kodu, nieświadomie otworzyły cyberprzestępcom nową furtkę – taką, która omija wieloletnie szkolenia z bezpieczeństwa. Zgodnie z analizą Brada Arkina z Socket, opublikowaną 23 czerwca, asystenci AI pobierają pakiety do środowisk, których żaden skaner nie nadzoruje, rozwiązują zależności zanim zespół ds. bezpieczeństwa zdąży je sprawdzić, a robią to na skalę i z szybkością, do której ludzkie procesy weryfikacji nigdy nie były projektowane.

Konsekwencje tych działań są widoczne w raporcie Phoenix Security dotyczącym łańcucha dostaw w 2026 roku. Pierwsza połowa tego roku przyniosła już o 2,6 więcej kampanii i 4,5 razy więcej kompromitacji pakietów niż cały rok 2025. Agenci AI, będący zarówno celami, jak i nieświadomymi narzędziami do dystrybucji zagrożeń, stanowią udokumentowany katalizator tych wzrostów.

Dlaczego AI coding agents omijają ludzkie procedury bezpieczeństwa

Przez lata podstawową obroną behawioralną przed atakami na łańcuch dostaw było spowolnienie dewelopera: człowiek zatrzymywał się, by sprawdzić liczbę pobrań pakietu, zweryfikować historię autora lub zakwestionować nieznaną nazwę przed uruchomieniem npm install. Agenci AI nie robią niczego podobnego.

Podczas gdy ludzki programista zawahałby się na widok podejrzanej nazwy, agent AI rozwiązuje zależność i przechodzi dalej. Wykonuje dokładnie to, do czego został zbudowany – redukuje tarcie, utrzymuje tempo, usprawnia budowanie. I właśnie ta wydajność stała się powierzchnią ataku.

Środowisko agentów to obszar, który praktycznie nikt nie zbadał, a rozwija się najszybciej – mówi Brad Arkin z Socket. Organizacje, które wierzą, że ich bezpieczeństwo łańcucha dostaw jest silne, bo deweloperzy stosują ostrożne praktyki weryfikacji, mogą być narażone przez część przepływu pracy obsługiwaną przez AI, której istniejące audyty nie wychwytują.

Nowe techniki ataku: PromptMink, slopsquatting i Clinejection

Ataki wykorzystujące LLM: kampania PromptMink

Najwyraźniejszym dowodem, że napastnicy przystosowali się do nowego celu, jest kampania PromptMink, udokumentowana przez ReversingLabs i przypisana grupie Famous Chollima, powiązanej z Koreą Północną, która celuje w deweloperów kryptowalut i fintechów.

Kampania ta wykraczała poza tradycyjne typosquatting, czyli publikowanie pakietów o nazwach łudząco podobnych do popularnych bibliotek. PromptMink zastosował technikę, którą ReversingLabs nazywa „nadużyciem optymalizacji LLM i wstrzykiwaniem wiedzy”: tworzenie plików README napisanych tak, by dla dużego modelu językowego (LLM) brzmiały autorytatywnie podczas rozwiązywania zależności – nie jak dla człowieka czytającego dokumentację.

Pakiet-przynęta, @solana-launchpad/sdk, był połączony z łańcuchem złośliwych zależności, które zawierały infostealery (kradnące dane uwierzytelniające), klucze SSH dla trwałego zdalnego dostępu i narzędzia do archiwizacji danych. Potwierdzenie, że kampania dotarła do agentów AI, pojawiło się w styczniu 2026 roku, gdy badacze znaleźli legalny projekt z hackathonu Solana Graveyard, który zawierał @solana-launchpad/sdk – zależność dodaną w commicie współautorskim z Claude Opus.

Slopsquatting: gdy halucynacje AI stają się wektorem ataku

Oprócz pakietów-przynęt stworzonych specjalnie do oszukiwania agentów AI, wyłoniła się druga klasa ataków wykorzystująca inny tryb awarii modeli: halucynacje. Agenci AI regularnie sugerują nazwy pakietów, które nie istnieją. Badania USENIX Security 2025, testujące 16 dużych modeli językowych na 576 tysiącach próbek, wykazały, że około 19,7% rekomendacji pakietów generowanych przez AI odnosiło się do pakietów nieistniejących w rejestrach – model wymyślił je na podstawie statystycznych wzorców z danych treningowych, bez sprawdzenia w rejestrze.

Charlie Eriksen, badacz z Aikido Security, ukuł dla tej klasy ataków termin „slopsquatting”. W przeciwieństwie do typosquattingu, gdzie ofiara musi pomylić się w pisowni, slopsquatting wymaga jedynie, by agent AI regularnie halucynował konkretną nazwę, którą atakujący następnie rejestruje ze złośliwym ładunkiem.

To, co czyni slopsquatting strukturalnie niebezpiecznym, to przewidywalność halucynacji AI. Gdy badacze powtórzyli identyczne zapytania dziesięciokrotnie, 43% halucynacyjnych nazw pakietów pojawiało się za każdym razem. Atakujący wystarczy, że uruchomi kilkadziesiąt zapytań wobec popularnego modelu, zidentyfikuje nazwy, które stale się powtarzają, i zarejestruje je, zanim zrobi to ktoś inny.

W styczniu 2026 roku Eriksen zarejestrował pakiet npm o nazwie react-codeshift – nazwa nieistniejąca, ale wygenerowana przez model językowy w wyniku połączenia dwóch rzeczywistych narzędzi, jscodeshift i react-codemod. Zanim zdążył defensywnie zastrzec tę nazwę, halucynacyjne odniesienie rozprzestrzeniło się już do 237 repozytoriów GitHub za pośrednictwem plików umiejętności agenta generowanych przez AI. Natychmiast po rejestracji odnotowano codzienne próby pobierania przez autonomicznych agentów.

To była halucynacja – mówi Eriksen. Rozprzestrzeniła się na 237 repozytoriów. Wygenerowała rzeczywiste próby pobrania. Jedyny powód, dla którego nie stała się wektorem ataku, to fakt, że dotarłem tam pierwszy.

Clinejection: jak jeden issue na GitHubie stał się atakiem na 5 milionów deweloperów

Incydent Clinejection, ujawniony w lutym 2026 roku, pokazał, jak agenci AI zintegrowani z potokami CI/CD zwielokrotniają ryzyko poza pojedyncze maszyny deweloperów.

9 lutego badacz bezpieczeństwa Adnan Khan ujawnił łańcuch podatności w repozytorium GitHub narzędzia Cline. Cline dodał w grudniu 2025 roku oparty na AI przepływ pracy do triażu issue, który używał claude-code-action od Anthropic do automatycznego odpowiadania na zgłoszenia. Konfiguracja zezwalała każdemu użytkownikowi GitHub na wywołanie akcji i dawała agentowi pełny dostęp do wykonywania kodu na runnerze.

Atakujący mógł w tytule issue umieścić ukryte instrukcje, które nakłoniły agenta do uruchomienia npm install z kontrolowanego przez atakującego commita, wykonującego złośliwy skrypt preinstall. Następnie technika zatruwania pamięci podręcznej GitHub Actions (Cacheract) wykorzystała współdzielony zakres pamięci między przepływami o niskich i wysokich uprawnieniach, umożliwiając atakującemu kradzież poświadczeń publikacyjnych do npm, VS Code Marketplace i OpenVSX.

Osiem dni po publicznym ujawnieniu – gdy jeden token npm nie został jeszcze właściwie odwołany podczas rotacji poświadczeń – nieznany aktor opublikował nieautoryzowaną wersję [email protected] w npm. Zmodyfikowana wersja instalowała OpenClaw, otwartoźródłowego agenta AI z dostępem do systemu plików i wykonywaniem poleceń, na każdej maszynie dewelopera, która zaktualizowała się w ciągu ośmiu godzin. Cline ma ponad 5 milionów użytkowników.

Jak zauważył badacz Snyk, Stephen Thoemmes, atak nie wymagał żadnej nowej techniki – jedynie połączenia dobrze znanych podatności (pośrednie wstrzykiwanie promptów, zatruwanie pamięci podręcznej, słabości modeli poświadczeń) w exploit uruchamiany pojedynczym zgłoszeniem na GitHubie. Punktem wejścia był naturalny język, nie kod.

Co mówią eksperci i agencje rządowe o ochronie przed agentami AI

1 maja 2026 roku CISA, NSA i ich partnerzy z Five Eyes – agencje cyberbezpieczeństwa Australii, Kanady, Nowej Zelandii i Wielkiej Brytanii – opublikowali „Careful Adoption of Agentic AI Services”, pierwsze skoordynowane, wielorządowe wytyczne bezpieczeństwa dotyczące wdrożeń agentowych.

Poradnik wprost potwierdził istnienie klasy ataków opisanych w tym artykule: „słabe lub celowo wprowadzające w błąd opisy narzędzi mogą powodować, że agenci wybierają narzędzia zawodnie, przy czym przekonujące opisy są wybierane częściej” – bezpośrednie uznanie, że LLMy mogą być poddawane socjotechnice poprzez dokumentację, czyli mechanizm, który kampania PromptMink już wykorzystywała.

Zalecenia agencji obejmują utrzymywanie zaufanych rejestrów zatwierdzonych komponentów zewnętrznych, ograniczanie agentów AI do list dozwolonych narzędzi i wersji oraz wymaganie ludzkiej zgody przed działaniami o wysokim wpływie. Wstrzykiwanie promptów określono jako „najbardziej uporczywe i najtrudniejsze do naprawienia zagrożenie” dla wdrożeń agentowych, wobec którego żadna pojedyncza kontrola nie jest wystarczająca.

Ramy wytycznych są celowo ostrożne: dopóki praktyki bezpieczeństwa, metody oceny i standardy nie dojrzeją, organizacje powinny zakładać, że systemy agentowe mogą zachowywać się nieprzewidywalnie, i odpowiednio planować wdrożenia, przedkładając odporność, możliwość odwrócenia działań i ograniczenie ryzyka nad korzyści wydajnościowe.

Jak zespoły programistyczne mogą się chronić

Badacze bezpieczeństwa i wytyczne CISA/Five Eyes zgadzają się co do kilku skutecznych kontroli, które pozostają użyteczne nawet gdy atakujący ewoluują swoje techniki.

Traktuj pakiety sugerowane przez agentów AI jako odrębną kategorię do weryfikacji. Każda zależność, którą agent AI sugeruje lub instaluje autonomicznie, powinna być domyślnie traktowana jako niezaufana, dopóki jej wydawca, historia wersji i zależności przechodnie nie zostaną przejrzane. To ten sam standard, który programiści stosują wobec każdego kodu firm trzecich – różnica polega na tym, że dodatki generowane przez agenta często omijają moment ludzkiej weryfikacji.
Wymuszaj polityki rejestrowe na poziomie CI/CD, nie tylko na stacji roboczej dewelopera. Kontrole stosowane tylko tam, gdzie pracują ludzie, nie przechwytują pakietów wprowadzanych przez agentów działających w potokach CI/CD lub środowiskach piaskownicy. Socket Firewall, funkcja staged publishing npm (ogólnie dostępna od 22 maja 2026) i podobne kontrole na poziomie rejestru egzekwują polityki niezależnie od tego, w jaki sposób zależność została wprowadzona.
Ogranicz agentów do wstępnie zatwierdzonych list zależności w wrażliwych środowiskach. Agent AI, który nie może zainstalować pakietu spoza dozwolonej listy, nie może zainstalować złośliwego pakietu, niezależnie od tego, co sugeruje LLM. Wytyczne CISA ujmują to jako wymóg ludzkiej zgody dla działań o wysokim wpływie.
Wdróż praktyki Software Bill of Materials. SBOM-y umożliwiają audytowanie zależności wprowadzonych przez agenta po fakcie. Zespoły programistyczne, które nie widzą, co zainstalowały ich agenty, nie mogą reagować na incydenty związane z tymi instalacjami.
Stosuj wykrywanie behawioralne. Tradycyjne narzędzia do analizy składu oprogramowania sprawdzają nazwy zależności w bazach CVE, które publikują informacje dopiero po ujawnieniu podatności. Ataki na łańcuch dostaw, które dotarły do TanStack, Mastra i Cline w 2026 roku, nie miały w momencie ataku żadnego CVE. Narzędzia analizy behawioralnej – badające, co pakiety faktycznie robią, a nie jak się nazywają – mogą wykryć podejrzane zachowania zanim pojawi się jakikolwiek CVE.

Kluczowe wyzwanie, które zidentyfikował Brad Arkin w swoim wpisie z 23 czerwca, pozostaje aktualne: kod trafia do środowisk deweloperskich w więcej miejsc, niż zespoły bezpieczeństwa zdążyły zmapować. Potok budowania to łatwy sukces. Laptopy deweloperów to cicha luka. Środowiska agentów to luka rosnąca najszybciej – i na razie większość organizacji nie traktuje jej jako części swojej powierzchni ataku.

Mechanizm techniczny, który umożliwia te ataki, to strukturalna cecha ekosystemu npm: hak postinstall. Gdy deweloper lub potok CI/CD uruchamia npm install, npm automatycznie wykonuje skrypty postinstall lub preinstall zdefiniowane w pliku package.json – zanim uruchomi się kod aplikacji i zanim większość narzędzi analizy statycznej zdąży sprawdzić, co właśnie trafiło do systemu. Hak uruchamia się z takim samym dostępem do systemu plików i środowiska jak proces dewelopera, co oznacza, że sięga do kluczy API, poświadczeń chmurowych, kluczy SSH i tokenów CI/CD przechowywanych w lokalnym środowisku.

Uruchomienie npm install --ignore-scripts blokuje ten mechanizm dla większości pakietów, ale flaga ma udokumentowane ominięcia. Pakiety używające natywnych rozszerzeń (binding.gyp) mogą ją obchodzić, a CVE-2025-69263 wykazało, że złośliwy plik .npmrc w zależności gitowej może całkowicie zastąpić binarny plik git. Wykrywanie behawioralne – monitorowanie, co pakiety faktycznie robią na poziomie kodu, zamiast sprawdzania nazw względem baz CVE – jest strukturalną odpowiedzią. Flaga to tylko częściowa kontrola.

To właśnie ten mechanizm techniczny stanowi podstawę działalności Socket: analiza zachowania zależności open-source zanim trafią do bazy kodu, zamiast czekania na pojawienie się CVE.

Każda z opisanych kampanii wykorzystuje ten sam mechanizm: hak postinstall to moment, w którym złośliwy ładunek ma dostęp do środowiska ofiary. To strukturalna cecha ekosystemu npm, której agenci AI nie omijają – wręcz przeciwnie, czynią go bardziej dostępnym, automatyzując proces instalacji.

Tak więc, podczas gdy agenci AI mogą zwiększać produktywność, ich niezdolność do weryfikowania pakietów przed instalacją tworzy nowe, poważne ryzyko. Dopóki agenci nie będą domyślnie sprawdzać, czy sugerowany pakiet istnieje, kto go utrzymuje i czy nie został oznaczony jako złośliwy, organizacje muszą traktować każdą zależność wprowadzoną przez AI jako potencjalnie niebezpieczną i odpowiednio dostosować swoje procesy bezpieczeństwa.