Uważaj na Skills podczas kodowania z AI (mogą zawierać podatności)

Cześć

 

Dziś będzie o bezpieczeństwie korzystanie z AI do kodowania (np. Claude Code czy Cursor) z nastawieniem na SKILLS.

 

Ale zanim, to czy pamiętasz wczesne lata npm (node package manager)?

Developerzy "z zachwytu" instalowali kolejne paczki bez zastanowienia, bo "ktoś to już napisał i działa". A potem okazywało się, że paczka z milionami pobrań tygodniowo kradnie tokeny i wysyła je gdzieś w świat.

 

Dokładnie to samo dzieje się teraz ze Skills w podejściu pracy z AI - z jedną ważną różnicą - jest gorzej.

 

Dlaczego?


Złośliwa paczka npm uruchamia się w kontekście Twojej aplikacji.
Złośliwy skill AI uruchamia się z uprawnieniami samego agenta.

Jeśli Twój agent ma dostęp do terminala, systemu plików, kluczy API, zmiennych środowiskowych - skill też to dostaje. Automatycznie. Bez żadnego dodatkowego kroku.

 

Bo skill to nie jest plik kodu. Nie przejdziesz go linterem. Nie wyłapie go statyczna analiza. To plik markdown - instrukcje napisane ludzkim językiem, które agent po prostu... czyta i wykonuje.

 

Wystarczą trzy linijki tekstu w SKILL.md, żeby agent wykonał komendę w powłoce.

 

Co mówią dane?

W lutym 2026 Snyk Labs - jedna z najbardziej znanych firm zajmujących się bezpieczeństwem kodu - opublikowała badanie pod nazwą ToxicSkills. Pierwsze tak duże badanie ekosystemu skills dla agentów AI.

Przeskanowali 3 984 skills z publicznych katalogów.

Wyniki:

  • 36,82% miało co najmniej jedną lukę bezpieczeństwa,
  • 534 skills (13,4%) zawierało co najmniej jeden krytyczny problem bezpieczeństwa,
  • 76 skills miało potwierdzone złośliwe payloady - kradzież credentials, backdoory, eksfiltracja danych.

 

Osobne badanie firmy Koi Security z stycznia 2026 znalazło 341 złośliwych skills na jednej platformie. 335 z nich należało do jednej skoordynowanej kampanii. Pięć z siedmiu najczęściej pobieranych skills na tej platformie było malwarem.

 

Jeden z udokumentowanych ataków działał tak: skill wyglądał normalnie, robił dokładnie to, co obiecywał. Ale miał sekcję "Prerequisites" - instrukcję, którą agent czytał i wykonywał zanim w ogóle zaczął działać. W środku... polecenie pobrania i uruchomienia skryptu.

Platforma została zamknięta.

 

Co można z tym zrobić w praktyce?

Kilka rzeczy, które sam stosuję:

 

Skill = zależność produkcyjna, nie kawałek dokumentacji.
Przed instalacją sprawdzam, skąd pochodzi i kto to napisał. Czy repozytorium wygląda wiarygodnie?

 

Czytam SKILL.md zanim go użyję.
Serio - to kilka minut. Szukam czy nie ma tam komend do wykonania, pobierania czegoś z zewnątrz, instrukcji "uruchom to zanim zaczniesz".

 

Oficjalne źródła > community marketplace.
Skills od twórców narzędzi mają dużo mniejsze ryzyko niż skills od anonimowego użytkownika z 3 commitami w historii.

 

Minimalne uprawnienia dla agenta.
Agent piszący kod nie potrzebuje dostępu do ~/.ssh ani produkcyjnych kluczy API. Sam mam osobny profil z ograniczonym dostępem do plików - i nie wyobrażam sobie pracy inaczej.

 

Popularność nie znaczy bezpieczeństwo.
Część złośliwych skills miała sztucznie podbite statystyki — boty, fake konta, masowe downloady. Gwiazdki na GitHubie to za mało.

 

Jest jeszcze temat CI/CD.

Aikido Security pokazało, że prompt injection przez skills może przejąć Twój pipeline CI/CD.


Jak to działa?

 

Agent osadzony w GitHub Actions przetwarza zewnętrzne dane - np. treść PR-a, komentarze, opisy commitów. Jeśli w tych danych znajdzie się złośliwa instrukcja, agent może ją potraktować jak polecenie i wykonać - przy każdym kolejnym commicie, automatycznie, bez wiedzy zespołu. Badacze potwierdzili, że dotknęło to już co najmniej pięć firm z listy Fortune 500.

 

Jest też inny wariant.

 

Jeśli Twój agent ma uprawnienia do wyszukiwania i instalowania narzędzi - a wiele konfiguracji domyślnie je ma - może zainstalować złośliwy skill samodzielnie. Bez Twojego udziału.

 

Wystarczy, że podczas pracy napotka zatrute README, opis w katalogu skills albo spreparowany wynik wyszukiwania. Agent czyta instrukcję, uznaje ją za legalne polecenie i wykonuje.

 

Człowiek nic nie klika. Nic nie zatwierdza.

 

Agent po prostu działa - tak jak go tego nauczyłeś.

 

Dlatego "zainstaluj tego skilla, bo ma 200 gwiazdek" to zdanie, które coraz częściej powinno zapalać czerwoną lampkę.

 

Ekosystem skills rośnie szybciej niż narzędzia do ich weryfikacji. A większość developerów nawet nie wie, że jest problem.

 

To dopiero początek.

 

Security w pracy z AI nie kończy się na sprawdzeniu skilla przed instalacją.

 

Co z kodem, który AI generuje w Twoim repo? Masz automatyczny security scan zanim cokolwiek trafi na produkcję? Masz AI Code Review, który łapie to, czego Ty możesz nie zauważyć? Masz guardrails - plik, który mówi AI czego NIGDY nie może zrobić w Twoim projekcie?

 

W programie Ewolucja Developera budujesz to od podstaw. Pipeline z security scanning. AI Code Review na każdym PR. Guardrails i standardy. Observability, żebyś wiedział co się dzieje na produkcji.

I najważniejsze : Security mindset od dnia pierwszego.

 

Niższa cena tylko do 31 marca 2026.

 

== Dołącz do Ewolucji Developera w niższej cenie 
(do 31 marca 2026) ==

 

Uff, to już wszystko.

 

Dzięki!
Damian Naprawa
ewolucjadevelopera.pl | wkontenerach.pl

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


P.S. Otrzymujesz tę wiadomość, bo należysz do społeczności wkontenerach.pl lub jesteś na pokładzie jednego z moich szkoleń. Jeśli już nie chcesz być ze mną w kontakcie to możesz wypisać się z dalszej komunikacji poprzez link, który podaję dalej. UWAGA: po kliknięciu wypiszesz się ze wszystkich informacji: w tym informacji o nowych aktualizacjach szkoleń, bezpłatnych materiałach oraz wszystkich ofertach - nawet jeśli jesteś na pokładzie któregoś ze szkoleń. Jeśli chcesz się wypisać tylko z wybranego tematu, wybranych maili — proszę odpisz na tę wiadomość. W przeciwnym wypadku: klikając tutaj WYPISUJESZ się ze WSZYSTKIEGO związanego z szkoladockera.pl oraz wkontenerach.pl
 
Damian Naprawa, Dąbrówki 12, 39-300 Mielec, NIP: 8172196938