Бяспека ланцужкоў паставак агентаў штучнага інтэлекту раней была простай, галоўным чынам таму, што паміж назвай пакета і зборкай заўсёды стаяў чалавек. На працягу дваццаці гадоў уся мадэль была такой: хтосьці чытаў назву перад тым, як яна была ўведзена. Не заўсёды ўважліва. Але хтосьці чытаў яе.
Цяпер гэтага няма. Калі сёння спытаць у мадэлі штучнага інтэлекту бібліятэку, то прыкладна кожны пяты рэкамендаваны пакет не існуе. Зламыснікі ведаюць пра гэта, таму спачатку рэгіструюць гэтыя назвы. Агент усталёўвае іх, тэстуе і рухаецца далей, і ніхто нічога не чытае паміж імі. Менавіта ў гэтым зараз дае збой бяспека ланцужка паставак агентаў штучнага інтэлекту: не ў нейкім будучым сцэнарыі, а ў 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Ён рэдагуе Dockerfile, перабудоўвае шматэтапныя зборкі і дапаўняе pipeline канфігурацыю непасрэдна, уваходзячы ў саму сістэму зборкі, а не толькі ў дрэва зыходнага кода.
Менавіта тут і знаходзіцца адказ галіны на рызыкі ў ланцужку паставак, SBOMз і SLSA provenance, павінен быў трымацца. Затым, у маі 2026 года, зламыснік ашукаў распрацоўшчыка, выкарыстаў скрадзены токен для публікацыі «сіраты» commit без бацькоўскага элемента ў гісторыі праекта і выкарыстаў яго для ўзлому кэша зборкі. У выніку восемдзесят чатыры пакеты былі адпраўлены з цалкам дзейсным, належным чынам падпісаным паходжаннем вышэйшага ўзроўню. Усе аўтаматызаваныя праверкі прайшлі. Шкоднаснае праграмнае забеспячэнне было сапраўдным, як і, тэхнічна, дакументы, якія пацвярджалі, як яно было сабранае.
Непрыемны вынік: паходжанне даказвае, што зборка рабіла з тым, што ёй было дадзена, а не тое, што тое, што ёй было дадзена, заслугоўвала даверу. Атруціце ўваходныя дадзеныя яшчэ да таго, як артэфакт з'явіцца, і атэстацыя — гэта сумленны, правераны запіс несумленнай зборкі. Бяспека ланцужка паставак агентаў штучнага інтэлекту не можа быць цалкам перададзена інструментам атэстацыі, створаным для свету, дзе чалавек, а не мадэль, вырашае, што ўваходзіць у зборку.
Адзін практычны спосаб змякчэння не надта прывабны, але эфектыўны: перыяд чакання праз некалькі дзён пасля публікацыі новай версіі пакета перад яе прыняццем. Большасць актыўных інцыдэнтаў у ланцужку паставак пазначаюцца і раскрываюцца ў гэты ранні перыяд, таму пяцідзённая затрымка нейтралізавала б значную долю мінулагодніх. атакі ў стылі чарвякоўцаной абсалютна нічога, акрамя неадкладнагаiacy.
Git, Review і скарачэнне чалавечага кантрольнага пункта
Праверка кода і commit Гісторыя доўгі час служыла апорай даверу для «хтосьці на гэта паглядзеў». Гэтая апора становіцца хісткай, калі агенты commitі ўсё часцей зліваюцца без удзелу чалавека ў цыкле ў момант іх узнікнення.
Агент, які ўсталёўвае пакет, не мае такой жа праблемы з даверам, як распрацоўшчык, які капіюе адказ Stack Overflow, нават калі абодва прапускаюць напісанне арыгінальнага кода. Фрагмент кода Stack Overflow быў напісаны рэальным чалавекам і неафіцыйна рэцэнзаваны шляхам галасавання "за" і "супраць". Рэкамендацыя, згенераваная штучным інтэлектам, — гэта імавернасны вынік без уласцівасцей, і распрацоўшчык, які капіюе яе ўручную, усё роўна зірне на назву пакета, дату апошняга абнаўлення, адкрытыя праблемы. Агент, які ўсталёўвае яго, не спыняецца ні для чаго з гэтага, калі толькі нешта не створана спецыяльна для прыпынення.
Вось у чым сапраўдная праблема з shift-left. Традыцыйны shift-left мяркуе, што гэта самая хуткая рэч у свеце. pipeline — распрацоўшчык, якога можна навучаць, падштурхоўваць і ацэньваць. Калі хутчэй за ўсё развіваецца аўтаномны агент, бяспека з націскам shift-left павінна быць перавязана з кантрольнымі пунктамі, якія агент не можа абысці: пясочніца, кантроль выхаду і перыяды аднаўлення, а не з палітыкай, якую ніхто не выконвае.
Бяспека ланцужка паставак агентаў штучнага інтэлекту: які бяспечны агент 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-left, пабудаваная з улікам праверкі чалавекам, не маштабуецца ў адпаведнасці з хуткасцю агента; shift-left, пабудаваная з улікам пясочніцы, абмежаванняў на выхад і часу аднаўлення ўстаноўкі, усё яшчэ можа выявіць узламаны агент, перш чым яго дзеянні дасягнуць прадукцыйнасці, таму што гэтыя элементы кіравання не залежаць ад таго, ці хто-небудзь што-небудзь чытае.
