Злам ланцюжка постачання ПЗ: як ШІ-інструменти кодування породжують “слопсквотинг”

Злам ланцюжка постачання ПЗ: як ШІ-інструменти кодування породжують "слопсквотинг" 1

Slopsquatting – це нова загроза в ланцюжку постачання програмного забезпечення, спричинена “галюцинаціями” штучного інтелекту. Оскільки розробники все частіше покладаються на ШІ-асистентів для написання коду, вони несвідомо надають зловмисникам доступ до свого програмного забезпечення з першого дня.

Що таке Slopsquatting?

Slopsquatting – це новий вид атаки на ланцюжок постачання, який використовує “галюцинації” великих мовних моделей (LLM) для впровадження шкідливого коду в процеси розробки. Цей термін поєднує “AI slop” (неякісні результати ШІ) та “typosquatting” (реєстрація доменів-двійників, що відрізняються однією-двома літерами від популярних), зловмисна практика, коли атакуючі реєструють неправильно написані або схожі версії популярних доменів, щоб обманути користувачів, які помилково вводять URL-адреси.

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

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

Як ШІ створює ризик для ланцюжка постачання?

Традиційно ризики безпеки, пов’язані з ШІ, виникають через “галюцинації” — генерування неправдивої інформації, яка може негативно вплинути на користувачів, що сприймають її як достовірну. Однак, ці ж “галюцинації” еволюціонували в безпекові вразливості, які можуть бути використані зловмисниками.

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

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

Оскільки вигадані пакети не є просто варіантами популярних бібліотек з одруківками, не існує масштабних механізмів захисту від такої практики. Наприклад, реєстр захищає від спроби зловмисника опублікувати “crossenv” як варіант популярного пакету “cross-env”. Однак, він не ідентифікує “mpn install cross-env file” або “cross-env-extended” як потенційні загрози.

“Галюцинації” є стійкими та серйозними

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

Одна дослідницька команда проаналізувала 31 267 уразливостей, що належать до 14 675 пакетів у 10 мовах програмування. Вони виявили, що кількість зареєстрованих уразливостей зростає щорічно на 98%, що значно швидше, ніж 25% річне зростання кількості пакетів програмного забезпечення з відкритим вихідним кодом. Команда також спостерігала 85% збільшення середнього терміну існування уразливостей, що свідчить про зниження рівня безпеки.

Реальні небезпеки “галюцинацій” ШІ

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

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

Чому LLM “галюцинують” пакети?

LLM генерують статистично найбільш ймовірну відповідь, а не пріоритезують точність. Як наслідок, “галюцинації” є відносно поширеними. Одне дослідження виявило, що рівень “галюцинацій” варіюється від 50% до 82% залежно від моделі та методу запиту. Навіть GPT-4o, найефективніша модель, демонструє рівень “галюцинацій” не нижче 23%, навіть із застосуванням методів зменшення.

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

Які LLM схильні до Slopsquatting?

Хоча всі LLM схильні до slopsquatting, деякі з них більш вразливі, ніж інші. Ймовірність генерації вигаданих пакетів під час створення коду залежить від моделі. Пропрієтарні моделі (комерційні, закриті) у чотири рази менш схильні генерувати вигадані пакети, ніж моделі з відкритим вихідним кодом.

Одна дослідницька група довела це, провівши 30 тестів на 30 різних системах. З 576 000 зразків коду та 2,23 мільйона згенерованих пакетів, 19,7% були “галюцинаціями”. GPT-4.0 Turbo мав рівень “галюцинацій” 3,59%, тоді як DeepSeek 1B, найефективніша модель з відкритим вихідним кодом, показала 13,63%.

Це дослідження свідчить про те, що організації, які покладаються на інструменти ШІ з відкритим вихідним кодом для генерації коду, приблизно в чотири рази більше піддаються ризику атак slopsquatting. Однак, це не обов’язково означає, що пропрієтарні інструменти завжди залишатимуться безпечнішими. Як тільки зловмисники усвідомлять цю розбіжність, вони можуть спробувати маніпулювати пропрієтарними LLM, щоб скористатися перевагами видимої безпеки.

“Vibe coding” посилює проблему

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

Зростання “vibe coding” (невибіркового використання коду, згенерованого ШІ) та кодування за допомогою ШІ збільшує поверхню атаки. Чим більше розробників інтегрують інструменти ШІ у свої робочі процеси без впровадження належних процесів перевірки, тим більше розширюється поверхня атаки для slopsquatting.

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

Навігація в розробці за допомогою ШІ

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

Зак Амос – Редактор розділу новин у ReHack.

Ласкаво просимо до спільноти VentureBeat!

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

Читайте більше з нашої програми гостьових публікацій – і ознайомтеся з нашими рекомендаціями, якщо ви зацікавлені у створенні власної статті!

Як захиститися (Порада ІТ-Блогу): Завжди ретельно перевіряйте назви рекомендованих пакетів з відкритим вихідним кодом, переконуючись, що вони існують в офіційних репозиторіях (наприклад, npm, PyPI, Maven Central), перш ніж додавати їх як залежності. Розгляньте можливість використання інструментів статичного аналізу коду, які можуть виявляти підозрілі або невідомі залежності.

Дізнатися більше на: venturebeat.com

Залишити відповідь

Ваша e-mail адреса не оприлюднюватиметься. Обов’язкові поля позначені *