Під час розмов на виставковому стенді Black Hat минулого тижня, майже кожне обговорення з керівниками з AppSec, інженерами платформ та CISO стосувалося одного запитання: хто насправді перевіряє код, згенерований ШІ?
Розробники все активніше використовують інструменти для написання коду за допомогою ШІ. Зростання продуктивності є реальним, а відкритий програмний код залишається основою сучасних корпоративних застосунків. Однак, коли ШІ-асистенти за мілісекунди доповнюють пропозиції щодо сторонніх залежностей, команди корпоративної безпеки та розробники відкритого коду стикаються зі спільною операційною проблемою: генерація коду повністю випереджає застарілі методи перегляду.
Коли неперевірена або “галюцинуюча” залежність потрапляє в кодову базу зі швидкістю машини, сканування Software Composition Analysis (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 до проактивного вибору джерел, забезпечуючи, що кожен пакет, рекомендований моделлю ШІ, попередньо перевірений на наявність шкідливих типізацій (typosquats) та slopsquatting.
Саме на цьому рівні введення працює Secure Open Source Library and Curated Catalog від ActiveState. Розроблений для функціонування як корпоративний шлюз введення, ActiveState надає попередньо перевірені, постійно відновлені пакети з відкритим кодом безпосередньо на робочі станції розробників, конвеєри CI/CD та середовища агентів ШІ.
Розміщуючись між публічними реєстрами пакетів та інструментами розробників, курований каталог гарантує, що ризики, пов’язані з “галюцинаціями” пакетів, перехоплюються на межі вибору.
Корпоративні команди, що працюють на основі керованого джерела введення, усувають вектори slopsquatting на етапі прийому, зменшуючи загальний вплив CVE приблизно на 95% без необхідності змушувати розробників вимикати своїх ШІ-асистентів.
Висновок
Вимкнення інструментів написання коду за допомогою ШІ є непрактичним і неконкурентним. Однак, розгляд інтеграції ШІ виключно як метрики продуктивності розробників, без оновлення правил введення ланцюга постачання програмного забезпечення, залишає виробничі збірки вразливими до автоматизованого компрометування.
Забезпечення безпеки сучасного конвеєра розробки вимагає гарантії того, що кожен пакет, вибраний розробником або агентом, за замовчуванням керується, перш ніж він потрапить до збірки.
Якщо ви зацікавлені в тому, як ActiveState може допомогти забезпечити безпеку ваших додатків з відкритим кодом, заплануйте демонстрацію сьогодні.
Про автора:
Джоні Рівера — керівник продукту, чия кар’єра охоплює кібербезпеку, цифрові медичні рішення та інструментарій для розробників. Він є гордим батьком восьмикласника, який захоплюється театром, і одружений 18 років з любов’ю свого життя, яку зустрів у World of Warcraft.
Спонсоровано та написано ActiveState.
Дізнатися більше на: www.bleepingcomputer.com