Skan to nadal migawka

W czerwcu opisywaliśmy fałszywy skill, który przeszedł skanery Cisco i NVIDII i trafił do dwudziestu sześciu tysięcy agentów. Mechanizm był prosty: w chwili skanowania skill wskazywał na prawdziwą dokumentację, a treść pod tym adresem podmieniono dopiero po instalacji. Napisaliśmy wtedy zdanie, które okazuje się kluczowe także dziś: skan to migawka, a skill może zmienić zachowanie po tym, jak zaufanie zostało już przyznane.

NVIDIA wydała tymczasem SkillSpector — otwartoźródłowy skaner, który czyta umiejętność agenta i odpowiada na pytanie, czy bezpiecznie ją zainstalować. W sierpniu trafił do zestawienia najciekawszych narzędzi otwartoźródłowych miesiąca.

To jest dobre narzędzie i za chwilę pokażę, dlaczego liczby stojące za jego powstaniem w pełni uzasadniają jego istnienie. Ale odpowiada ono na pytanie postawione w złym momencie — i warto zrozumieć, dlaczego, zanim zacznie się traktować jego wynik jako przepustkę.

Liczby, które uzasadniają narzędzie

Zacznijmy od tego, co przemawia za tym narzędziem, bo przemawia mocno.

Badanie stojące za SkillSpectorem objęło 42 447 umiejętności z głównych marketplace'ów. Wynik: 26,1 procent zawiera co najmniej jedną podatność, a 5,2 procent wykazuje prawdopodobnie złośliwe intencje. Umiejętności, które dostarczają wykonywalny skrypt, są przy tym 2,12 razy bardziej narażone na zawieranie podatności niż te złożone z samych instrukcji.

Co czwarta umiejętność w publicznym obiegu ma realną lukę. Co dwudziesta wygląda na celowo złośliwą. Przy skali marketplace'ów agentowych, o której pisaliśmy przy okazji Paperclipa i czterech równoległych kanałów dystrybucji bez jednej warstwy przeglądu, to są liczby, które w pełni uzasadniają wypuszczenie skanera.

Powód, dla którego to boli, jest znany i nie zmienił się od czerwca. Umiejętność agenta to nie jest wtyczka działająca w piaskownicy. To zwykle plik z instrukcjami, a obok niego skrypt, który sięga do powłoki, zmiennych środowiskowych i katalogu z kluczami SSH. Uruchamia się z uprawnieniami agenta, czyli twoimi. Jedno ze źródeł ujmuje to zwięźle: model bezpieczeństwa bliższy jest tu rozszerzeniu przeglądarki niż aplikacji webowej w piaskownicy.

SkillSpector robi z tym rzecz sensowną. Skanuje repozytorium, adres, archiwum albo pojedynczy plik, przechodzi przez sześćdziesiąt cztery wzorce podatności w szesnastu kategoriach — od wstrzykiwania promptu i wyprowadzania danych po nadmierną sprawczość, zatruwanie pamięci i nadużycia specyficzne dla protokołu MCP. Pierwsza faza jest statyczna i trwa sekundy: analiza drzewa składniowego wyłapuje wywołania wykonujące kod, dynamiczne importy i sięganie do powłoki. Druga, opcjonalna, używa modelu językowego do oceny intencji — czyli do porównania tego, co umiejętność deklaruje, z tym, co faktycznie robi.

Na wyjściu jest ocena ryzyka od zera do stu, etykiety wagi i rekomendacja.

Pytanie zadane w złym momencie

I tu dochodzimy do sedna.

SkillSpector odpowiada na pytanie: czy bezpiecznie zainstalować tę umiejętność? To jest pytanie sensowne i, jak pokazują liczby, w jednym przypadku na cztery odpowiedź brzmi „nie".

Ale czerwcowy atak, który przeszedł przez skanery, polegał na czymś, czego to pytanie z definicji nie obejmuje. Tamten skill był bezpieczny w chwili instalacji. Wskazywał na prawdziwą dokumentację, nie zawierał złośliwego kodu, przeszedł kontrolę uczciwie. Stał się niebezpieczny później — gdy zmieniono treść pod zewnętrznym adresem, na który wskazywał.

Żadna analiza statyczna tego nie wychwyci, bo w momencie skanowania nie ma czego wychwycić. Nie jest to wada implementacji, którą dałoby się poprawić lepszymi regułami. To jest właściwość samego podejścia: skan bada stan w jednym punkcie czasu, a zaufanie przyznaje się na cały okres używania.

Ten kształt problemu wraca u nas z uporem w zupełnie różnych kontekstach. Podpis pakietu był ważny, bo artefakt naprawdę powstał w tym repozytorium — tylko konto opiekuna było w cudzych rękach. Łatka wygenerowana przez model wygląda jak łatka i przechodzi testy, a w trzech przypadkach na cztery czegoś nie domyka. Za każdym razem kontrola działa poprawnie i za każdym razem mierzy coś innego, niż potrzebujemy.

Ocena, która zbiera dwadzieścia znalezisk w jedną liczbę

Jest jeszcze drugi problem, niezależny od poprzedniego, i pokazał go niezależny przegląd narzędzia.

Autor przetestował SkillSpectora na trzech umiejętnościach. Na celowo spreparowanej pułapce narzędzie zwróciło pełne sto punktów i twarde „nie instaluj" — i to była odpowiedź poprawna. Ale, jak zauważa, najgorszą rzeczą, jaką wykryło, był zwykły tekst w pliku instrukcji, a nie kod.

Ciekawszy jest drugi przypadek. Na legalnej umiejętności do automatyzacji — takiej, którą autor chciałby wdrożyć i której nie zainstalowałby bez sprawdzenia — skaner zgłosił dwadzieścia znalezisk. Szesnaście z nich dotyczyło wywołań interfejsu GitHuba, czyli tego, na czym polega cała deklarowana funkcja tej umiejętności.

I dalej zdanie, które jest właściwą krytyką: ocena zwinęła te dwadzieścia znalezisk w jedną liczbę całkowitą i nie powiedziała, które cztery z nich naprawdę mają znaczenie.

To jest problem każdego wskaźnika zbiorczego, ale w tym kontekście szczególnie kosztowny. Liczba od zera do stu wygląda jak werdykt, a jest streszczeniem — i streszcza akurat to, co trzeba przeczytać w całości. Umiejętność, która robi swoją robotę, generuje sygnały nieodróżnialne od umiejętności, która robi coś podejrzanego, bo jedno i drugie sięga do sieci i do plików.

Autor tego przeglądu tytułuje go trafnie: od zielonego znaczka do prawdziwego osądu. Ryzykiem nie jest tu narzędzie. Ryzykiem jest zielony znaczek — moment, w którym ktoś uzna, że skoro ocena wyszła niska, sprawdzanie się skończyło.

Uczciwie: co ten skaner robi dobrze

Trzymajmy proporcje, bo krytyka powyżej dotyczy sposobu użycia, nie jakości wykonania.

SkillSpector wyłapuje to, co da się wyłapać statycznie, i robi to szeroko: ukryte instrukcje, wyprowadzanie danych, sięganie po poświadczenia, niebezpieczne wzorce wykonania kodu, podatne zależności sprawdzane w publicznej bazie. Przy jednej czwartej umiejętności zawierającej realną lukę to jest realna wartość — większość tych luk jest zwyczajna i widoczna w kodzie.

Narzędzie ma też cechy, które świadczą o przemyśleniu problemu operacyjnego. Można ustalić linię bazową, przyjąć znane znaleziska i skanować wyłącznie pod kątem nowych — co rozwiązuje dokładnie ten problem szesnastu wywołań interfejsu, o którym była mowa wyżej. Wyniki da się wyprowadzić w formacie nadającym się do potoku ciągłej integracji. Analizę semantyczną można uruchomić na modelu działającym lokalnie, bez wysyłania cudzego kodu na zewnątrz.

NVIDIA prowadzi przy tym równolegle katalog umiejętności weryfikowanych, gdzie oprócz skanu automatycznego jest przegląd ludzki i podpis. To jest odpowiedź na inną część problemu niż sam skaner i warto ją odnotować.

Trzeba też powiedzieć rzecz oczywistą, a pomijaną: narzędzie nie obiecuje, że rozwiązuje problem zmiany treści po instalacji. Odpowiada na pytanie, które zadaje, i odpowiada na nie dobrze. Krytyka dotyczy tego, jak takie narzędzia bywają używane — jako brama, po przejściu której przestaje się patrzeć.

Co z tego wynika dla obrońcy

Rzecz pierwsza jest wprost do zastosowania: uruchom skaner, ale nie traktuj wyniku jako werdyktu. Przeczytaj znaleziska, nie ocenę. Przy legalnej umiejętności większość z nich będzie opisem tego, do czego ona służy — i właśnie dlatego liczba zbiorcza jest tu najmniej użyteczną częścią wyniku.

Rzecz druga wynika z czerwcowego przypadku i jest ważniejsza. Skan przed instalacją nie zastępuje obserwacji po instalacji. Jeśli umiejętność sięga do zewnętrznego adresu po treść, konfigurację albo instrukcje, to ten adres jest częścią jej zachowania, a nie częścią jej kodu — i może się zmienić w dowolnym momencie. Umiejętności pobierające cokolwiek z zewnątrz zasługują na osobną kategorię ryzyka, niezależnie od tego, co pokazał skan.

Rzecz trzecia jest architektoniczna i wraca u nas od tygodni. Wszystko powyższe dotyczy tego, co agent wykonuje. Nic z tego nie zmienia tego, do czego agent ma dostęp. Umiejętność uruchamiana z uprawnieniami agenta jest groźna dokładnie w tej mierze, w jakiej te uprawnienia są szerokie — i to jest jedyna zmienna, która działa niezależnie od tego, czy skan cokolwiek wykrył.

Jedna myśl na koniec

Historia zabezpieczeń łańcucha dostaw oprogramowania to seria coraz lepszych odpowiedzi na pytanie, czy artefakt jest w porządku w chwili, gdy go bierzemy. Sumy kontrolne, podpisy, poświadczenia pochodzenia, skanery, teraz skanery umiejętności agentowych. Każde z tych narzędzi było potrzebne i każde zamknęło jakąś klasę problemów.

Wszystkie mają jednak wspólną cechę: badają stan w momencie pobrania, a zaufanie przyznajemy na cały okres używania. Dopóki artefakt był plikiem, który się instalowało i który potem leżał bez zmian, ta różnica była teoretyczna. Odkąd artefaktem jest umiejętność sięgająca w czasie działania po treść z cudzego serwera, przestała być.

NVIDIA odpowiedziała dobrze na pytanie, które zadała. Czerwcowy atak przypomniał, że to nie jest jedyne pytanie — a nasz własny zapis z tamtego miesiąca brzmi tak samo aktualnie: skan to migawka, a zaufanie przyznaje się na dłużej.

Źródła

Help Net Security — omówienie narzędzia w zestawieniu najciekawszych rozwiązań otwartoźródłowych sierpnia, z opisem obsługiwanych formatów wejścia, przebiegu analizy statycznej oraz ustaleniem, że umiejętności dostarczające wykonywalny skrypt są 2,12 razy bardziej narażone na podatności: https://www.helpnetsecurity.com/2026/08/03/skillspector-open-source-agent-skill-security-scanner/

NVIDIA / GitHub — repozytorium projektu z opisem zakresu wykrywania, mechanizmu linii bazowej pozwalającej skanować wyłącznie pod kątem nowych znalezisk oraz możliwości uruchomienia analizy semantycznej na lokalnym modelu: https://github.com/NVIDIA/SkillSpector

Towards Data Science — niezależny przegląd narzędzia na trzech umiejętnościach, z ustaleniem, że przy legalnej umiejętności szesnaście z dwudziestu znalezisk dotyczyło jej własnej deklarowanej funkcji, a ocena zbiorcza nie wskazała, które z nich mają znaczenie: https://towardsdatascience.com/from-green-checkmark-to-real-judgment-auditing-ai-agent-skills-with-skillspector/

AI Insiders — dane z badania obejmującego 42 447 umiejętności z głównych marketplace'ów, z odsetkiem podatnych i prawdopodobnie złośliwych, oraz porównanie modelu zagrożeń do problemu złośliwych pakietów w rejestrach: https://aiinsiders.net/article/nvidia-ships-open-source-scanner-for-agent-skill-supply

AgentConn — szczegółowy opis kategorii wykrywania, sposobu naliczania oceny ryzyka oraz kontekstu katalogu umiejętności weryfikowanych prowadzonego przez NVIDIĘ: https://agentconn.com/skills/skillspector/