ستونزه په یوه جمله کې
بل ځل یو د مصنوعي ذهانت مرستیال د نصبولو لپاره یو بسته وړاندیز کوي، ایا تاسو به په حقیقت کې وګورئ چې ایا دا بسته شتون لري؟ ډیری پراختیا کونکو دا نه دي کړي. د وړاندیز او تایید ترمنځ دا تشه په سمه توګه هغه ځای ده چې د سلپسکواټینګ بریدونه پیل کیږي، او له همدې امله د سلپسکواټینګ ارتقا او عملي سلپسکواټینګ مخنیوي پوهیدل د AppSec او DevSecOps ټیمونو لپاره یو ریښتینی لومړیتوب ګرځیدلی.
په یوه ځای کې ناست برید څه شی دی؟
د یو بل په څنګ کې ناست برید د د ټایپوسکواټینګ (د یو ډومین یا پیکج نوم ثبتولو عمل چې د یو عام غلط املا له لارې د مشروع نوم تقلید کوي، لکه غوښتنې پرځای د غوښتنې(، هیله ده چې د کارونکي خپله ټایپ کول دوی مستقیم دې ته ورسوي)، مګر د دې مهم توپیر سره چې تېروتنه له کوم ځای څخه سرچینه اخلي. ټایپوسکاټینګ د انسانانو د ټایپ کولو تېروتنو څخه ګټه پورته کوي. د سلپسکوټینګ برید د لویو ژبو ماډلونو له غلطیو څخه ګټه پورته کوي: یو LLM د یو بسته نوم "خیانت کوي" چې په بشپړ ډول مشروع ښکاري مګر په هیڅ عامه راجسټری کې شتون نلري، او بریدګر لومړی د هغه دقیق نوم ثبتولو سره هلته رسیږي مخکې لدې چې څوک ښه نیت ولري.
د یو عادي سلپسکواټینګ برید تر شا میکانیزم ساده دی، او دا سادگي په سمه توګه هغه څه دي چې دا اغیزمن کوي:
- یو پراختیا ورکوونکی د مصنوعي ذهانت له مرستیال څخه د کوډ کولو ستونزې حل کولو کې د مرستې غوښتنه کوي.
- دا ماډل داسې حل رامینځته کوي چې د داسې بسته واردوي یا نصبولو سپارښتنه کوي چې هیڅکله شتون نلري.
- یو بریدګر چې لیدلي وي چې څو ماډلونه ورته وهمي نوم تکراروي، هغه پیکج په npm، PyPI، یا بل عامه راجسټری کې ثبتوي، چې دننه یې ناوړه کوډ وي. دا هغه شیبه ده چې وهمي په ریښتیني سلپسکویټینګ برید بدلیږي.
- راتلونکی پراختیا ورکوونکی چې ورته وړاندیز ترلاسه کوي او تایید یې نه کوي، هغه اوس اصلي بسته نصبوي، کوم چې د دوی چاپیریال ته د ننوتلو دروازه ده.
د "سلاپسکوټینګ" اصطلاح د سیټ لارسن لخوا رامینځته شوه، د پایتون سافټویر بنسټ کې د امنیت پراختیا کونکي، او د انډریو نیسبټ لخوا مشهوره شوه، ترڅو دا نمونه په سمه توګه تشریح کړي: د "پیکج وهم" په برید ویکتور بدل شو.
بې ثباته تکامل: څنګه د څیړنې لیوالتیا په ریښتیني ګواښ بدله شوه
هغه څه چې د سلپ سکواټینګ د تکامل په اړه د پام وړ دي یوازې مفهوم نه دی؛ دا دی چې دا څومره ژر د څیړنې مشاهدې څخه د برید مستند، اندازه کیدونکي ټولګي ته لاړ.
۲۰۲۳: د خبرداري لومړۍ نښه. د امنیت څېړونکی بار لانیاډو ولیدل چې ډیری LLMs په مکرر ډول د یوې بستې سپارښتنه وکړه چې نوم یې دی د مخ غېږ ورکول، کوم چې شتون نلري (اصلي بسته د دې سره نصب شوې ده د پایپ انسټال -U "huggingface_hub[cli]"). د خطر د ښودلو لپاره، هغه د دې کڅوړې یوه خالي نسخه عامه راجستر ته اپلوډ کړه. د دریو میاشتو په اوږدو کې، دا د 30,000 څخه ډیر ډاونلوډونه ترلاسه کړل، پرته له کوم ترویج څخه. دا وهم شوی نوم حتی د علی بابا څیړنې پورې تړلي د ذخیره README کې راڅرګند شو، چې په پیل کې یې وښودله چې څنګه دا "جعلي" نومونه کولی شي په ریښتیني اسنادو کې لیک شي او د تعقیبي بریدونو لپاره لاره هواره کړي چې وروسته به راشي.
۲۰۲۴: خطر د یو څیړونکي د بلاګ پوسټ څخه د ټیکنالوژۍ اصلي پوښښ ته لیږدول کیږي. په مارچ کې 2024، راجستر راپور ورکړ چې څنګه د مصنوعي ذهانت ماډلونه په ډاډ سره د سافټویر پیکج نومونه اختراع کول چې پراختیا کونکي یې بیا ډاونلوډ کول، ځینې یې په احتمالي توګه د مالویر سره مسموم شوي وو. دا پوښښ د هغه څه لپاره لږ مهم و چې دا یې په تخنیکي توګه څرګند کړ او د هغه څه لپاره چې یې اشاره یې کوله: د huggingface-cli قضیه نور د یو ځل لپاره تجسس نه وه؛ دا د یوې جدي نمونې لومړۍ نښه وه چې د اصلي ټیکنالوژۍ مطبوعاتو لپاره یې بیرغ پورته کړ، د لویې کچې اکاډمیک مطالعې څخه مخکې چې یو کال وروسته به ساحه تایید کړي.
۲۰۲۵: د ستونزې لومړۍ سخته او لویه پیمانه اندازه ګیري. کاغذ "موږ ستاسو لپاره یو بسته لرو! د کوډ تولیدونکي LLMs لخوا د بستې وهمونو جامع تحلیل" (Spracklen et al.، په کې وړاندې شوی د USENIX امنیت سمپوزیم) د کوډ نسل ۱۶ ماډلونه، دواړه سوداګریز (GPT-4، GPT-3.5) او خلاص سرچینه (CodeLlama، DeepSeek، WizardCoder، Mistral)، د 576,000 Python او JavaScript کوډ نمونو په اوږدو کې ازمول. موندنې د slopsquatting په ارتقا کې یو روښانه ټکی په ګوته کوي، دا له کیسې څخه معلوماتو ته لیږدوي:
- ۸۵٪ د ماډلونو لخوا وړاندیز شوي کڅوړې شتون نه درلود.
- د خلاصې سرچینې ماډلونه ډیر ځله وهم شوي (۸۵٪ په اوسط ډول) د سوداګریزو ماډلونو په پرتله (۸۵٪).
- تر ټولو بد سرغړوونکي، کوډ لاما ۷B او کوډ لاما ۳۴B، د خپلو پایلو له دریمې برخې څخه زیات په وهم کې وو.
- په ټولو ازمول شویو ماډلونو کې، څیړونکو ننوتل ۲۰۵۰۰۰ ځانګړي وهمي بستې نومونه، یو دومره لوی حوض چې په ډیری ایکوسیستمونو کې دوامداره سلپسکواټینګ بریدونو ته وده ورکوي.
- یو تفصیل چې په ځانګړي ډول د مخنیوي لپاره اړونده دی: تقریبا ۸۵٪ د وهمي نومونو ډېری یې اصلي کڅوړو ته نږدې وو، چې دا چانس کموي چې څوک یې په یوه نظر وګوري.
د مطالعې څخه یوه مهمه توضیحات، او شاید د دې دلیل چې د سلپ سکوټینګ ارتقا ګړندی شوی پرځای یې چې له منځه تللی وي، دا دی چې وهمي نومونه ناڅاپي ندي، او دوی په هره هڅه کې نه بدلیږي. ورته ماډلونه ورته اختراع شوي نومونه تکراروي کله چې ورته اشارې ورکړل شي، پدې معنی چې بریدګر اټکل کولو ته اړتیا نلري. دوی یوازې د ماډل چلند مشاهده کولو ته اړتیا لري، هغه نومونه وپیژني چې تکرار کیږي، او مخکې لدې چې یو ریښتینی پراختیا کونکی یې وکړي ثبت کړي. د دې تکرار وړتیا تعقیبي تحلیل وموندله چې کله څیړونکو ورته اشارې لس ځله بیا چلولې، د هر یو په چلولو کې 43٪ د وهمي کڅوړو نومونه څرګند شول، او 58٪ له یو ځل څخه ډیر تکرار شول، دا ثبوت چې ډیری وهمي د یو ځل شور پرځای تکرار وړ اثار دي. دا تکرار وړتیا هغه څه دي چې یو ځل وهمي په یو ځل د اندازې وړ سلوپ سکوټینګ برید ته اړوي.
۲۰۲۶: له جلا شویو کڅوړو څخه تر خپلواکو اجنټانو پورې. سږ کال تر دې دمه تر ټولو روښانه شواهد وړاندې کړي دي چې سلپسکوټینګ نور د پراختیا کونکي لخوا وړاندیز شوی کاپي پیسټ کولو پورې محدود نه دی. د پایپ نصب کول or د npm لګول امر. د ۲۰۲۶ کال په جنوري کې، څېړونکی چارلي ایریکسن په ایکیډو امنیت کې وموندل شوه چې د AI کوډ کولو اجنټانو دمخه د npm د وهم لرونکي کڅوړې په اړه لارښوونې خپرې کړې وې، د غبرګون کوډ بدلون (یو نوم چې په احتمالي توګه دوه اصلي وسایل سره یوځای کوي، jscodeshift او د عکس العمل کوډ موډ)، په ۲۳۷ زیرمو کې، اجنټان لاهم هڅه کوي چې دا هره ورځ نصب کړي. ایریکسن نوم پخپله ثبت کړ، په دفاعي ډول، مخکې لدې چې بریدګر یې وسله وال کړي. په جلا توګه، یو ریښتینی ناوړه بسته نومول شوې نه کارول شوي واردات، د مشروع پر ځای وهم شوی د ایسلنټ-پلګ ان-نه کارول شوي-واردات، د ۲۰۲۶ کال په لومړیو کې شاوخوا ۲۳۳ اونیزې ډاونلوډونه ثبت کول سره له دې چې npm یې د امنیت لاندې ساتلی و، دا د دې نښه ده چې د سلپ سکواټینګ برید څومره وخت کولی شي د قربانیانو راجلبولو ته دوام ورکړي حتی وروسته له دې چې دا بیرغ شي. په دې وروستیو کې، د ۲۰۲۶ کال په جولای کې، څیړونکو یو اړونده تخنیک تشریح کړ، چې د "هالو سکواټینګ" په نوم یادیږي، چې د AI هولیسینیشن د چټک انجیکشن سره زنځیر کوي ترڅو د AI کوډ کولو اجنټ چې د کارونکي په استازیتوب هولیسینیټ سرچینه ترلاسه کوي د برید کونکي لخوا چمتو شوي کوډ چلولو ته وتښتول شي، د غیر فعال نصب خطر څخه د اجنټ پراختیا کاري فلو دننه فعال ریموټ کوډ اجرا کولو ویکتور ته د سلپ سکواټینګ ارتقا غځوي.
ولې "ویب کوډینګ" د سلپسکواټینګ بریدونو لپاره سطحه پراخه کړه
که چیرې د مصنوعي ذهانت له لارې تولید شوی کوډ یو ځانګړی عمل وای، نو د سلپ سکواټینګ بریدونه به ډیر مهم نه وای. داسې نه ده. د کوډ کولو معاونینو، خودمختار اجنټانو، او "ویب کوډینګ" کاري فلو زیاتوالی، چیرې چې پراختیا کونکي د چلولو دمخه د کوډ لږ او لږ بیاکتنه کوي، د سافټویر برید سطح په دوه مشخصو لارو بدل کړی، او دواړه د سلپ سکواټینګ ارتقا ګړندی کوي:
- د ننوتلو نقطه نور یوازې پراختیا کونکی نه دی. د ټایپ کولو برید پخوا د یو کس لخوا د ټایپ کولو تېروتنه پورې اړه درلوده. اوس دا تېروتنه کولی شي پخپله ماډل کې رامینځته شي او په سلګونو مختلفو پراختیا کونکو ته خپره شي چې ورته پوښتنې کوي او ورته وهمي سپارښتنه ترلاسه کوي، د یو واحد سلپکویټینګ برید لاسرسی څو چنده کوي.
- د برید سطحه د زنځیر څخه نوره هم پورته تللې ده. نور دا کافي نه ده چې هغه کوډ وګورئ چې یو انسان لیکي. ټیمونه هم اړتیا لري چې هغه انحصارونه وګوري چې د AI مرستیال یې وړاندیز کوي، د MCP سرورونه چې ورسره وصل کیږي، او هغه اجنټان چې په خپلواکه توګه پیکجونه نصبوي پرته له مستقیم انساني بیاکتنې څخه. دودیز AppSec، د زیرمو او انساني بیاکتنې لپاره جوړ شوی commits، هیڅکله د پراختیا کونکي، مصنوعي ذهانت، او د بسته بندۍ راجسټری ترمنځ د دې نوي تعامل د لیدلو لپاره ډیزاین شوی نه و، کوم چې په سمه توګه هغه ځای دی چې اوس د سلپسکوټینګ بریدونه پټ دي.
له دې څخه هیڅ یو دا معنی نلري چې تولیدي AI په طبیعي ډول ناامنه دی. دا پدې مانا ده چې دا د اکمالاتي زنځیر خطر یو نوی ډول معرفي کوي چې دودیز امنیتي وسایل د نیولو لپاره ندي جوړ شوي، او یو چې د ورته تایید اصولو غوښتنه کوي چې موږ دمخه په هر بهرني انحصار کې پلي کوو: په ډیفالټ باور مه کوئ، سرچینه تایید کړئ، او د هر پراختیا کونکي په حافظه یا څارنې تکیه کولو پرځای دا تایید اتومات کړئ. دا اتومات کول د هر ریښتیني سلپسکویټینګ مخنیوي ستراتیژۍ بنسټ دی.
د بې هوښه کېدو مخنیوی: ټیمونه نن ورځ څه کولی شي
ښه خبر دا دی چې د بې هوښه کېدو مخنیوی بهرني وسایلو ته اړتیا نلري. دا په سیستماتیک ډول د انحصار حفظ الصحې کړنو پلي کولو ته اړتیا لري چې دمخه شتون لري، مګر ډیری ټیمونه هغه وخت آرام کوي کله چې یو AI چې دوی باور لري کوډ "وړاندیز" کوي. د بې هوښه کېدو مخنیوي یوه مؤثره طریقه معمولا لاندې سره یوځای کوي:
- د نصبولو دمخه هر نوی پیکج په لاسي ډول تایید کړئ، په ځانګړي توګه کله چې دا د AI مرستیال له وړاندیز څخه راځي. تایید کړئ چې دا په رسمي راجسټری کې شتون لري، څوک یې ساتي، کله خپور شو، او ایا د ډاونلوډ شمیرې یې ریښتیني ښکاري. دا یوازینی عادت د هرې ډلې لپاره د سلپسکویټینګ مخنیوي ترټولو ارزانه بڼه ده.
- هیڅکله دا مه انګیرئ چې د AI لخوا تولید شوی کوډ په ډیفالټ ډول خوندي دی. د کوډ یوه ټوټه چې "کار کوي" پدې معنی نه ده چې د هغې انحصار مشروع دی. د انحصار بیاکتنه باید د کوډ بیاکتنې برخه وي، نه استثنا.
- د لاک فایلونو او هش تصدیق وکاروئ د دقیقو نسخو د پین کولو لپاره او د خاموش تازه معلوماتو د هغه بسته په پرتله چې په اصل کې پلټل شوې وه، په بل بسته کې د تبادلې مخه ونیسئ.
- د انحصار سکیننګ ځای پر ځای کړئ چې د پیژندل شوي CVEs هاخوا د خطر نمونې په نښه کوي: غیر معمولي کڅوړې، نومونه چې په شکمن ډول د موجوده سره ورته وي، نوي ساتونکي چې هیڅ ریکارډ نلري، یا د غیر معمولي چلند سره سکریپټونه نصب کړي. یو نوی خپور شوی کڅوړه چې تقریبا هیڅ تاریخ نلري چې د "تقریبا" پیژندل شوي شی نوم سره نږدې تقلید کوي په سمه توګه د ډیری سلپسکویټینګ بریدونو تر شا نمونه ده چې تر دې دمه مستند شوي.
- د عامه ثبت ادارو سره ورته شکونه ولرئcism لکه د کومې بلې نا تایید شوې بهرنۍ سرچینې په څیر. حقیقت دا دی چې د پایپ نصب کول or د npm لګول تېروتنه نه کوي د مشروعیت ثبوت نه دی.
- د پراختیایي ټیمونو روزنه په دې حقیقت چې د مصنوعي ذهانت په مرسته کوډ کول د نصب شوي شیانو د تصدیق کولو مسؤلیت نه لرې کوي؛ دا یوازې یو ګام اضافه کوي چې باید د هر ډول جدي سلپسکویټینګ مخنیوي پلان برخې په توګه د کار په جریان کې شامل شي.
د دې اقداماتو څخه هیڅ یو په خپل ځان کې نوی نه دی. هغه څه چې بدل شوي دي هغه پیمانه ده: کله چې د انحصار وړاندیز نور د سټیک اوور فلو یا همکار څخه نه راځي، مګر د یو ماډل څخه چې کولی شي ورته وهمي تېروتنه زرګونو مختلفو پراختیا کونکو ته تکرار کړي، لاسي تایید، پداسې حال کې چې لاهم اړین دی، په خپل ځان کې کافي نه دی. له همدې امله ډیر ټیمونه د دوی دننه د سلپسکویټینګ مخنیوي دا طبقه اتومات کوي. د سافټویر جوړښت تحلیل (SCA) وسایل، د دې پرځای چې دا انفرادي پراختیا کونکي ډسپلین ته پریږدي.
دا مخکې دیcisولې ASPM پلیټونه په شان ژیګیني د شکمن انحصار کشف کول، د ټایپ کولو، انحصار ګډوډۍ، او پیژندل شوي ناوړه کڅوړو پوښښ، په ورته خلاصې سرچینې او AI انحصار تحلیل کې جوړ کړئ. pipeline، نو د سلپسکواټینګ مخنیوی په هر پراختیا کونکي پورې اړه نلري چې هر ځل چې د AI مرستیال د نوي انحصار وړاندیز کوي نو دا باید وګوري.
FAQs
ایا د بې ځایه کارونې برید د ټایپوسکوټینګ برید سره ورته دی؟
په بشپړه توګه نه. دواړه د جعلي پیکج نوم ثبتول دي ترڅو هغه څوک چې دا نصبوي دوکه کړي، مګر د غلطۍ سرچینه توپیر لري. ټایپوسکویټینګ د انسانانو د ټایپ کولو غلطیو څخه ګټه پورته کوي. یو سلپسکویټینګ برید د AI ماډلونو لخوا اختراع شوي (خیالي) د پیکج نومونه کاروي، کوم چې بریدګر بیا د قانوني شتون دمخه راجستر کوي.
ایا د پیکج مدیر په اتوماتيک ډول د دې ډول برید مخه نیولی شي؟
په بشپړه توګه نه، له همدې امله د سلپسکواټینګ مخنیوی د پیکج مدیر په کچه نشي دریدلی. که چیرې یو بریدګر د پراختیا کونکي د نصبولو هڅه کولو دمخه د وهم شوي پیکج ثبت کړي، نو نصب به پرته له کومې غلطۍ بشپړ شي ځکه چې پیکج په ریښتیا سره شتون لري، که څه هم دا ناوړه دی. اغیزمن مخنیوی د پیکج د اصل او چلند اضافي تایید ته اړتیا لري.
ایا دا یوازې د خلاصې سرچینې ماډلونو اغیزه کوي؟
نه. د سپراکلین او نورو مطالعې په هر ازمول شوي ماډل کې وهمي افکار وموندل، په شمول د سوداګریزو ماډلونو، که څه هم د پام وړ ټیټ نرخ سره (د خلاصې سرچینې ماډلونو لپاره د 21.7٪ په پرتله 5.2٪). هیڅ ماډل په بشپړ ډول له ستونزې څخه پاک نه دی، کوم چې د دې یوه برخه ده چې ولې د سلپسکوټینګ ارتقا په ټولیز ډول د AI په مرسته کوډ کولو ودې سره سرعت ساتي.
ایا دا یو نظري خطر دی، یا دا دمخه کارول شوی دی؟
د د مخ غېږ ورکول قضیه، د یو څیړونکي لخوا اپلوډ شوی خالي بسته چې په دریو میاشتو کې له 30,000 څخه ډیر ځله ډاونلوډ شوې وه پرته له کوم ترویج څخه، ښیې چې خطر یوازې تیوریکي نه دی: یو وهم شوی نوم یوازې د مختلفو اشارو سره دومره مطابقت ته اړتیا لري چې یو څوک یې په ریښتیني بې ځایه برید بدل کړي.
