Праблема ў адным сказе
Наступны раз Памочнік штучнага інтэлекту рэкамендуе пакет для ўсталёўкі, ці збіраецеся вы насамрэч праверыць, ці існуе гэты пакет? Большасць распрацоўшчыкаў гэтага не рабілі. Менавіта гэты разрыў паміж прапановай і праверкай і з'яўляецца месцам, дзе пачынаюцца атакі тыпу «слопсквотынг», і менавіта таму разуменне як эвалюцыі «слопсквотынгу», так і практычнае прадухіленне «слопсквотынгу» стала сапраўдным прыярытэтам для каманд AppSec і DevSecOps.
Што такое атака з нядбайным прысяданнем?
Атака з нядбайным прысяданнем — гэта варыянт typosquatting (практыка рэгістрацыі даменнага імя або імя пакета, якое імітуе законнае імя праз распаўсюджаныя памылкі ў напісанні, напрыклад запыты замест запытамі, спадзеючыся, што ўласная памылка карыстальніка прывядзе яго прама да яго), але з важным адрозненнем у тым, адкуль бярэцца памылка. Тыпасквотынг выкарыстоўвае памылкі друку, выкліканыя чалавекам. Атака нядбайнасці выкарыстоўвае памылкі, якія робяць мадэлі вялікіх моў: LLM «галюцынуе» назву пакета, якая гучыць цалкам легітымна, але не існуе ні ў адным публічным рэестры, і зламыснік дабіраецца туды першым, рэгіструючы менавіта гэтую назву, перш чым гэта зробіць хто-небудзь з добрымі намерамі.
Механізм тыповай атакі з нядбайным прысяданнем просты, і менавіта гэтая прастата робіць яе эфектыўнай:
- Распрацоўшчык просіць памочніка па штучным інтэлекце дапамагчы яму вырашыць праблему з кадаваннем.
- Мадэль генеруе рашэнне, якое імпартуе або рэкамендуе ўсталяваць пакет, якога ніколі не існавала.
- Зламыснік, які заўважыў, што некалькі мадэляў пастаянна паўтараюць адно і тое ж галюцынаванае імя, рэгіструе гэты пакет са шкоднасным кодам унутры ў npm, PyPI або іншым публічным рэестры. У гэты момант галюцынацыя ператвараецца ў сапраўдную атаку тыпу «слопсквотынг».
- Наступны распрацоўшчык, які атрымлівае такую ж прапанову і не правярае яе, усталёўвае ўжо рэальны пакет, які з'яўляецца бэкдорам у яго асяроддзе.
Тэрмін «slopsquatting» быў прыдуманы Сэтам Ларсанам, распрацоўшчыкам па бяспецы ў Python Software Foundation, і папулярызаваны Эндру Нэсбітам, каб апісаць менавіта гэтую заканамернасць: «галюцынацыя пакета», якая ператварылася ў вектар атакі.
Эвалюцыя нядбайнасці: як даследчая цікаўнасць ператварылася ў рэальную пагрозу
Характэрнай у эвалюцыі слопскотынгу з'яўляецца не толькі канцэпцыя, але і тое, як хутка ён перайшоў ад даследчага назірання да дакументаванага, вымернага класа нападаў.
2023: Першы папераджальны знак. Даследчык па бяспецы Бар Ланьядо заўважыў, што некалькі магістраў права неаднаразова рэкамендавалі пакет пад назвай абдымаючы твар-клі, якога не існуе (сапраўдны пакет усталёўваецца з дапамогай pip install -U “huggingface_hub[cli]”). Каб прадэманстраваць рызыку, ён загрузіў пустую версію гэтага пакета ў публічны рэестр. На працягу трох месяцаў ён атрымаў больш за 30 000 загрузак без якога-небудзь прасоўвання. Выдуманая назва нават з'явілася ў README рэпазітара, звязанага з даследаваннямі Alibaba, што на ранняй стадыі паказала, як гэтыя «падробныя» імёны могуць прасачыцца ў рэальную дакументацыю і стварыць глебу для наступных неахайных нападаў.
2024: Рызыка пераходзіць з блога даследчыка ў асноўныя тэхналагічныя навіны. У сакавіку 2024, рэгістрацыя паведамлялася пра тое, як мадэлі штучнага інтэлекту ўпэўнена выдумлялі назвы праграмных пакетаў, якія распрацоўшчыкі потым спампоўвалі, некаторыя з якіх патэнцыйна былі заражаныя шкоднасным праграмным забеспячэннем. Гэта асвятленне мела не столькі тэхнічнае значэнне, колькі сігнал: выпадак huggingface-cli быў ужо не аднаразовай кур'ёзам; гэта быў першы прыкмета заканамернасці, дастаткова сур'ёзнай, каб асноўная тэхналагічная прэса адзначыла яе, перад маштабным акадэмічным даследаваннем, якое пацвердзіла маштаб праз год.
2025: Першае строгае маштабнае вымярэнне праблемы. Папера «У нас ёсць для вас пакет! Комплексны аналіз пакетных галюцынацый з дапамогай генерацыі кода LLM» (Спраклен і інш., прадстаўлены на Бяспека USENIX У рамках сімпозіума было пратэставана 16 мадэляў генерацыі кода, як камерцыйных (GPT-4, GPT-3.5), так і з адкрытым зыходным кодам (CodeLlama, DeepSeek, WizardCoder, Mistral), на 576 000 узорах кода Python і JavaScript. Вынікі даследавання адзначаюць выразны момант у эвалюцыі нядбайнасці, пераводзячы яе з анекдота ў дадзеныя:
- 19.7% з пакетаў, рэкамендаваных мадэлямі, не існавала.
- Мадэлі з адкрытым зыходным кодам галюцынавалі значна часцей (21.7% у сярэднім), чым камерцыйныя мадэлі (5.2%).
- Найгоршыя парушальнікі, CodeLlama 7B і CodeLlama 34B, галюцынавалі больш чым у траціне сваіх вынікаў.
- Ва ўсіх пратэставаных мадэлях даследчыкі ўвайшлі ў сістэму 205 000 унікальных галюцынацыйных назваў пакетаў, дастаткова вялікі басейн, каб падсілкоўваць працяглыя атакі нядбайнага падыходу ў некалькіх экасістэмах.
- Адна дэталь, асабліва важная для прафілактыкі: прыблізна 38% галюцынаваныя назвы вельмі нагадвалі сапраўдныя пасылкі, што зніжае верагоднасць таго, што хтосьці заўважыць іх з першага погляду.
Важная дэталь даследавання, і, верагодна, прычына таго, што эвалюцыя слопсквотынгу паскорылася, а не спынілася, заключаецца ў тым, што галюцынацыйныя назвы не выпадковыя і не мяняюцца пры кожнай спробе. Адны і тыя ж мадэлі, як правіла, паўтараюць адны і тыя ж выдуманыя назвы, калі ім даюць падобныя падказкі, а гэта значыць, што зламысніку не трэба здагадвацца. Ім проста трэба назіраць за паводзінамі мадэлі, вызначаць назвы, якія паўтараюцца, і рэгістраваць іх, перш чым гэта зробіць сапраўдны распрацоўшчык. Наступны аналіз гэтай паўтаральнасці паказаў, што калі даследчыкі паўтаралі аднолькавыя падказкі па дзесяць разоў, 43% галюцынацыйных назваў пакетаў з'яўляліся пры кожным запуску, а 58% паўтараліся больш за адзін раз, што сведчыць аб тым, што большасць галюцынацый з'яўляюцца паўтаральнымі артэфактамі, а не аднаразовым шумам. Менавіта гэтая паўтаральнасць ператварае аднаразовую галюцынацыю ў маштабуемую атаку слопсквотынгу.
2026: Ад ізаляваных пакетаў да аўтаномных агентаў. Гэты год даў найбольш відавочныя доказы таго, што нядбайнасць больш не абмяжоўваецца капіяваннем прапанаванага распрацоўшчыкам ўстаноўка pip or ная ўстаноўка каманда. У студзені 2026 года даследчык Чарлі Эрыксен У Aikido Security выявілі, што агенты па кадаванні штучнага інтэлекту ўжо распаўсюдзілі інструкцыі, якія спасылаюцца на галюцынаваны npm-пакет, рэагаваць-зрух кода (назва, якая праўдападобна аб'ядноўвае два рэальныя інструменты, jscodeshift і react-codemod), у 237 рэпазіторыях, прычым агенты ўсё яшчэ штодня спрабуюць усталяваць яго. Эрыксен сам зарэгістраваў назву, абараняючыся, перш чым зламыснік змог бы выкарыстаць яе ў якасці зброі. Асобна, сапраўдны шкоднасны пакет пад назвай нявыкарыстаны імпарт, галюцынаваў замест законнага eslint-plugin-unussed-imports, у пачатку 2026 года ўсё яшчэ фіксаваў каля 233 штотыднёвых загрузак, нягледзячы на тое, што npm прыпыніў яго бяспеку, што сведчыць пра тое, як доўга атака з выкарыстаннем нядбайнасці можа прыцягваць ахвяр нават пасля таго, як яе пазначылі. Зусім нядаўна, у ліпені 2026 года, даследчыкі апісалі падобную тэхніку пад назвай «HalluSquatting», якая злучае галюцынацыю штучнага інтэлекту з імгненнай ін'екцыяй, каб агент кадавання штучнага інтэлекту, які атрымлівае рэсурс з галюцынацыямі ад імя карыстальніка, мог быць вымушаны запусціць код, прадастаўлены зламыснікам, пашыраючы эвалюцыю нядбайнасці ад пасіўнай рызыкі ўстаноўкі да актыўнага вектара дыстанцыйнага выканання кода ўнутры працоўных працэсаў агентнай распрацоўкі.
Чаму «вібрацыйнае кадаванне» пашырыла магчымасці для нядбайных нападаў
Атакі з выкарыстаннем метаду «слопсквотынгу» не мелі б вялікага значэння, калі б код, згенераваны штучным інтэлектам, быў нішавай практыкай. Але гэта не так. З'яўленне памочнікаў кадавання, аўтаномных агентаў і працоўных працэсаў «вібрацыйнага кадавання», дзе распрацоўшчыкі правяраюць усё менш і менш кода перад яго запускам, змяніла паверхню для праграмных атак двума канкрэтнымі спосабамі, і абодва паскараюць эвалюцыю слопсквотынгу:
- Кропкай уваходу больш не з'яўляецца толькі распрацоўшчык. Раней памылка пры друку рабілася адным чалавекам. Цяпер памылка можа ўзнікнуць унутры самой мадэлі і распаўсюдзіцца на сотні розных распрацоўшчыкаў, якія задаюць падобныя пытанні і атрымліваюць адну і тую ж выдуманую рэкамендацыю, што памнажае ахоп адной нядбайнай атакі.
- Паверхня атакі перамясцілася далей па ланцужку. Больш недастаткова назіраць за кодам, які піша чалавек. Камандам таксама трэба сачыць за залежнасцямі, якія прапануе памочнік штучнага інтэлекту, за серверамі MCP, да якіх ён падключаецца, і за агентамі, якія ўсталёўваюць пакеты аўтаномна, без непасрэднага праверкі чалавекам. Традыцыйная AppSec, створаная для праверкі рэпазіторыяў і людзей. commits, ніколі не быў распрацаваны для назірання за гэтым новым узаемадзеяннем паміж распрацоўшчыкам, штучным інтэлектам і рэестрам пакетаў, і менавіта ў ім цяпер хаваюцца неахайныя атакі.
Нішто з гэтага не азначае, што генератыўны штучны інтэлект па сваёй сутнасці небяспечны. Гэта азначае, што ён уводзіць новы тып рызыкі для ланцужка паставак, для выяўлення якой традыцыйныя інструменты бяспекі не былі прызначаны, і які патрабуе тых жа прынцыпаў праверкі, якія мы ўжо ўжываем да любой знешняй залежнасці: не давярайце па змаўчанні, праверце крыніцу і аўтаматызуйце гэтую праверку замест таго, каб спадзявацца на памяць або пільнасць кожнага распрацоўшчыка. Гэтая аўтаматызацыя з'яўляецца асновай любой рэальнай стратэгіі прадухілення нядбайнасці.
Прадухіленне нядбайнага прысядання: што каманды могуць зрабіць сёння
Добрая навіна заключаецца ў тым, што для прадухілення нядбайнасці не патрэбныя экзатычныя інструменты. Яно патрабуе сістэматычнага прымянення ўжо існуючых практык гігіены залежнасцей, але многія каманды расслабляюцца ў той момант, калі штучны інтэлект, якому яны давяраюць, «прапануе» код. Эфектыўны падыход да прадухілення нядбайнасці звычайна спалучае наступнае:
- Уручную правярайце любы новы пакет перад яго ўсталёўкай, асабліва калі гэта прапанова памочніка штучнага інтэлекту. Пераканайцеся, што яно існуе ў афіцыйным рэестры, хто яго вядзе, калі яно было апублікавана і ці рэальная колькасць яго загрузак. Гэтая адзіная звычка — самая танная форма прафілактыкі нядбайнасці, даступная любой камандзе.
- Ніколі не мяркуйце, што код, згенераваны штучным інтэлектам, бяспечны па змаўчанні. Фрагмент кода, які «працуе», не азначае, што яго залежнасці з'яўляюцца законнымі. Праверка залежнасцей павінна быць часткай праверкі кода, а не выключэннем з яе.
- Выкарыстоўвайце файлы блакіроўкі і праверку хэша каб замацаваць дакладныя версіі і спыніць ціхае абнаўленне ад замены пакета, які адрозніваецца ад таго, які быў першапачаткова правераны.
- Разгарніце сканаванне залежнасцей, якое выяўляе шаблоны рызыкі, акрамя вядомых CVE.: анамальныя пакеты, назвы, падазрона падобныя да існуючых, новыя распрацоўшчыкі без гісторыі або ўсталяваныя скрыпты з незвычайнай паводзінамі. Новаапублікаваны пакет амаль без гісторыі, які вельмі блізка імітуе назву чагосьці «амаль» знаёмага, — гэта менавіта тая схема, якая ляжыць у аснове большасці неахайных нападаў, задакументаваных да гэтага часу.
- Стаўцеся да публічных рэестраў з такім жа скептыкамcisм, як і любая іншая неправераная знешняя крыніца. Той факт, што ўстаноўка pip or ная ўстаноўка не выклікае памылку, гэта не доказ легітымнасці.
- Навучанне каманд распрацоўшчыкаў на тым факце, што кадаванне з дапамогай штучнага інтэлекту не здымае адказнасці за праверку таго, што ўсталёўваецца; яно проста дадае крок, які павінен быць убудаваны ў працоўны працэс як частка любога сур'ёзнага плана па прадухіленні нядбайнасці.
Ніводная з гэтых мер сама па сабе не з'яўляецца новай. Змяніўся толькі маштаб: калі прапанова залежнасці больш не паступае ад Stack Overflow або ад калегі, а паступае ад мадэлі, якая можа паўтараць адну і тую ж галюцынаваную памылку тысячам розных распрацоўшчыкаў, ручная праверка, хоць і неабходная, перастае быць дастатковай сама па сабе. Вось чаму ўсё больш каманд аўтаматызуюць гэты ўзровень прадухілення нядбайнасці ў сваіх Аналіз складу праграмнага забеспячэння (SCA) інструменты, а не пакідаць гэта на волю асобных распрацоўшчыкаў.
Гэта папярэдняеcisчаму ASPM Платформы як Ксігені убудаваць выяўленне падазроных залежнасцей, уключаючы памылкі друку, блытаніну з залежнасцямі і вядомыя шкоднасныя пакеты, у адзін і той жа аналіз залежнасцей ад адкрытага зыходнага кода і штучнага інтэлекту pipeline, таму прадухіленне нядбайнасці не залежыць ад таго, ці павінен кожны распрацоўшчык памятаць пра гэта кожны раз, калі памочнік штучнага інтэлекту прапануе новую залежнасць.
Часта задаваныя пытанні
Ці з'яўляецца атака нядбайнасці тым жа самым, што і атака тыпасквотынгу?
Не зусім. Абодва метады ўключаюць рэгістрацыю фальшывай назвы пакета, каб падмануць таго, хто яго ўсталёўвае, але крыніца памылкі адрозніваецца. Тыпасквотынг выкарыстоўвае памылкі друку, атрыманыя чалавекам. Атака нядбайнасці выкарыстоўвае назвы пакетаў, выдуманыя (галюцынаваныя) мадэлямі штучнага інтэлекту, якія зламыснік затым рэгіструе да таго, як яны існавалі легальна.
Ці можа менеджар пакетаў аўтаматычна прадухіліць такую атаку?
Не цалкам, і менавіта таму прадухіленне нядбайнасці не можа спыніцца на ўзроўні менеджара пакетаў. Калі зламыснік зарэгіструе выдуманы пакет да таго, як распрацоўшчык паспрабуе яго ўсталяваць, усталёўка завершыцца без памылак, таму што пакет сапраўды існуе, нават калі ён шкоднасны. Эфектыўнае прадухіленне патрабуе дадатковай праверкі паходжання і паводзін пакета.
Ці гэта тычыцца толькі мадэляў з адкрытым зыходным кодам?
Не. Даследаванне Спраклена і інш. выявіла галюцынацыі ва ўсіх правераных мадэлях, у тым ліку ў камерцыйных, хоць і са значна меншай частатой (5.2% супраць 21.7% для ацэненых мадэляў з адкрытым зыходным кодам). Ніводная мадэль не пазбаўлена гэтай праблемы цалкам, і таму развіццё нядбайнага выкарыстання навыкаў ідзе ў нагу з ростам кадавання з дапамогай штучнага інтэлекту ў цэлым.
Гэта тэарэтычная рызыка, ці яна ўжо выкарыстана?
,en абдымаючы твар-клі Выпадак з пустым пакетам, загружаным даследчыкам, які быў спампаваны больш за 30 000 разоў за тры месяцы без якога-небудзь прасоўвання, паказвае, што рызыка не толькі тэарэтычная: галюцынаванае імя павінна быць дастаткова паслядоўным у розных падказках, каб хтосьці ператварыў яго ў сапраўдную нядбайную атаку.
