Slopsquatting: gdy AI podpowiada złośliwy pakiet

Od błędu w kodzie do złośliwego pakietu

Kiedy programista korzysta z modelu językowego do napisania fragmentu kodu, często otrzymuje też sugestię importu: import data_utils, from analytics import plot czy coś podobnego. Problem w tym, że niektóre z tych nazw po prostu nie istnieją — model generuje je na podstawie wzorców z treningu, nie z aktualnej listy pakietów dostępnych w rejestrze. Jeśli deweloper nie sprawdzi nazwy przed instalacją, a atakujący zarejestrował już taką nazwę z złośliwym zawartością, instalacja kończy się kompromitacją całego projektu.

To zjawisko nazwano slopsquatting — analogia do typosquattingu, ale zamiast literówki w nazwie domeny następuje błędna sugestia modelu AI. HackerOne w analizie z 2025 roku wskazuje, że ataki na łańcuch dostaw wzrosły wyraźnie: 12 incydentów typu upstream implant (jak XZ Utils) i 10 ataków typu dependency confusion odnotowano w 2025 roku. W obu przypadkach kluczową rolę odgrywała automatyzacja — atakujący używali narzędzi AI do maskowania złośliwego kodu jako standardowej aktualizacji.

Jak działa atak w praktyce

W scenariuszu z dokumentacji Repello AI i HackerOne typowy łańcuch wygląda następująco:

1. Deweloper prosi model AI o generację funkcji, która ma przetwarzać dane JSON.
2. Model sugeruje import z pakietu json-processor-v2 — nazwa brzmi wiarygodnie, ale taki pakiet nie istnieje w npm czy PyPI.
3. Atakujący zarejestrował już nazwę json-processor-v2 z złośliwym kodem, który otwiera backdoor przy importowaniu.
4. Jeśli deweloper zainstaluje pakiet bez weryfikacji, złośliwy kod trafia do kodu źródłowego, a następnie do produkcji.

W przeciwieństwie do klasycznego dependency confusion — gdzie atakujący tworzy pakiet z nazwą podobną do popularnej biblioteki — slopsquatting wykorzystuje błędy modelu AI, które są trudniejsze do wykrycia, bo nazwa jest technicznie unikalna i nie zawiera oczywistych literówek.

Skala problemu

Według danych z raportów 2025-2026:

• Ponad 512 847 pakietów zawierało złośliwy kod w analizowanych zbiorach (HackerOne, SentinelPRO).
• 80% zależności w projektach pozostaje niezałatanych przez ponad rok.
• AI służy do automatyzacji maskowania: złośliwe aktualizacje są projektowane tak, by wyglądały jak regularne poprawki bezpieczeństwa.

Należy podkreślić, że nie chodzi o błąd samego modelu AI. Modele generują tekst na podstawie statystyk z danych treningowych; jeśli nazwa pakietu występowała często w podobnym kontekście w innych projektach, model może ją polecić. Brak weryfikacji ze strony użytkownika to główny czynnik ryzyka.

Co z tym zrobić

W raportach CISA, OWASP LLM Top 10 i MITRE ATLAS zaleca się kilka warstw ochrony:

• Spis zależności (SBOM) — dokumentacja każdej używanej biblioteki z wersją i źródłem.
• Weryfikacja nazw przed instalacją — nawet jeśli nazwa wygląda logicznie, trzeba sprawdzić, czy istnieje w oficjalnym rejestrze.
• Kontrola tożsamości wydawcy — ataki kompromitowania konta dewelopera (maintainer account compromise) są coraz częstsze.
• Przegląd kodu generowanego przez AI — model jest narzędziem, nie autorytetem; każda sugestia importu wymaga potwierdzenia.

W erze agentic AI — gdzie autonomiczne systemy mogą sama instalować pakiety, aktualizować zależności czy nawet generować nowe moduły — ryzyko slopsquattingu rośnie w tempie, którego tradycyjne skanery podatności nie są w stanie nadążyć. Problem nie jest technicznie trudny do zrozumienia: chodzi o to, by generatywna AI nie stała się nieświadomym kanałem dystrybucji złośliwego kodu.

Źródła: HackerOne (2025) — analiza slopsquattingu w łańcuchu dostaw; Repello AI — przewodnik po atakach na AI supply chain; SentinelPRO AI — przegląd ataków 2025 z danymi o XZ Utils i dependency confusion; Michigan Tech / OWASP LLM Top 10 — klasyfikacja SL05 (supply chain).