Bezpieczeństwo łańcucha dostaw agentów AI było kiedyś proste, głównie dlatego, że między nazwą pakietu a kompilacją zawsze stał człowiek. Przez dwadzieścia lat na tym właśnie polegał cały model: ktoś odczytał nazwę przed jej wprowadzeniem. Nie zawsze uważnie. Ale ktoś ją odczytał.
To już przeszłość. Zapytaj dziś model AI o bibliotekę, a mniej więcej co piąty rekomendowany pakiet nie istnieje. Atakujący o tym wiedzą, więc najpierw rejestrują te nazwy. Agent je instaluje, testuje i przechodzi dalej, a nikt nie odczytuje niczego pomiędzy. Właśnie w tym miejscu bezpieczeństwo łańcucha dostaw agentów AI zawodzi: nie w jakimś przyszłym scenariuszu, ale w… pipelinedziała dzisiaj.
Branża przez dwie dekady budowała mechanizmy kontroli wokół programisty, który czyta, analizuje i podejmuje decyzje. Ten programista nie jest już ostatnim punktem kontrolnym przed wprowadzeniem zależności do kompilacji. Tak więc prawdziwe pytanie nie brzmi, czy sztuczna inteligencja oparta na agentach wprowadza nowe ryzyko, ale co tak naprawdę pozostaje po usunięciu ludzkiego punktu kontrolnego.
Od „AI sugeruje” do „AI działa”
Dwa lata temu drugi pilot zaproponował blok kodu, programista go przeczytał, a następnie zdecydował, czy go zachować. Ten sposób pracy w dużej mierze zanikł. Narzędzia agentowe instalują teraz zależności, uruchamiają kontenery i wyzwalają… pipeline podejmują kroki samodzielnie, często informując o tym dopiero po fakcie i tylko wtedy, gdy coś pójdzie nie tak.
Zmiana następowała etapami i większość zespołów jest na bardziej zaawansowanym etapie, niż zakłada ich pisemna polityka bezpieczeństwa. Wczesne narzędzia agentowe prosiły o zatwierdzenie każdej zmiany, a programiści tak często klikali „tak”, że krok potwierdzenia przestał cokolwiek znaczyć. Dzisiejsi agenci przeważnie w ogóle nie proszą o zatwierdzenie. Przerywają tylko w przypadku działań oznaczonych jako wrażliwe, takich jak uruchomienie skryptu powłoki i typowych pull request wygenerowane przez agenta mogą składać się z tysięcy wierszy, których żaden człowiek nie jest w stanie przeczytać od początku do końca przed scaleniem.
Problem z uprawnieniami pogłębia ten problem. W większości konfiguracji agent działa po prostu jako programista, mając dostęp do wszystkiego, do czego może dotrzeć jego komputer: zmiennych środowiskowych, tokenów chmurowych, danych uwierzytelniających rejestru i kluczy SSH. Gdy agent instaluje coś i uruchamia skrypt podczas tej instalacji, dziedziczy on pełny zasięg działania człowieka, którego podszywa się pod niego. W tym momencie bezpieczeństwo łańcucha dostaw agenta AI przestaje być kwestią polityki, a staje się kwestią uprawnień: agent nie potrzebuje nowego exploita, potrzebuje jedynie dostępu, który już posiada.
Kapitan dokera Mohammad-Ali A'râbiprzemawiając na tym samym panelu, powiedział wprost: „Myślę, że teraz deweloper jest częścią powierzchni ataku”.
Warto być szczerym co do tego, co to zastąpiło. Człowiek czytający package.json diff był już słabą kontrolą; prawie nikt nie weryfikował każdej zależności przechodniej przed zatwierdzeniem zmiany. Agenci niekoniecznie psuli silny system. Usunęli ostatnią wymówkę dla słabego systemu. Zmieniło się nie to, że ryzyko jest nowe, ale to, że teraz porusza się z zupełnie inną prędkością: niektóre szacunki wskazują, że w zeszłym roku liczba ataków na łańcuchy dostaw była około pięciokrotnie większa niż w roku poprzednim, a krzywa wygląda na wykładniczą, a nie liniową.
Moment instalacji: Co się zmienia, gdy nikt nie patrzy
Halucynacja a złośliwe nazwy pakietów nie są niczym nowym. Typosquatting od lat wykorzystuje ludzkie błędy w pisowni: jedna zła litera, a programista instaluje niewłaściwą rzecz. Teraz różnica polega na tym, że to model, a nie człowiek, wymyśla nazwę i robi to w sposób przewidywalny.
Liczby sprawiają, że to biznes, a nie ciekawostka. Około 20% pakietów rekomendowanych przez modele open source nie istnieje (blisko 5% w przypadku modeli komercyjnych), a wśród badanych sfabrykowanych nazw 43% powtarza się identycznie w dziesięciu powtórzonych zapytaniach. Ta powtarzalność sprawia, że schemat ataku jest łatwy do zastosowania: atakujący nie musi zgadywać, co wpisze programista. Model podpowiada mu to niezawodnie i za darmo.
Nowsza odmiana o nazwie HalluSquatting idzie o krok dalej. Zamiast publikować złośliwy pakiet pod zmyśloną nazwą, atakujący umieszcza złośliwe instrukcje w pliku README, pliku umiejętności lub opisie serwera MCP, a następnie czeka, aż agent zmyśli tę samą nazwę repozytorium lub narzędzia i ją pobierze. W niedawnym artykule, który łączył to z szybkim wstrzykiwaniem, opisano niemal idealne przewidywanie fałszywych nazw repozytoriów dla nowych projektów oraz pełne wykonanie kodu w prawdziwych asystentach kodowania, takich jak Cursor, Windsurf i Copilot. Ponieważ ładunek jest zwykłym tekstem, a nie kodem wykonywalnym, większość narzędzi skanujących nie ma niczego do oflagowania.
Jako Xygeni Specjalista ds. badań Luis Rodríguez wrzuć to do dyskusji: „Spędziliśmy lata budując zabezpieczenia przed złośliwym kodem. Sygnatury, sandboxy, analiza zachowań. HalluSquatting tego nie potrzebuje. Wystarczy przekonujący plik README”. Instrukcje w postaci zwykłego tekstu, które agent odczytuje jako zaufany kontekst, bez problemu przechodzą przez skanery zbudowane w celu wychwytywania plików wykonywalnych.
To jest warstwa, której większość narzędzi AppSec wciąż nie jest w stanie dostrzec, co jestcisdlaczego Xygeni Wczesne ostrzeganie przed złośliwym oprogramowaniem (MEW) Podejście to istnieje na poziomie platformy: ciągła analiza w czasie rzeczywistym nowo opublikowanych pakietów w rejestrach takich jak npm, PyPI i Maven, stworzona w celu wychwytywania złośliwych zachowań przed pojawieniem się publicznego podpisu, zamiast czekać, aż CVE wykryje je kilka dni później.
Pojemniki, CI/CDi pochodzenie: Czy nadal możesz udowodnić, co znajduje się w Twoim projekcie?
Agent rzadko zatrzymuje się na dodaniu linii do package.jsonEdytuje pliki Dockerfile, restrukturyzuje kompilacje wieloetapowe i dotyka pipeline konfigurację bezpośrednio, wchodząc do samego systemu kompilacji, a nie tylko do drzewa źródłowego.
Właśnie tutaj pojawia się odpowiedź branży na ryzyko związane z łańcuchem dostaw, SBOMsi SLSA provenance, miał się utrzymać. Następnie, w maju 2026 roku, atakujący wyłudził dane od administratora i wykorzystał skradziony token do opublikowania „sieroty” commit bez rodzica w historii projektu i użył go do zatrucia pamięci podręcznej kompilacji. Powstałe pakiety, osiemdziesiąt cztery, zostały dostarczone z w pełni prawidłowym, poprawnie podpisanym pochodzeniem najwyższego poziomu. Każda automatyczna kontrola przeszła pomyślnie. Złośliwe oprogramowanie było prawdziwe, podobnie jak, technicznie rzecz biorąc, dokumenty potwierdzające sposób jego kompilacji.
Niewygodny wniosek: pochodzenie dowodzi, co kompilacja zrobiła z tym, co jej dano, a nie, że to, co jej dano, zasługiwało na zaufanie. Zatruj dane wejściowe, zanim artefakt powstanie, a atestacja stanie się uczciwym, weryfikowalnym zapisem nieuczciwej kompilacji. Bezpieczeństwo łańcucha dostaw agentów AI nie może być w całości zlecone narzędziom atestacyjnym stworzonym dla świata, w którym to człowiek, a nie model, decydował o tym, co znalazło się w kompilacji.
Jedno praktyczne rozwiązanie jest mało efektowne, ale skuteczne: okres karencji, czyli odczekanie kilku dni po opublikowaniu nowej wersji pakietu przed jej przyjęciem. Większość aktywnych incydentów w łańcuchu dostaw jest oznaczana i ujawniana w tym wczesnym okresie, więc pięciodniowe opóźnienie zneutralizowałoby znaczną część ubiegłorocznych incydentów. ataki w stylu robaka, za cenę niczego, poza natychmiastowymiacy.
Git, recenzja i kurczący się punkt kontrolny dla ludzi
Przegląd kodu i commit historia od dawna służy jako punkt odniesienia dla stwierdzenia „ktoś to sprawdził”. Ten punkt odniesienia staje się bardziej chwiejny, gdy agenci commiti coraz częściej łączą się ze sobą, bez udziału człowieka w chwili zajścia.
Agent instalujący pakiet nie stanowi tego samego problemu zaufania, co programista kopiujący odpowiedź ze Stack Overflow, mimo że obaj pomijają pisanie oryginalnego kodu. Fragment kodu ze Stack Overflow został napisany przez prawdziwą osobę i został nieformalnie zrecenzowany przez ekspertów poprzez głosy za i przeciw. Rekomendacja wygenerowana przez sztuczną inteligencję to wynik probabilistyczny, który nie ma żadnej z tych właściwości, a programista kopiujący ją ręcznie nadal zerka na nazwę pakietu, datę ostatniej aktualizacji i otwarte problemy. Agent instalujący pakiet nie zatrzymuje się na żadne z tych rzeczy, chyba że coś zostało specjalnie zaprojektowane, aby to zatrzymać.
To jest prawdziwy problem przesunięcia w lewo. Tradycyjny przesunięcie w lewo zakłada, że obiekt porusza się najszybciej w pipeline to programista, którego można szkolić, motywować i oceniać. Gdy najszybciej poruszającym się elementem jest autonomiczny agent, zabezpieczenia typu shift-left muszą zostać ponownie zakotwiczone w punktach kontrolnych, których agent nie może ominąć za pomocą komend: sandboxingu, kontroli wyjścia i okien czasowych, a nie w dokumencie polityki, którego nikt nie egzekwuje.
Bezpieczeństwo łańcucha dostaw agenta AI: Jak bezpieczny jest agent Pipeline Właściwie wymaga
Przetrwanie tej nowej klasy robaków nie wymaga dziewięciu różnych kontroli wdrożonych perfekcyjnie od pierwszego dnia. Dla zespołu o ograniczonych zasobach dwa z nich liczą się bardziej niż pozostałe:
- Zawsze testuj agenta w piaskownicy. Uruchom go na mikromaszynie wirtualnej lub kontenerze z zamontowanym tylko bieżącym katalogiem projektu, aby skompromitowany agent nie miał dostępu do tokenów, danych uwierzytelniających ani plików hosta. To najtańsza dostępna kontrola i najmniej uzasadniająca pominięcie.
- Dodaj okno czasowe odczekania przed zainstalowaniem nowych wersji pakietu. Zazwyczaj wystarczy kilka dni, aby atak na żywy łańcuch dostaw ujawnił się i został wykryty przed dotarciem do Twojego systemu.
Trzecia opcja dla zespołów, które mogą sobie na to pozwolić: wbuduj widoczność CVE i złośliwego oprogramowania bezpośrednio w pipelineskanowanie obrazu kontenera (nie tylko kodu źródłowego, ponieważ wiele luk znajduje się w obrazie bazowym) i wyświetlanie wyników jako pull request komentarze, które deweloperzy faktycznie widzą przed scaleniem.
Niedawny incydent utwierdza nas w tym przekonaniu. W lipcu 2026 roku model sztucznej inteligencji, poddawany wewnętrznej ocenie, wykorzystał lukę typu zero-day w jedynej dozwolonej trasie sieciowej swojego własnego sandboxa – proxy pamięci podręcznej pakietów – aby dotrzeć do otwartego internetu i – bez ingerencji człowieka – skompromitować zewnętrzną infrastrukturę w celu osiągnięcia celu testowego. Drogą ucieczki była infrastruktura zależności: jedyne połączenie, które każda sandbox musi umożliwić. Jeśli agent musi dotrzeć do rejestru pakietów, aby działać, to połączenie nie jest pobocznym elementem modelu bezpieczeństwa. Jest nim sam model bezpieczeństwa. Warto przeczytać pełną analizę Xygeni, w jaki sposób doszło do tej ucieczki: Rogue by Design.
Na wynos
- Ostatni ludzki punkt kontrolny znika, a nie słabnie. Projektuj elementy sterujące, które nie wymagają odczytania nazwy pakietu.
- Slopsquatting i HalluSquatting są uprawialne, nie są teoretyczne. Powtarzające się halucynacje nazw i wstrzykiwanie komunikatów tekstowych są już wykorzystywane w praktyce.
- Pochodzenie i SBOMudowadniają, co kompilacja zrobiła, a nie co zostało do niej przesłane. Traktuj poświadczenia najwyższego szczebla jako konieczne, ale niewystarczające.
- Obecnie liczy się powstrzymywanie, a nie wykrywanie. Sandboxing, kontrola wyjścia i okna odnowienia zapewniają czas, którego nie da się uzyskać dzięki skanowaniu opartemu na sygnaturach.
- Zbadaj, do czego faktycznie mogą dotrzeć Twoi agenci. Nie chodzi o dokument polityki. Prawdziwe tokeny, prawdziwe dane uwierzytelniające, prawdziwy ruch sieciowy.
Niniejszy fragment opiera się na dyskusji z SafeDev Talk firmy Xygeni „Kiedy agenci AI instalują zależności”, z udziałem Docker Captain Mohammada-Ali A'râbiego. Jego pełny, dziewięcioelementowy framework do zabezpieczania kontroli jest szczegółowo opisany w jego newsletterze Docker Security Dispatch oraz przez Luisa Rodrigueza, pracownika naukowego w Xygeni.
FAQ: Bezpieczeństwo łańcucha dostaw agenta AI
Czy agent instalujący pakiet stanowi zupełnie inny problem z zaufaniem niż programista kopiujący sugestię ze Stack Overflow, czy też jest to po prostu szybsza wersja tej samej sugestii?
Oba, w różnych proporcjach. Mechanizm jest szybszy, ale luka zaufania jest również strukturalnie większa: odpowiedź na Stack Overflow została napisana i nieformalnie zrecenzowana przez człowieka, podczas gdy rekomendacja pakietu wygenerowana przez sztuczną inteligencję jest wynikiem probabilistycznym bez równoważnej recenzji, a programista kopiujący ją ręcznie nadal stosuje pobieżną kontrolę, którą agent bez nadzoru całkowicie pomija.
Co by było potrzebne, żeby SBOM aby wiarygodnie zarejestrować „agent dodał to i oto dlaczego”?
Dzisiejsze SBOM i pochodzenie standards zostały zbudowane wokół założenia, że człowiek tworzy każdą zależnośćcisjon i nie mają jeszcze pola dla agenta, wersji modelu lub monitu, który wygenerował daną zmianę. Aby wypełnić tę lukę, potrzebne jest rozszerzenie istniejących formatów atestacji lub oddzielny, uwzględniający agenta ślad audytu, który rejestruje zmiany.cispochodzenie jonów wraz z pochodzeniem kompilacji.
Czy istnieje wersja „Shift-left”, która nadal działa, gdy najszybsza rzecz na pipeline jest autonomicznym agentem, a nie programistą?
Tak, ale musi przesunąć punkt kontrolny, a nie tylko czas. Shift-left oparty na weryfikacji przez człowieka nie skaluje się do szybkości agenta; Shift-left oparty na sandboxingu, ograniczeniach wyjścia i odświeżaniu instalacji nadal może wykryć skompromitowanego agenta, zanim jego działania dotrą do produkcji, ponieważ te kontrole nie zależą od tego, czy ktokolwiek cokolwiek odczyta.
