Що таке слопсквотінг?

Що таке недбале присідання? Це напад у якому зловмисники реєструють точні назви пакетів, які галюцинують помічники кодування ШІ, а потім завантажують ці пакети шкідливим програмним забезпеченням і чекають, поки розробник їх встановить. Це не крайній випадок. У дослідженні, представленому на Безпека USENIX 2025, 19.7% пакетів, рекомендованих моделями кодування ШІ на 576 000 зразках коду, не існували, а дослідники зареєстрували понад 205 000 унікальних галюцинаційних імен у протестованих моделях.

Розуміння того, що таке недбале присідання (і як воно виглядає на практиці), важливо, оскільки це не просто примха штучного інтелекту. Недбале присідання — це наступник епохи штучного інтелекту. друкарський сквот, з однією критичною різницею: типосквотинг залежить від помилки людини, тоді як слопсквотинг залежить від помилки моделі, яка повторюється достатньо передбачувано, щоб зловмисник міг використати його у великих масштабах. У цьому посібнику пояснюється, що таке слопсквотинг, чому він поширюється швидше, ніж його може виявити перевірка пакетів, які ризики він створює та як організації можуть виявити та запобігти йому, перш ніж він потрапить у виробництво.

Значення недбальства: визначення #

Формальне значення терміна «недбале ставлення»: практика реєстрації назви пакета, яку галюцинує велика мовна модель, вигаданої назви, яка звучить правдоподібно, але не існує в жодному публічному реєстрі, та завантаження її шкідливим кодом. перш ніж справжній розробник встановить його на основі пропозиції штучного інтелекту.

Цей термін розширює концепцію типосквотінгу (реєстрація назви пакета, яка імітує справжню, через поширену орфографічну помилку) до специфічного режиму невдачі генеративного ШІ. Там, де типосквотінг використовує друкарську помилку людини, слопсквотінг використовує Галюцинації моделі штучного інтелектуn: асистент з кодування рекомендує pip install або npm install для пакета, якого ніколи не існувало, а зловмисник, який помітив те саме вигадане ім'я, що повторюється в запитах, реєструє його першим.

Практичне значення «недбальства» полягає в наступному: атака на ланцюг поставок, яка перетворює помилку моделі на робочий експлойт, без необхідності людської помилки, окрім довіри до пропозиції штучного інтелекту. Це не теоретично. Один галюцинований пакет, встановлений як доброякісний тест у 2023 році, отримав понад 30 000 завантажень за три місяці без жодного просування та підтвердив, що шкідливі варіанти, що використовують саме цей шаблон, сьогодні присутні в публічних реєстрах.

Слопсквотінг проти типосквотінгу: у чому різниця? #

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

Опечатка залежить від людської помилки друку: розробник має намір ввести запити та вводить requeusts замість цього, а зловмисник, який зареєстрував це ім'я з помилкою, чекає. Ризик пов'язаний з одним натисканням клавіші розробника, однією миттю неуважності.

Недбале використання повністю усуває людську помилку та замінює її помилкою моделі, яка повторюється у великих масштабах для кожного розробника, який отримує подібне запит. Подальший аналіз показав, що коли дослідники повторювали ідентичні запити по десять разів кожне, 43% галюцинованих назв пакетів з'являлися під час кожного запуску, а 58% повторювалися більше одного разу. Саме ця повторюваність робить недбале використання придатним для використання: зловмиснику не потрібно вгадувати друкарську помилку. Йому потрібно лише спостерігати, яке галюциноване ім'я повторює модель, та зареєструвати його раніше, ніж це зробить справжній розробник.

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

Чому слопскування розповсюджується? #

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

Зростання кодування за допомогою штучного інтелекту, автономні агенти та робочі процеси «вібраційного кодування», де розробники переглядають дедалі менше коду перед його запуском, змістили поверхню для програмних атак двома конкретними способами:

Точкою входу більше не є лише розробник. Атака типу «сквотингу» залежить від помилки однієї людини. «Слопсквотинг» може виникнути всередині самої моделі та поширитися на сотні різних розробників, які ставлять схожі запитання та отримують ту саму галюцинаційну рекомендацію, множачи охоплення однієї атаки.

Поверхня атаки змістилася вище по ланцюжку. Більше недостатньо переглядати код, який пише людина. Командам також потрібно стежити за залежностями, які пропонує помічник штучного інтелекту, серверами MCP, до яких він підключається, та агентами, які встановлюють пакети автономно без прямого людського контролю. Традиційна AppSec, створена для перевірки репозиторіїв та людського контролю. commits, ніколи не був розроблений для спостереження за цією новою взаємодією між розробником, штучним інтелектом та реєстром пакетів, де саме ховається недбалість.

Ризики недбальства #

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

• Повторювана експлуатація. Оскільки галюциновані імена не є випадковими, одне й те саме фальшиве ім'я передбачувано з'являється в різних сеансах і моделях. Зловмисникам не потрібно вгадувати; їм потрібно лише спостерігати за поведінкою моделі та реєструвати імена, які постійно повторюються, перетворюючи одноразову галюцинацію на масштабовану, повторювану атаку.
• Агентне поширення. Недбале використання ресурсів більше не обмежується копіюванням запропонованої команди встановлення розробником. У січні 2026 року дослідники виявили, що агенти кодування ШІ вже поширили інструкції, що посилаються на галюцинований npm-пакет, по 237 репозиторіях, причому агенти все ще намагалися встановити його щодня, без людини, яка б могла помітити помилку.
• Уникнення схожості імен. Приблизно 38% вигаданих назв дуже схожі на справжні пакети, що знижує ймовірність того, що розробник помітить заміну з першого погляду. Шкідливий пакет, розташований на один символ далі від довіреної залежності, не виглядає підозріло; він схожий на друкарську помилку, яку ви б зробили самі.
• Постійний вплив після виявлення. Пакет-галюцинація, який замінив легітимний плагін ESLint, все ще реєстрував щотижневі завантаження навіть після того, як реєстр помістив його під блокування безпеки, що свідчить про те, що позначка недбало встановленого пакета не зупиняє його встановлення негайно.

Де ховається недбало #

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

Зазвичай присідання відбувається через:

• Помічники та другі пілоти, що використовують штучний інтелект для кодування. Початкова пропозиція — вигадана назва пакета, представлена ​​поруч із легітимним робочим кодом, — і є джерелом вразливості. У навколишньому коді немає нічого поганого, бо зазвичай це так; лише залежність є фальшивою.
• Автономні агенти кодування. Агентські робочі процеси, які встановлюють залежності без перевірки людиною, усувають єдину контрольну точку – розробника, який зупиняється для перевірки імені, що в іншому випадку виявило б несправжній пакет, перш ніж він потрапить до проекту.
• Менеджери пакетів без кроку перевірки. Ні pip install, ні npm install не викликають помилку, якщо цільовий пакет існує та є шкідливим. Інсталяція завершується нормально, оскільки, з точки зору менеджера пакетів, все гаразд.

Як виявити та запобігти недбалому присіданню #

Запобігання недбалості не вимагає екзотичних інструментів. Воно вимагає систематичного застосування вже існуючих практик гігієни залежностей, а не їх послаблення в той момент, коли ШІ «пропонує» код.

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

Ніколи не вважайте, що код, згенерований штучним інтелектом, безпечний за замовчуваннямКод, який «працює», не означає, що його залежності є легітимними. Перевірка залежностей має бути частиною перевірки коду, а не винятком з неї.

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

Застосуйте AI-SPM як рівень управління. Управління безпекою на основі штучного інтелекту (ШІ) – це практика, розроблена для виявлення саме таких ризиків, спричинених ШІ, у великих масштабах, шляхом постійного виявлення залежностей, запропонованих ШІ, та їх оцінювання ще до того, як людині доведеться згадати про ручну перевірку.

Захист від недбалих присідань за допомогою Xygeni #

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

Ксігені Підхід розглядає це як проблему безперервного виявлення: інвентаризація на основі штучного інтелекту та Специфікація ШІ поверхню кожного, впровадженого штучним інтелектом залежність по всьому SDLC, надаючи командам живий запис того, що помічник зі штучним інтелектом фактично запропонував та встановив. Xygeni Shield, Живлення від MEW (раннє попередження про шкідливе програмне забезпечення), виявляє та блокує шкідливі пакети, включаючи недбалі, ще до появи сигнатури, тим самим закриваючи прогалину, яку залишають відкритою сканери на основі сигнатур.

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

FAQ #