Штучний інтелект змінив підхід розробників до написання коду. Інструменти на кшталт GitHub Copilot, ChatGPT і Claude здатні генерувати функціональний код із природномовних запитів, що призвело до появи нового стилю програмування — так званого vibe coding. Проте ця технологічна революція принесла з собою несподівану загрозу кібербезпеці, яку дослідники назвали слопсквоттингом.
Що таке слопсквоттинг
Слопсквоттинг (slopsquatting) — це новий тип атаки на ланцюг постачання програмного забезпечення, який використовує схильність великих мовних моделей до галюцинацій. Термін вперше запропонував Сет Ларсон, дослідник безпеки та резидент Python Software Foundation, у 2025 році. Назва походить від поєднання слів “slop” (низькоякісний вихід штучного інтелекту) та “squatting” (захоплення).
На відміну від тайпсквоттингу, де зловмисники реєструють доменні імена зі схожими до популярних назвами, розраховуючи на помилки користувачів при введенні, слопсквоттинг експлуатує помилки самого штучного інтелекту. Коли AI-асистент для програмування генерує код, він іноді рекомендує пакети, які насправді не існують — галюцинує назви бібліотек, які здаються правдоподібними, але є повністю вигаданими.
Масштаб проблеми: дані дослідження
Команда дослідників з Університету Техасу в Сан-Антоніо, Університету Оклахоми та Технологічного інституту Вірджинії провела найбільше на сьогодні дослідження галюцинацій пакетів у AI-генерованому коді. Результати виявилися тривожними.
Науковці протестували 16 провідних AI-моделей для генерації коду, включаючи комерційні рішення (GPT-4, GPT-3.5, Claude) та моделі з відкритим вихідним кодом (CodeLlama, DeepSeek, WizardCoder, Mistral). Використовуючи два набори промптів, вони згенерували 576 000 зразків коду мовами Python та JavaScript.
Результати дослідження показали, що близько 20% рекомендованих пакетів виявилися неіснуючими — загалом 205 000 унікальних вигаданих назв пакетів. Моделі з відкритим вихідним кодом демонстрували вищий рівень галюцинацій (21,7% у середньому) порівняно з комерційними інструментами (5,2%).
Особливо тривожним виявився факт, що ці галюцинації не є випадковими. При повторному виконанні того самого промпту 10 разів 43% вигаданих пакетів повторювалися кожного разу, а 58% з’являлися більше одного разу. Лише 39% галюцинацій ніколи не повторювалися. Як зазначають аналітики з Socket, ця послідовність робить слопсквоттинг життєздатною стратегією атаки — зловмисникам не потрібно аналізувати величезні обсяги логів або вгадувати можливі назви.
Анатомія галюцинованих назв пакетів
Дослідники виявили цікаві закономірності в назвах пакетів, які галюцинують AI-моделі. Аналіз показав, що 13% були простими помилками на один символ (типовими друкарськими помилками), 9% становили назви пакетів, запозичені з інших мов програмування (наприклад, пакети npm у коді Python), а 38% мали помірну схожість із реальними пакетами, що свідчить про схожу структуру найменування.
Дослідження також виявило декілька поширених сценаріїв виникнення галюцинацій. Перший — заповнення контекстних прогалин, коли AI-моделі створюють правдоподібно звучні назви пакетів на основі намірів користувача без належної перевірки в реальному світі. Другий — міметика поверхневої форми, коли агенти складають легітимно звучні пакети на основі статистичних конвенцій без надійної валідації.
Як працює атака слопсквоттингу
Механізм атаки відносно простий, але потенційно дуже ефективний. Зловмисник запускає популярні AI-моделі для генерації коду, виявляє назви пакетів, які повторюються в згенерованому коді, а потім публікує реальні — але шкідливі — бібліотеки з цими самими назвами в публічних репозиторіях на кшталт PyPI чи npm.
Коли розробник, керований AI-асистентом, автоматично встановлює всі пакети, згадані в згенерованому коді, або коли AI-інструмент сам встановлює пакети без перевірки, шкідлива залежність потрапляє в кодову базу. Як пояснюють дослідники з FOSSA, ця компрометація може потім поширитися через весь код або ланцюг залежностей програмного забезпечення, заражаючи будь-який код, що покладається на шкідливий пакет.
Реальний експеримент з huggingface-cli
Дослідник безпеки Бар Ланядо продемонстрував уразливість цієї загрози у 2024 році практичним експериментом. Він завантажив порожній пакет під назвою huggingface-cli — назву, яку великі мовні моделі часто галюцинували, плутаючи команду, що використовується для CLI HuggingFace Hub, з реальною назвою пакета.
Результати виявилися приголомшливими. Лише за три місяці цей порожній пакет отримав понад 15 000 завантажень. Більше того, він навіть був згаданий у файлі README дослідницького репозиторію, створеного компанією Alibaba. Цей експеримент наочно продемонстрував, наскільки легко розробники, керовані рекомендаціями штучного інтелекту, можуть бути введені в оману і завантажити неіснуючі пакети.
Vibe coding — ідеальне середовище для слопсквоттингу
Термін vibe coding, запропонований дослідником AI Андрієм Карпати в лютому 2025 року, описує техніку програмування, де розробники значною мірою покладаються на штучний інтелект для генерації коду. Цей підхід передбачає, що програміст описує бажаний результат природною мовою, а AI обробляє деталі реалізації.
Хоча vibe coding може значно прискорити прототипування програмного забезпечення, він створює кілька умов, які роблять розробників уразливими до атак слопсквоттингу. Основна філософія vibe coding заохочує розробників неявно довіряти штучному інтелекту, що призводить до мінімальної або відсутньої ручної перевірки назв пакетів і залежностей, недостатнього аудиту пакетів перед встановленням та небезпечної звички копіювати команди встановлення безпосередньо з рекомендацій AI.
Vibe coding наголошує на швидкій розробці, що часто призводить до компромісів щодо стійкості, безпеки та надійності. Розробники пропускають перевірки безпеки, щоб підтримувати темп роботи, тиск швидкої доставки відбиває бажання ретельно перевіряти залежності, а фокус зміщується на прототипування функціональності, а не на валідацію безпеки.
Чому слопсквоттинг особливо небезпечний
Експерти з кібербезпеки виділяють кілька факторів, які роблять слопсквоттинг особливо серйозною загрозою.
По-перше, ця атака експлуатує довірчі відносини між розробниками та AI-інструментами. Коли програміст використовує vibe coding, він фактично передає своє технічне судження AI-системам, які можуть галюцинувати з упевненістю.
По-друге, слопсквоттинг створює приховану вразливість. На відміну від багатьох проблем безпеки, які спричиняють негайні проблеми, атаки слопсквоттингу можуть залишатися неактивними в кодовій базі протягом тривалих періодів, що ускладнює виявлення.
По-третє, ця загроза ефективно масштабується для атакувальників. Націлюючись на послідовно галюцинованих назвах пакетів, зловмисники можуть створити відносно невелику кількість шкідливих пакетів, які будуть ненавмисно використані багатьма розробниками. Як зазначають дослідники з компанії Socket, якщо єдиний галюцинований пакет стає широко рекомендованим AI-інструментами, а атакувальник зареєстрував цю назву, потенціал для широкомасштабної компрометації стає реальним.
По-четверте, слопсквоттинг обходить традиційні засоби контролю безпеки. Більшість інструментів безпеки зосереджені на виявленні вразливостей у наявному коді, а не на запобіганні встановленню шкідливих пакетів, які здаються легітимними.
Поточний стан загрози
Станом на грудень 2025 року дослідники не зафіксували широкомасштабних експлуатацій слопсквоттингу в реальних умовах. Проте це не означає, що загроза є чисто теоретичною. Як повідомляє Infosecurity Magazine, з огляду на те, що минулого року в репозиторіях з відкритим вихідним кодом було виявлено близько 20 000 шкідливих бібліотек, експерти впевнені, що хтось спробує конвеєризувати цей новий тип атаки.
Цей сценарій особливо небезпечний для програмістів-аматорів, а також для корпоративних IT-відділів, які вирішують деякі завдання автоматизації внутрішньо. Саме ці категорії користувачів найімовірніше покладатимуться на AI-рекомендації без належної перевірки.
Заходи захисту від слопсквоттингу
Експерти з кібербезпеки розробили комплекс рекомендацій для захисту від загрози слопсквоттингу. Ці заходи поєднують технічний контроль і культурні практики розробки.
Ручна верифікація пакетів. Ніколи не довіряйте сліпо пакетам, запропонованим штучним інтелектом. Завжди перевіряйте їхнє існування та репутацію в офіційних репозиторіях перед встановленням. Як радять експерти з BleepingComputer, використовуйте сканери залежностей, lockfiles та верифікацію хешів для закріплення пакетів до відомих, перевірених версій.
Налаштування AI-моделей. Дослідження показали, що зниження налаштування temperature (рівня випадковості) у AI-моделях значно зменшує кількість галюцинованих пакетів. Деякі комерційні асистенти для написання коду також мають вбудовані захисні механізми — новіші LLM іноді можуть розпізнати власні галюціновані пропозиції пакетів і попередити про них.
Код-рев’ю та людський нагляд. Попросіть досвідчених розробників переглянути код, згенерований за допомогою AI. Тестуйте AI-генерований код у безпечному, ізольованому середовищі спочатку — не дозволяйте AI безпосередньо встановлювати пакети у вашу систему без вашого підтвердження.
Інтеграція безпеки в конвеєр розробки. Зробіть сканування вихідного коду та статичне тестування безпеки частиною конвеєра розробки. Весь код, включаючи згенерований AI, повинен відповідати чітким критеріям: відсутність вбудованих токенів чи інших секретів, використання правильних версій бібліотек та інших залежностей. Ці завдання добре інтегруються в цикл CI/CD.
Використання SBOM. Software Bill of Materials (SBOM) — це список усіх компонентів (бібліотек, модулів тощо) у вашому програмному забезпеченні разом з їхніми версіями та джерелами. Актуальні SBOM можуть стати важливими інструментами, які допомагають командам швидко виявляти несподівані або несанкціоновані залежності.
Додаткові цикли валідації AI. Впровадьте додаткові цикли валідації AI, де LLM перевіряє власний код на помилки, щоб зменшити кількість галюцинацій. Крім того, модель можна попросити проаналізувати популярність і корисність кожного пакета, згаданого в проєкті.
Використання попередньо створених баз даних та RAG. Використання попередньо створеної бази даних популярних бібліотек для точного налаштування моделі та забезпечення генерації з розширеним пошуком (Retrieval Augmented Generation, RAG) також зменшує кількість помилок.
Дослідники змогли скоротити кількість галюцинованих пакетів до 2,4% для DeepSeek і 9,3% для CodeLlama, поєднуючи всі ці методи. На жаль, обидва показники занадто далекі від нуля, щоб цих заходів було достатньо.
Роль платформ та індустрії
Компанії, що розробляють AI-інструменти для програмування, також працюють над вирішенням проблеми. Як зазначають аналітики Trend Micro, передові асистенти для написання коду, такі як Claude Code CLI, OpenAI Codex CLI та Cursor AI з валідацією на основі MCP, допомагають зменшити — але не повністю усунути — ризик фантомних залежностей, оскільки навіть валідація в реальному часі не може виявити кожен крайній випадок.
Платформи для публікації пакетів також можуть відігравати активну роль. Оскільки аналіз згенерував список уразливих назв і асоційовані з ними платформи пакетів, було б розумно, щоб кожна з цих платформ занесла ці назви в чорний список. Це б заблокувало двері до того, як автори шкідливого програмного забезпечення навіть почнуть діяти.
Спеціалізовані інструменти кібербезпеки також адаптуються до нової загрози. Компанія Socket розробила платформу, яка сканує кожен пакет у дереві залежностей, позначає ризиковану поведінку, як-от скрипти встановлення, обфускований код або приховані корисні навантаження, та попереджає про це до того, як буде завдано шкоди.
Висновки та перспективи
Слопсквоттинг ілюструє, що навіть наші AI-помічники можуть створювати нові вектори атак. Ланцюг постачання програмного забезпечення вже перебував під облогою з боку тих, хто намагається експлуатувати будь-яку слабкість — галюцинації штучного інтелекту представляють новий тип тріщини, яку потрібно усунути, перш ніж вона розшириться.
Хороша новина полягає в тому, що спільнота реагує. Обізнаність про слопсквоттинг — разом з іншими новими загрозами ланцюга постачання програмного забезпечення — швидко зростає, а разом з нею приходить і дія: краще навчання AI-моделей, удосконалені інструменти для перевірки залежностей та міцніші культурні норми щодо верифікації коду.
Зрештою, поєднання технології (як-от сканери вразливостей, SBOM та безпечні AI-інструменти) та культури (навчання, політики та пильні практики) може значно зменшити загрози на кшталт слопсквоттингу в майбутньому. Проте розробники повинні пам’ятати золоте правило: довіряй, але перевіряй — особливо коли довіра надається штучному інтелекту.
