Слопсквотинг: коли ШІ вигадує пакет, який ви ставите

ШІ-помічник відповідає на ваше запитання акуратними змінами й одним новим імпортом. Назва пакета звучить саме так, як мала б звучати справжня бібліотека, тож ви запускаєте запропоновану команду встановлення.

Тепер цей пакет справді існує. Його зареєстрували минулого тижня, коли хтось помітив, що помічники раз у раз пропонують цю назву, і його скрипт встановлення запустився раніше, ніж ви прочитали хоч рядок коду.

Слопсквотинг — це атака на ланцюг постачання ПЗ, у якій зловмисник реєструє назву пакета, яку вигадують ШІ-помічники для програмування, і чекає, поки розробники встановлять його за порадою помічника. Ця назва не є одруківкою справжнього пакета. Це правдоподібна назва, якою не користувалася жодна справжня бібліотека, доки її не зайняв зловмисник.

Термін запропонував Seth Larson, security developer-in-residence у Python Software Foundation, як гру слів із тайпсквотингом. Різниця важлива: тайпсквотинг чекає на помилку людини, а слопсквотинг на помилку моделі.

Достатньо часто, щоб на це можна було розраховувати. Spracklen із колегами в дослідженні, представленому на USENIX Security 2025, згенерували 576 000 зразків коду на Python і JavaScript за допомогою 16 великих мовних моделей (LLM).

Комерційні моделі вигадували пакети в середньому щонайменше в 5,2% випадків, а моделі з відкритим кодом у 21,7%. Дослідження зафіксувало 205 474 унікальні вигадані назви пакетів, тобто великий запас назв, які може зареєструвати зловмисник.

Атакою галюцинацію робить повторюваність. Якщо модель пропонує ту саму вигадану назву багатьом розробникам, зловмисникові достатньо зареєструвати її один раз.

Ланцюжок атаки має чотири кроки, і жоден не потребує доступу до вашої мережі:

1. Зібрати назви. Зловмисник дає популярним помічникам типові задачі з програмування й записує назви пакетів, яких немає в реєстрі.
2. Зареєструвати їх. Зловмисник публікує під цими назвами пакети в npm або PyPI, часто з робочою заглушкою, щоб нічого не виглядало зламаним.
3. Додати скрипт встановлення. Хук npm postinstall або крок збирання Python запускає код у момент встановлення, ще до будь-якого імпорту.
4. Чекати. Кожен розробник, який іде за порадою помічника, запускає цей скрипт від свого облікового запису, з доступом до своїх токенів і ключів.

У 2024 році Bar Lanyado з Lasso Security перевірив ідею на нешкідливій заглушці. Моделі раз у раз пропонували pip install huggingface-cli, назву, якою справжній проєкт ніколи не користувався, тож він зареєстрував її й за три місяці отримав понад 15 000 завантажень. README в одному з репозиторіїв Alibaba навіть почав радити користувачам встановити цей пакет.

Вправа про галюцинацію ШІ в назві пакета проводить той самий ланцюжок з місця розробника. Ви приймаєте зміни помічника, бачите, як запускається скрипт встановлення, а потім читаєте картку пакета в реєстрі, яку пропустили, і відкликаєте токен, що витік.

Знайдіть його в реєстрі до команди встановлення, а не після. Вигаданий пакет рідко провалює одну перевірку, зате провалює кілька разом:

• Вік. Опублікований кілька днів чи тижнів тому, без жодної історії.
• Версії. Один реліз або серія релізів за один день.
• Завантаження. Жменька або раптовий сплеск, що не відповідає віку пакета.
• Вихідний код. Немає прив’язаного репозиторію, або репозиторій не містить опублікованого коду.
• Видавець. Обліковий запис, який зареєструвався приблизно тоді ж, коли опублікував пакет.
• Скрипти встановлення. Хук postinstall чи крок збирання в пакеті, якому нема чого компілювати.

npm view <name> і сторінка пакета на pypi.org показують більшість цього за секунди. Якщо пропозиція помічника не проходить ці перевірки, попросіть у нього усталену бібліотеку з тим самим інтерфейсом.

Вважайте розкритим усе, до чого міг дістатися скрипт встановлення. Насамперед це облікові дані на машині: токен npm у .npmrc, хмарні профілі та SSH-ключі.

Спершу відкличте розкриті облікові дані, а потім видаліть пакет. Видалення залежності виправляє код, але локалізує інцидент лише виведення облікових даних з ладу.

Окремі перевірки ловлять один пакет. Командні контролі не дають наступній вигаданій назві дістатися до будь-кого:

• Приватний проксі реєстру зі списком схвалених пакетів відхиляє назви, яких ніхто не перевіряв.
• Скрипти встановлення за замовчуванням вимкнені. npm install --ignore-scripts або відповідне налаштування перекриває шлях, на який розраховує слопсквотинг, а пакети, яким скрипти справді потрібні, ідуть окремим списком винятків.
• Новий запис у package.json чи requirements.txt отримує таку саму увагу, як нова функція.
• Lock-файли з хешами цілісності не дають залежності тихо змінитися.

Наш огляд ризиків безпеки ШІ-асистентів для програмування ставить цю загрозу поряд з іншими шляхами в ланцюг постачання, які відкривають помічники. Версію тієї самої атаки, що спирається на людську помилку, описує наш посібник про тайпсквотинг.

Пакет лише одне з того, що помічник може імпортувати непомітно. Ще дві речі приходять тим самим шляхом, через пропозиції, прийняті без другого погляду.

Чужу ліцензію. Помічник може слово в слово відтворити код, на якому навчався, разом із копілефтною ліцензією. Вправа про ліцензійне зараження коду від ШІ простежує функцію до першоджерела, замінює її й додає ліцензійне сканування фрагментів до кожного релізу.

Чужі інструкції. Помічник читає файл правил у вашому репозиторії й виконує його за кожним запитом, тож цей файл теж частина вашого ланцюга постачання. Вправа про отруєння файлу правил простежує один рядок без рев’ю, що повернув обхід автентифікації в продакшн, а потім закріплює файл за власником коду.

Тести мають бути останнім рубежем, що ловить усе це, і їх помічники теж пишуть. Вправа про порожні тести від ШІ показує дванадцять зелених тестів, жоден з яких не перевіряв випадок, через який стався витік.

Слопсквотинг і тайпсквотинг — це одне й те саме?

Ні. Тайпсквотинг реєструє одруківку в назві справжнього пакета й чекає, поки людина помилиться. Слопсквотинг реєструє назву, якою не користувався жоден справжній пакет, і чекає, поки її запропонує ШІ-помічник.

Чи вигадують пакети новіші моделі ШІ?

Дослідження Spracklen показало, що частота дуже різниться між моделями, а нижча частота не означає нуль. Будь-який помічник може запропонувати назву, яку не перевіряв, тож перевірка в реєстрі має бути в робочому процесі незалежно від моделі.

Чи захищає lock-файл від слопсквотингу?

Лише після першого встановлення. Lock-файл фіксує вже встановлене, тож не дає пакету змінитися пізніше, але нічого не робить у момент, коли ви додаєте вигаданий пакет. Перевірка має відбутися до першого встановлення.

Як навчити розробників помічати вигадані пакети?

Дайте їм встановити такий пакет у безпечному середовищі й подивитися, що робить його скрипт. Наш курс «Безпечна розробка з ШІ-помічниками» починається саме з цього, а далі охоплює інше, що створює помічник, і доступи, які він має.

Відкрийте залежність, яку ваша команда додала останньою за порадою помічника, і проженіть її через шість перевірок у реєстрі вище. Якщо щось виглядає не так, замініть облікові дані на машинах, де її встановлювали, ще до того, як видалити пакет.

Кожну вправу з каталогу безпеки ШІ та LLM можна спробувати безкоштовно. Щоб навчити інженерну команду, зв’яжіться з нами.

• Spracklen et al., We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs (USENIX Security 2025)
• The Register, AI bots hallucinate software packages and devs download them (березень 2024)