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

Коли дослідник безпеки Bar Lanyado з Lasso Security попросив інструмент для написання коду на базі ШІ надати Python-клієнт, модель запропонувала встановити huggingface-cli. Цей пакет — фантом; легітимна бібліотека має назву huggingface_hub. Щоб довести небезпеку, Lanyado зареєстрував фальшиву назву в Python Package Index (PyPI) як порожній плейсхолдер. Протягом трьох місяців цей плейсхолдер зібрав понад 30 000 завантажень, з'явився у публічній документації та навіть у зразках коду, зібраних із репозиторіїв Alibaba.

Як фантомний пакет стає реальною загрозою

  1. Промпт → галюцинація – Розробник звертається до ШІ за допомогою. Модель, навчена на зашумлених даних з інтернету, вигадує назву пакета, що звучить правдоподібно.
  2. Копіювання-вставлення → документація – Пропозиція потрапляє в README, відповідь на Stack Overflow або внутрішню вікі. Після запису назва поширюється серед спільноти.
  3. Інтеграція коду – Розробник, довіряючи ШІ, додає назву у файл requirements і випускає код у продакшн.

Чому існуючі засоби захисту пропускають цю проблему

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

Що доводить цей експеримент

  • Вигадані ШІ назви потрапляють у продакшн – Понад 30 000 завантажень свідчать про те, що розробники дійсно завантажують ці фантомні пакети.
  • Галюцинації стають документацією – Як тільки фальшива назва з'являється у публічному посібнику, вона може зберігатися нескінченно довго, поширюючи помилку.
  • Реєстрація є тривіальною – Публікація пакета на PyPI нічого не коштує і займає лічені хвилини, що знижує поріг для зловживань у ланцюгах постачання.

Заходи захисту, які дійсно працюють

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

На що звернути увагу далі

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