Код, створений ШІ: загроза для постачання програмного забезпечення
У міру зростання залежності організацій від великих мовних моделей (LLM) для прискорення розробки, нове дослідження попереджає, що код, згенерований штучним інтелектом, може вносити приховані вразливості в програмне забезпечення. Дослідники з Університету Техасу в Сан-Антоніо проаналізували 576 000 зразків коду, згенерованих 16 найпоширенішими LLM, і виявили, що майже 20% зовнішніх пакетів, які вони оголосили, були «галюцинаціями» — посиланнями на неіснуючі бібліотеки. Ця розбіжність між результатами AI та реальністю створює можливості для атак на основі плутанини залежностей, що може загрожувати всьому: від корпоративних додатків до критичної інфраструктури.
Галюцинації пакетів і плутанина залежностей
Кожен сучасний додаток покладається на сторонні бібліотеки для пришвидшення розробки та уникнення повторного винаходу колеса. Але коли LLM вигадує назву пакету — наприклад, fastdata-utils@^2.1.5 — розробники можуть ненавмисно довіряти їй і встановлювати. Зловмисники можуть зареєструвати таку ж назву на публічних реєстрах пакетів, таких як npm або PyPI, опублікувати отруєну версію та скористатися правилами імпліцитного вирішення версій, щоб доставити шкідливі програми, які викрадають дані, встановлюють бекдори або проникають глибше в корпоративні мережі.
- Плутанина залежностей (або “плутанина пакетів”) вперше була продемонстрована у 2021 році, коли дослідники обманули корпоративні мережі Apple, Microsoft і Tesla, зареєструвавши подібні назви внутрішніх пакетів на публічних реєстрах.
- Галюцинації, викликані LLM, підвищують ризик: у дослідженні UTSA було виявлено 440 445 галюцинованих посилань на пакети в зразках Python і JavaScript.
- 43% з цих галюцинацій повторювалися більше ніж 10 разів, що робить їх постійними цілями для зловмисників.
Основні висновки дослідження
- Відкриті LLM, такі як CodeLlama та StarCoder, мали найвищі показники галюцинацій, у середньому близько 22% усіх залежностей.
- Комерційні моделі (ChatGPT, GPT-4, Claude) мали в середньому трохи більше 5%, що пояснюється більшими кількістю параметрів (>10×) та детальнішою налаштуванням безпеки.
- Зразки JavaScript демонстрували галюцинації на рівні 21.3%, у порівнянні з 15.8% для Python, ймовірно, через величезну екосистему npm з понад 2.5 мільйона пакетів проти 350 000 у PyPI.
Розширення поверхні атаки: останні інциденти та тенденції
З моменту публікації статті UTSA на конференції USENIX Security 2025, команди безпеки спостерігали реальні випадки, коли імпорти, запропоновані AI, призводили до встановлення неперевірених пакетів. У липні 2025 року Snyk повідомила, що 24% проектів, що використовують AI-кодові асистенти, ввели принаймні одну відсутню залежність протягом першого тижня використання. У одному відомому випадку внутрішній банківський додаток ненавмисно завантажив пакет npm з бекдором під назвою secure-auth-token, що дозволило зловмисникам перехоплювати OAuth-дані в процесі передачі.
Експерти галузі попереджають, що проблема загострюється. Кеті Муссуріс, генеральний директор Luta Security, зазначає: «Ми вступаємо в еру, коли AI є нашим парним програмістом. Але без сувірної перевірки ці галюцинації стають найслабшою ланкою в ланцюгу. Зловмисники завжди будуть експлуатувати сліпі зони довіри». Тим часом спільна рекомендація CISA та NCSC Великої Британії у вересні 2025 року закликала організації вважати всі залежності, створені AI, ненадійними, поки не будуть перевірені.
Технічні заходи та найкращі практики
- Впроваджуйте стандарти Software Bill of Materials (SBOM), такі як CycloneDX або SPDX, для каталогізації кожної залежності, включаючи транзитні.
- Реалізуйте фреймворк SLSA (Supply-chain Levels for Software Artifacts). Вимагайте принаймні рівня 2 SLSA для підтвердження підписаного походження джерела, і переходьте до рівня 4 для герметичних збірок та підтвердження походження.
- Використовуйте Sigstore для прозорого управління ключами та автоматичної перевірки підписів пакетів під час установки.
- Інтегруйте інструменти статичного аналізу та сканування залежностей (GitHub Dependabot, CodeQL, Snyk) у CI/CD пайплайни для виявлення незареєстрованих або нових залежностей перед злиттям.
- Використовуйте плагіни в IDE, які в реальному часі перевіряють існування пакетів через API реєстрів. Попередній перегляд Visual Studio 2026 від Microsoft тепер містить значок «Надійна залежність», який перевіряє npm, PyPI, Maven Central та внутрішні канали.
Перспективи: забезпечення безпеки розробки з підтримкою LLM
Постачальники LLM намагаються закрити цю прогалину. В майбутньому API «Code Integrity» від OpenAI інтегрує перевірки реєстру безпосередньо в модель, запобігаючи галюцинованим імпортам. Anthropic експериментує з генерацією, доповненою отриманням (RAG), яка прив’язує завершення коду до перевіреної документації. Тим часом дослідницькі команди в MIT та Стенфорді вивчають формальні шари верифікації над виходами LLM, щоб гарантувати, що запропоновані імпорти існують і відповідають семантичним політикам версій.
На даний момент організаціям слід оновити свої політики DevOps: вимагати ручної перевірки залежностей, запропонованих AI, забезпечити фіксацію залежностей та постійно моніторити нові шкідливі реєстрації, які відповідають внутрішнім назва. Як нещодавно передбачив технічний директор Microsoft Кевін Скотт, «95% коду буде підтримуватись AI протягом п’яти років». Важливо вже сьогодні впроваджувати заходи безпеки, щоб завтрашні AI-орієнтовані пайплайни не стали шляхом до зламу.