Штучний інтелект (ШІ) стрімко завойовує сферу розробки програмного забезпечення, автоматизуючи завдання та підвищуючи продуктивність. Однак це швидке впровадження створює нові виклики для кібербезпеки, особливо щодо перевірки коду, згенерованого ШІ, та управління програмними залежностями. Компанії зіштовхуються з проблемою, коли швидкість генерації коду ШІ значно випереджає традиційні процеси перевірки безпеки.
Під час обговорень на виставці Black Hat минулого тижня команда ActiveState майже в кожній розмові з керівниками з безпеки додатків (AppSec), інженерами платформ та директорами з інформаційної безпеки (CISO) чула одне запитання: хто насправді перевіряє код, згенерований ШІ?
Впровадження ШІ-інструментів для розробників не сповільнюється. Підвищення продуктивності є реальним, а відкритий вихідний код (open source) залишається основою сучасних корпоративних додатків. Але поки ШІ-асистенти автодоповнюють пропозиції щодо сторонніх залежностей за мілісекунди, команди безпеки підприємств та розробники open source стикаються зі спільною операційною проблемою: генерація коду повністю випередила застарілий процес перевірки. Коли неперевірена або “галюцинована” залежність потрапляє в кодову базу зі швидкістю машини, сканування програмної композиції (SCA) після коміту ледве встигають.
Забезпечення безпеки цього конвеєра не означає сповільнення розробників або обмеження використання відкритого коду. Це вимагає управління тим, що потрапляє в середовище на етапі вибору, ще до того, як імпорт ініціює збірку.
Механізми “Slopsquatting” та машинне споживання
Великі мовні моделі (LLM) рекомендують програмні бібліотеки на основі статистичної ймовірності та історичних шаблонів коду, а не перевірки реєстру пакетів у реальному часі.
Коли модель пропонує назву пакета, яка не існує в PyPI або npm, це створює вразливість ланцюга постачання, відому як slopsquatting (або експлуатація “галюцинацій” пакетів ШІ).
Масштаб цієї вразливості був висвітлений у дослідженні USENIX Security, яке проаналізувало шістнадцять популярних моделей генерації коду на понад 500 000 зразках коду:
-
Вимірюваний відсоток запропонованих ШІ назв пакетів не існує в публічних реєстрах.
-
Із запропонованих залежностей, які дійсно відповідають реальним пакетам, майже половина містить відомі CVE або застарілі версії.
Зловмисники регулярно відстежують вихідні патерни публічних LLM та репозиторіїв коду розробників, щоб виявити ці “галюциновані” назви пакетів. Після їх виявлення зловмисник реєструє підроблену назву на PyPI або npm, завантажує шкідливий код і чекає, доки автоматизовані середовища розробки або CI/CD збірки завантажать його.
Цей вектор активно спостерігається в реальних розгортаннях. На початку 2026 року дослідники безпеки відстежили один “галюцинований” npm-пакет (react-codeshift), що походив з 47 ШІ-згенерованих навичок агента в одному коміті.
Ця “галюцинація” поширилася органічно через форки до понад 230 репозиторіїв, перш ніж інженер помітив, що його ніколи явно не обирав жоден розробник.
Проблема полягала не в зловмисному намірі розробника, а в повній відсутності контролю над імпортом.
Зупиніть “галюцинації” пакетів ШІ до того, як вони потраплять у вашу збірку
ШІ-асистенти генерують програмне забезпечення зі швидкістю машини, але неперевірені залежності наражають ваш конвеєр на ризик slopsquatting та атак на ланцюг постачання.
ActiveState, що працює на базі безпечного репозиторію чистих компонентів, створених з вихідного коду, дозволяє організаціям доводити походження програмного забезпечення та атестацію на рівні збірки, одночасно усуваючи вектори slopsquatting на етапі приймання.
Поговоріть з нашою командою
“Множник тертя” при перевірці відкритого коду
Проблема приймання в корпоративному середовищі безпосередньо впливає на ширшу екосистему відкритого коду. Ті самі ШІ-асистенти, які генерують пропозиції щодо неперевірених залежностей у корпоративних мережах, також створюють автоматизовані запити на злиття (pull requests), які надсилаються до репозиторіїв, що підтримуються спільнотою.
Цей обсяг автоматизованих внесків створює безпрецедентне навантаження на розробників-волонтерів:
-
Суперечливі політики ШІ: Основні проєкти, включаючи Kubernetes, ядро Linux, LLVM та Godot, опублікували різні політики щодо внесків, зроблених за допомогою ШІ. Хоча деякі повністю забороняють код, згенерований ШІ, інші дозволяють його лише за умови, що людина-розробник бере на себе повну відповідальність за кожен доданий рядок.
-
Вища щільність дефектів: Огляд 470 запитів на злиття у відкритому коді від CodeRabbit показав, що внески, зроблені співавторами ШІ, містили на 70% більше дефектів, ніж код, написаний людьми, незважаючи на те, що вони виглядали чистими на поверхні.
Коли “галюциновані” або вразливі пакети проходять через корпоративне приймання, вони неминуче потрапляють у вихідні запити на злиття відкритого коду, змушуючи розробників-волонтерів витрачати години на валідацію залежностей, які жодна людина свідомо не перевіряла.
Швидкість проти верифікації: Прогалина в управлінні
Нещодавня телеметрія зі звіту Kusari “Application Security in Practice” ілюструє, наскільки розгортання інструментів випереджає контроль над імпортом:
|
Метрика |
Корпоративне впровадження |
|
Організації, що використовують ШІ-асистенти для кодування |
85% |
|
Організації, що використовують ШІ для допомоги у перевірці коду на етапі PR |
38% |
|
Організації з виділеними елементами контролю AppSec на базі ШІ |
9% |
Традиційні робочі процеси AppSec покладаються на сканування коду після його написання або після відкриття запиту на злиття. Коли код генерується зі швидкістю машини, пізні сповіщення просто створюють шум у черзі, який інженери ігнорують.
Захист конвеєра на етапі вибору
Очікування, що частота “галюцинацій” LLM впаде до нуля, не є стратегією AppSec. Основна проблема полягає у швидкості, а не в точності моделі. Щоб захистити конвеєр розробки, не жертвуючи вихідною продуктивністю, команди безпеки та платформ переносять оборону лівіше IDE:
-
Обмежте пряме отримання даних з реєстру: Блокуйте робочі станції розробників та ШІ-агентів від прямого запиту до неперевірених публічних кінцевих точок під час автодоповнення коду.
-
Ізолюйте залежності, запропоновані ШІ: Направляйте нововведені залежності в ізольований пісочник для автоматизованого аналізу досяжності та вразливостей, перш ніж дозволити їм потрапити до основних гілок.
-
Керуйте шлюзом приймання: Відійдіть від реактивного підрахунку CVE до проактивного курування джерел, гарантуючи, що кожен пакет, рекомендований моделлю ШІ, попередньо перевірений на наявність шкідливих типотних атак та цілей slopsquatting.
Цей рівень приймання — саме те, де працює Безпечна бібліотека відкритого коду та курований каталог від ActiveState. Розроблений для функціонування як корпоративний шлюз приймання, ActiveState надає попередньо перевірені, постійно виправлені пакети відкритого коду безпосередньо на робочі станції розробників, конвеєри CI/CD та середовища ШІ-агентів.
Розміщуючись між публічними реєстрами пакетів та інструментами розробника, курований каталог гарантує, що ризики “галюцинованих” пакетів перехоплюються на межі вибору.
Корпоративні команди, що працюють на основі керованого джерела приймання, усувають вектори slopsquatting на етапі входу, зменшуючи загальний вплив CVE приблизно на 95% без необхідності змушувати розробників вимикати своїх ШІ-асистентів.
Висновок
Відключення ШІ-інструментів для кодування є непрактичним і неконкурентним. Однак ставлення до інтеграції ШІ виключно як до показника продуктивності розробника, без оновлення правил приймання ланцюга постачання програмного забезпечення, залишає виробничі збірки вразливими до автоматизованого компрометування.
Забезпечення безпеки сучасного конвеєра розробки вимагає гарантії того, що кожен пакет, обраний розробником або агентом, за замовчуванням керується, перш ніж він потрапить у збірку.
Якщо ви зацікавлені дізнатися, як ActiveState може допомогти захистити ваші програми з відкритим кодом, заплануйте демонстрацію сьогодні.
Про автора:
Джоні Рівера — керівник продукту, кар’єра якого охоплює кібербезпеку, рішення для цифрової охорони здоров’я та інструментарій для розробників. Він є гордим батьком театрального гуртка для учня 8-го класу і одружений 18 років з коханням свого життя, з яким познайомився в грі World of Warcraft.
Спонсоровано та написано ActiveState.
Подробиці можна знайти на сайті: www.bleepingcomputer.com