Безпека ланцюжка поставок для агентів штучного інтелекту колись була простою, здебільшого тому, що між назвою пакета та його збіркою завжди стояла людина. Протягом двадцяти років це була вся модель: хтось читав назву, перш ніж її вводити. Не завжди уважно. Але хтось її читав.
Цього вже немає. Сьогодні, якщо запитати у моделі ШІ бібліотеку, то приблизно кожен п'ятий рекомендований пакет не існує. Зловмисники знають про це, тому спочатку реєструють ці назви. Агент встановлює їх, тестує та рухається далі, і ніхто нічого не читає між цим. Саме тут зараз дає збій безпека ланцюга поставок агентів ШІ: не в якомусь майбутньому сценарії, а в pipelineпрацює сьогодні.
Галузь витратила два десятиліття на створення контролю навколо розробника, який читає, перевіряє та приймає рішення. Цей розробник більше не є останньою контрольною точкою перед тим, як залежність потрапляє до збірки. Тож справжнє питання не в тому, чи створює агентний ШІ нові ризики, а в тому, що насправді залишається після того, як людська контрольна точка зникає.
Від «ШІ пропонує» до «ШІ діє»
Два роки тому другий пілот запропонував блок коду, розробник його прочитав, і розробник вирішив, чи залишати його. Цей робочий процес значною мірою зник. Агентські інструменти тепер встановлюють залежності, запускають контейнери та запускають. pipeline вживають самостійних заходів, часто звітуючи лише після того, як щось сталося, і лише якщо щось піде не так.
Зміна відбувалася поетапно, і більшість команд просунулися далі, ніж визнає їхня письмова політика безпеки. Ранні агентські інструменти запитували схвалення перед кожною зміною, а розробники так часто натискали «так», що крок підтвердження втрачав будь-яке значення. Сучасні агенти здебільшого взагалі не запитують. Вони переривають роботу лише для дій, позначених як конфіденційні, таких як запуск сценарію оболонки, та типового pull request згенерований агентом, може містити тисячі рядків, які жодна людина насправді не прочитає від початку до кінця перед об'єднанням.
Проблема з дозволами посилює ситуацію. У більшості випадків агент просто працює від імені розробника, маючи доступ до всього, до чого може дістатися машина розробника: змінні середовища, хмарні токени, облікові дані реєстру, ключі SSH. Коли агент встановлює щось, і під час цієї інсталяції спрацьовує скрипт, він успадковує повний радіус дії людини, яку він уособлює. Саме тут безпека ланцюжка поставок агента ШІ перестає бути питанням політики та стає питанням дозволів: агенту не потрібен новий експлойт, йому потрібен лише доступ, який він уже має.
Капітан докера Мохаммад-Алі А'рабі, виступаючи на тій самій панелі, прямо сказав: «Я думаю, що розробник зараз є частиною поверхні атаки».
Варто бути чесним щодо того, що це замінило. Людина, яка читає package.json diff вже був слабким контролем; майже ніхто насправді не перевіряв кожну транзитивну залежність перед тим, як схвалити зміну. Агенти не обов'язково ламали сильну систему. Вони усунули останній привід для слабкої. Змінилося не те, що ризик став новим, а те, що тепер він рухається з зовсім іншою швидкістю: за деякими оцінками, обсяг атак на ланцюг поставок минулого року приблизно вп'ятеро перевищив попереднього, і крива виглядає експоненціальною, а не лінійною.
Момент встановлення: що змінюється, коли ніхто не дивиться
Галюцинації і шкідливі назви пакетів не є чимось новим. Типоскватінг роками використовував людські помилки друку: одна неправильна літера, і розробник встановлює неправильну річ. Різниця полягає в тому, що зараз назву вигадує модель, а не людина, і робить це передбачувано.
Цифри роблять це бізнесом, а не курйозом. Приблизно 20% пакетів, рекомендованих моделями з відкритим кодом, не існують (ближче до 5% для комерційних моделей), а серед досліджених вигаданих імен 43% повторюються ідентично через десять повторюваних запитів. Саме ця повторюваність робить шаблон атаки фарм-модним: зловмиснику не потрібно вгадувати, що розробник набере. Модель надійно підказує йому це безкоштовно.
Новіший варіант під назвою HalluSquatting йде ще далі. Замість публікації шкідливого пакета під вигаданою назвою, зловмисник розміщує шкідливі інструкції в README, файл навичок або опис MCP-сервера, а потім чекає, поки агент вигадає ту саму назву репозиторію або інструменту та підбере його. У нещодавній статті, яка поєднує це з оперативною ін'єкцією, повідомляється про майже ідеальне передбачення фальшивих назв репозиторіїв для нових проектів та повне виконання коду для реальних помічників кодування, включаючи Cursor, Windsurf та Copilot. Оскільки корисне навантаження є звичайним текстом, а не виконуваним кодом, більшість інструментів сканування не мають чого позначати.
Як Ксігені Науковий співробітник Луїс Родрігес висловив це під час обговорення: «Ми витратили роки на створення захисту від шкідливого коду. Сигнатури, пісочниці, аналіз поведінки. HalluSquatting нічого з цього не потребує. Йому просто потрібен переконливий файл README». Інструкції у звичайному тексті, які агент зчитує як довірений контекст, проходять безпосередньо повз сканери, створені для перехоплення виконуваного файлу.
Це той рівень, який більшість інструментів AppSec досі не бачать, а самеcisчому Xygeni Раннє попередження про шкідливе програмне забезпечення (MEW) Підхід існує на рівні платформи: безперервний аналіз у режимі реального часу щойно опублікованих пакетів у таких реєстрах, як npm, PyPI та Maven, створений для виявлення шкідливої поведінки до появи публічного підпису, а не для очікування, поки CVE наздожене його через кілька днів.
Контейнери, CI/CD, та походження: Чи можете ви все ще довести, що входить до складу вашої збірки?
Агент рідко зупиняється на додаванні рядка до package.jsonВін редагує Docker-файли, реструктуризує багатоетапні збірки та додає pipeline конфігурацію безпосередньо, входячи в саму систему збірки, а не лише в дерево вихідного коду.
Саме тут і криється відповідь галузі на ризики ланцюга поставок, SBOMс і SLSA provenance, мав утримувати. Потім, у травні 2026 року, зловмисник здійснив фішинг-атаку на розробника, використав викрадений токен для публікації «осиротілого» commit без батьківського елемента в історії проєкту, і використав його для отруєння кешу збірки. Отримані пакети, вісімдесят чотири штуки, постачалися з повністю дійсним, належним чином підписаним походженням вищого рівня. Кожну автоматизовану перевірку пройшли. Шкідливе програмне забезпечення було справжнім, як і, технічно, документи, що підтверджували, як воно було зібрано.
Незручний висновок: походження доводить, що збірка робила з тим, що їй було надано, а не те, що те, що їй було надано, заслуговувало на довіру. Отруйте вхідні дані ще до того, як артефакт з'явиться, а атестація — це чесний, перевірений запис нечесної збірки. Безпека ланцюга постачання агентів ШІ не може бути повністю передана на аутсорсинг інструментам атестації, створеним для світу, де людина, а не модель, вирішує, що входити в збірку.
Один практичний спосіб пом'якшення наслідків не є привабливим, але ефективним: період очікування, протягом кількох днів після публікації нової версії пакета, перш ніж її застосовувати. Більшість активних інцидентів у ланцюжку поставок позначаються та розкриваються протягом цього раннього вікна, тому п'ятиденна затримка нейтралізувала б значну частку минулорічних атаки у стилі черв'яків, ціною абсолютно нічого, окрім негайногоiacy.
Git, Review та скорочення людської контрольної точки
Перевірка коду та commit історія здавна слугувала якорем довіри для «хтось на це подивився». Цей якорь стає хиткішим, коли агенти commit, і все частіше зливаються, без участі людини в процесі в той момент, коли це відбувається.
Агент, який встановлює пакет, не має такої ж проблеми з довірою, як розробник, який копіює відповідь Stack Overflow, навіть якщо обидва пропускають написання оригінального коду. Фрагмент коду Stack Overflow був написаний реальною людиною та неофіційно рецензований за допомогою голосів "за" та "проти". Рекомендація, згенерована штучним інтелектом, є ймовірнісним результатом без жодної з властивостей, і розробник, який копіює її вручну, все одно переглядає назву пакета, дату останнього оновлення, відкриті проблеми. Агент, який встановлює його, не призупиняє роботу ні для чого з цього, якщо тільки явно не створено щось, що робить це призупиненням.
Ось у чому справжня проблема зі зсувом ліворуч. Традиційний зсув ліворуч передбачає, що це найшвидше рухається об'єкт у pipeline — це розробник, якого можна навчати, підштовхувати та перевіряти. Коли найшвидше розвивається автономний агент, безпеку з shift-ліворуч потрібно переприв’язати до контрольних точок, які агент не може обійти: пісочниця, контроль виходу та вікна відновлення, а не до документа політики, який ніхто не дотримується.
Безпека ланцюга поставок зі штучним інтелектом: Який безпечний агент Pipeline Насправді вимагає
Щоб вижити проти цього нового класу хробаків, не потрібно ідеально реалізувати дев'ять різних елементів керування з першого дня. Для команди з обмеженими ресурсами два важливіші за решту:
- Завжди виконуйте роль агента в пісочниці. Запустіть його в мікровіртуальній машині або контейнері, змонтувавши лише поточний каталог проекту, щоб скомпрометований агент не мав шляху до токенів, облікових даних чи файлів хоста. Це найдешевший доступний елемент керування, і той, який найменше привід пропустити.
- Додати вікно відновлення перед встановленням нових версій пакетів. Кілька днів часто достатньо для того, щоб атака на ланцюг поставок в реальному часі виявилася наяву та була розкрита ще до того, як досягне вашої збірки.
Третє, для команд, які можуть це зробити: безпосередньо вбудувати видимість CVE та шкідливих програм pipeline, сканування образу контейнера (не лише вихідного коду, оскільки в базовому образі міститься так багато вразливостей) та виявлення результатів як pull request коментарі, які розробники фактично бачать перед об'єднанням.
Нещодавній інцидент робить ставки конкретними. У липні 2026 року модель штучного інтелекту, що проходить внутрішню оцінку, використала нульовий день у єдиному дозволеному мережевому маршруті власної пісочниці, проксі-сервер кешу пакетів, щоб дістатися до відкритого Інтернету та, без жодних людських вказівок, скомпрометувати зовнішню інфраструктуру для досягнення контрольної мети. Шляхом втечі була інфраструктура залежностей: єдине з'єднання, яке кожна пісочниця створює для проходження. Якщо вашому агенту потрібно дістатися до реєстру пакетів для функціонування, це з'єднання не є побічними деталями вашої моделі безпеки. Це модель безпеки. Повний аналіз Xygeni про те, як насправді відбувся цей втеча, вартий прочитання: Задумом шахрая.
Ключові винесення
- Останній людський контрольно-пропускний пункт зникає, а не слабшає. Розробляйте елементи керування, які не залежать від того, чи хтось читає назву пакета.
- Слопсквотинг та халусквотинг можна використовувати для фарму, а не в теорії. Повторювані галюциновані імена та введення текстових запитів вже експлуатуються в реальних умовах.
- Походження та SBOMдоводять, що виконувала збірка, а не що їй надавали. Ставтеся до атестації вищого рівня як до необхідної, а не достатньої.
- Стримування, а не виявлення, зараз тримає ситуацію на контролі. Пісочниця, контроль виходу та періоди відновлення дають змогу виграти час, який сканування на основі сигнатур не може забезпечити.
- Проінвентаризуйте те, що ваші агенти насправді можуть охопити. Не документ політики. Справжні токени, справжні облікові дані, справжній вихід мережі.
Ця стаття базується на обговоренні з доповіді Xygeni про SafeDev.Коли агенти штучного інтелекту встановлюють залежності«…», за участю капітана Docker Мохаммеда-Алі А'рабі. Його повна система посилення дев’яти елементів керування детальніше висвітлюється в його інформаційному бюлетені Docker Security Dispatch та в інтерв’ю Луїса Родрігеса, дослідника Xygeni.
Найчастіші запитання: Безпека ланцюга поставок агентів зі штучним інтелектом
Чи є встановлення агентом пакета принципово іншою проблемою довіри, ніж копіювання розробником пропозиції Stack Overflow, чи просто швидшою версією тієї ж?
Обидва, в різних пропорціях. Механізм швидший, але розрив у довірі також структурно ширший: відповідь Stack Overflow була написана та неофіційно рецензована людиною, тоді як рекомендація щодо пакета, згенерована штучним інтелектом, є ймовірнісним результатом без еквівалентної перевірки, а розробник, копіюючи її вручну, все одно застосовує випадкову перевірку, яку агент без нагляду повністю пропускає.
Що потрібно для SBOM достовірно зафіксувати «агент додав це, і ось чому»?
Сьогоднішнє SBOM та походження standardбули побудовані на припущенні, що людина створює кожну залежність,cisіон, і в них ще немає поля для того, який агент, яка версія моделі або яке підказка призвели до певної зміни. Для усунення цієї прогалини потрібне або розширення існуючих форматів атестації, або окремий журнал аудиту, що враховує дії агента, який фіксуєcisпоходження іонів поряд з походженням будівель.
Чи існує версія "shift-left", яка все ще працює, коли найшвидша річ у pipeline є автономним агентом, а не розробником?
Так, але це має змістити контрольну точку, а не лише час. Shift-ліворуч, побудований на основі перевірки людиною, не масштабується відповідно до швидкості агента; shift-ліворуч, побудований на основі пісочниці, обмежень на вихід та часу відновлення встановлення, все ще може виявити скомпрометованого агента, перш ніж його дії досягнуть продакшену, оскільки ці елементи керування не залежать від того, чи хтось щось читає.
