Швидкість розробки за допомогою інструментів зі штучним інтелектом (ШІ) стрімко зростає, але разом із цим виникає нова проблема безпеки: як перевіряти код, згенерований ШІ? Відкриті програмні забезпечення (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 на етапі прийому.
Стимулюючий множник для перевірки відкритих програм
Виклики щодо прийому даних всередині підприємства безпосередньо впливають на ширшу екосистему відкритих програм. Ті самі асистенти ШІ, які генерують неперевірені пропозиції залежностей у корпоративних мережах, також створюють автоматизовані пул-запити, що подаються до репозиторіїв, керованих спільнотою.
Цей обсяг автоматизованих внесків створює безпрецедентне навантаження на розробників-волонтерів:
-
Суперечливі політики ШІ: Великі проєкти, включаючи Kubernetes, ядро Linux, LLVM та Godot, опублікували розбіжні політики щодо внесків, зроблених за допомогою ШІ. Деякі повністю забороняють код, згенерований ШІ, тоді як інші дозволяють його лише за умови, що людина-розробник бере на себе повну відповідальність за кожен доданий рядок.
-
Вища щільність дефектів: Огляд 470 пул-запитів у відкритих програмах, проведений CodeRabbit, показав, що внески, створені за допомогою ШІ, містять на 70% більше дефектів, ніж код, написаний людьми, незважаючи на те, що він виглядає чистим на поверхні.
Коли «галюциновані» або вразливі пакети проходять через корпоративний прийом, вони неминуче потрапляють у вихідні пул-запити відкритих програм, змушуючи розробників-волонтерів витрачати години на перевірку залежностей, які жодна людина свідомо не оцінювала.
Швидкість проти перевірки: Прогалина в управлінні
Нещодавня телеметрія зі звіту Kusari «Application Security in Practice» ілюструє, наскільки розгортання інструментів випереджає контроль прийому даних:
|
Показник |
Корпоративне впровадження |
|
Організації, що використовують асистенти кодування ШІ |
85% |
|
Організації, що використовують ШІ для допомоги в перевірці коду на етапі пул-запитів |
38% |
|
Організації з виділеними елементами контролю безпеки додатків ШІ |
9% |
Традиційні робочі процеси безпеки додатків покладаються на сканування коду після його написання або після відкриття пул-запиту. Коли код генерується зі швидкістю машини, пізні сповіщення просто створюють фоновий шум, який інженери ігнорують.
Забезпечення безпеки конвеєра на етапі вибору
Очікування, що рівень «галюцинацій» LLM впаде до нуля, не є стратегією безпеки додатків. Основна проблема полягає у швидкості, а не в точності моделі. Щоб забезпечити безпеку конвеєра розробки, не жертвуючи продуктивністю, команди безпеки та платформ зміщують оборону лівіше від IDE:
-
Обмежте прямі запити до реєстру: Блокуйте робочі станції розробників та агентів ШІ від прямого запиту до неперевірених публічних кінцевих точок під час автодоповнення коду.
-
Ізолюйте залежності, запропоновані ШІ: Направляйте нововведені залежності в ізольовану пісочницю для автоматизованого аналізу доступності та вразливостей, перш ніж дозволяти їм потрапляти до основних гілок.
-
Керуйте шлюзом прийому: Відходьте від реактивного підрахунку CVE до проактивної курації джерел, гарантуючи, що кожен пакет, рекомендований моделлю ШІ, попередньо перевірений на наявність шкідливих типізаційних помилок (typosquats) та slopsquatting.
Цей рівень прийому даних — це саме те, де працює Безпечна бібліотека відкритих програм та Курований каталог від ActiveState. Розроблений як шлюз прийому корпоративного рівня, ActiveState надає попередньо перевірені, постійно виправлені відкриті програмні пакети безпосередньо на робочі станції розробників, конвеєри CI/CD та середовища агентів ШІ.
Розміщуючись між публічними реєстрами пакетів та інструментами розробки, курований каталог гарантує, що ризики «галюцинованих» пакетів будуть перехоплені на межі вибору. Корпоративні команди, що використовують кероване джерело прийому, усувають вектори slopsquatting на етапі прийому, знижуючи загальний ризик CVE приблизно на 95% без необхідності вимагати від розробників вимкнення їхніх асистентів ШІ.
Висновок
Вимкнення інструментів кодування ШІ не є практичним або конкурентоспроможним. Однак, розгляд інтеграції ШІ виключно як метрики продуктивності розробника, без оновлення правил прийому ланцюжка поставок програмного забезпечення, залишає збірки у виробництві вразливими до автоматизованого компрометування. Забезпечення безпеки сучасного конвеєра розробки вимагає гарантії того, що кожен пакет, вибраний розробником або агентом, буде за замовчуванням керуватися ще до того, як він потрапить у збірку.
Якщо ви зацікавлені дізнатися, як ActiveState може допомогти забезпечити безпеку ваших відкритих програм, заплануйте демонстрацію сьогодні.
Про автора:
Джонні Рівера — керівник продукту, чия кар’єра охоплює кібербезпеку, рішення для цифрового медичного обслуговування та інструменти для розробників. Він — гордий батько акторки 8-го класу та одружений 18 років з любов’ю свого життя, яку зустрів у World of Warcraft.
Спонсоровано та написано ActiveState.
Подробиці можна знайти на сайті: www.bleepingcomputer.com