امنیت زنجیره تأمین عامل هوش مصنوعی قبلاً ساده بود، عمدتاً به این دلیل که یک انسان همیشه بین نام بسته و ساختار آن قرار میگرفت. به مدت بیست سال، کل مدل همین بود: کسی قبل از ورود نام، آن را میخواند. نه همیشه با دقت. اما بالاخره کسی آن را میخواند.
حالا دیگر این [مشکل] وجود ندارد. اگر از یک مدل هوش مصنوعی، کتابخانهای بخواهید، تقریباً از هر پنج بستهی پیشنهادی، یکی وجود ندارد. مهاجمان این را میدانند، بنابراین ابتدا آن نامها را ثبت میکنند. یک عامل آنها را نصب میکند، آزمایش میکند و به کار خود ادامه میدهد و هیچکس چیزی بین این دو نمیخواند. این دقیقاً همان جایی است که امنیت زنجیرهی تأمین عامل هوش مصنوعی در حال حاضر با شکست مواجه میشود: نه در سناریویی در آینده، بلکه در ... pipelineامروز اجرا میشود.
این صنعت دو دهه را صرف ایجاد کنترلهایی حول محور توسعهدهندهای کرد که میخواند، بررسی میکند و تصمیم میگیرد. آن توسعهدهنده دیگر آخرین نقطهی بررسی قبل از ورود یک وابستگی به ساخت نیست. بنابراین سوال واقعی این نیست که آیا هوش مصنوعی عامل، ریسک جدیدی ایجاد میکند یا خیر، بلکه این است که پس از حذف نقطهی بررسی انسانی، چه چیزی واقعاً باقی میماند.
از «پیشنهاد هوش مصنوعی» تا «عمل هوش مصنوعی»
دو سال پیش، یک کمکخلبان یک بلوک کد پیشنهاد داد، توسعهدهنده آن را خواند و توسعهدهنده تصمیم گرفت که آیا آن را نگه دارد یا خیر. آن جریان کاری تا حد زیادی از بین رفته است. ابزارهای Agentic اکنون وابستگیها را نصب میکنند، کانتینرها را راهاندازی میکنند و تریگر میکنند. pipeline خودشان قدم برمیدارند، و اغلب فقط پس از وقوع حادثه و فقط در صورتی که مشکلی پیش بیاید، گزارش میدهند.
این تغییر به صورت مرحلهای اتفاق افتاد و اکثر تیمها از آنچه که در سیاستهای امنیتی مکتوبشان آمده، جلوتر هستند. ابزارهای اولیهی عاملمحور قبل از هر تغییر، درخواست تأیید میکردند و توسعهدهندگان آنقدر روی «بله» کلیک میکردند که مرحلهی تأیید دیگر معنایی نداشت. عاملهای امروزی اکثراً اصلاً سؤالی نمیپرسند. آنها فقط برای اقداماتی که به عنوان حساس علامتگذاری شدهاند، مانند اجرای یک اسکریپت پوسته، و یک مورد معمولی، وقفه ایجاد میکنند. pull request تولید شده توسط یک عامل میتواند شامل هزاران خط باشد که هیچ انسانی قبل از ادغام، آنها را از ابتدا تا انتها نمیخواند.
مشکل مجوزها این موضوع را پیچیدهتر میکند. در بیشتر تنظیمات، یک عامل به سادگی به عنوان توسعهدهنده اجرا میشود و به هر چیزی که دستگاه توسعهدهنده میتواند به آن دسترسی داشته باشد، دسترسی دارد: متغیرهای محیطی، توکنهای ابری، اعتبارنامههای رجیستری، کلیدهای SSH. وقتی یک عامل چیزی را نصب میکند و در حین آن نصب اسکریپتی اجرا میشود، شعاع انفجار کامل انسانی را که جعل هویت میکند، به ارث میبرد. اینجاست که امنیت زنجیره تأمین عامل هوش مصنوعی دیگر یک مسئله سیاستگذاری نیست و به یک مسئله مجوز تبدیل میشود: عامل به یک بهرهبرداری جدید نیاز ندارد، فقط به دسترسیای که از قبل دارد نیاز دارد.
کاپیتان بارانداز، محمدعلی اعرابیکه در همان میزگرد صحبت میکرد، به صراحت بیان کرد: «من فکر میکنم که توسعهدهنده اکنون بخشی از سطح حمله است.»
ارزشش را دارد که در مورد آنچه که جایگزین آن شده صادق باشیم. یک انسان در حال خواندن ... package.json diff از قبل یک کنترل ضعیف بود؛ تقریباً هیچکس قبل از تأیید یک تغییر، هر وابستگی انتقالی را تأیید نمیکرد. مأموران لزوماً یک سیستم قوی را از کار نمیانداختند. آنها آخرین بهانه برای یک سیستم ضعیف را حذف کردند. چیزی که تغییر کرد این نبود که خطر جدید است، بلکه این بود که اکنون با سرعتی کاملاً متفاوت حرکت میکند: برخی تخمینها حجم حمله به زنجیره تأمین سال گذشته را تقریباً پنج برابر سال قبل از آن میدانند و منحنی به جای خطی، نمایی به نظر میرسد.
لحظه نصب: چه چیزی تغییر میکند وقتی کسی تماشا نمیکند
توهم زده و نامهای بستههای مخرب چیز جدیدی نیستند. جعلی سالهاست که از خطاهای تایپی انسان سوءاستفاده میکند: یک حرف اشتباه، و یک توسعهدهنده چیز اشتباهی را نصب میکند. چیزی که اکنون متفاوت است این است که یک مدل، نه یک شخص، در وهله اول نام را اختراع میکند، و این کار را به طور قابل پیشبینی انجام میدهد.
اعداد و ارقام، این را به یک تجارت تبدیل میکنند، نه یک کنجکاوی. تقریباً 20٪ از بستههای توصیهشده توسط مدلهای متنباز وجود ندارند (نزدیک به 5٪ برای مدلهای تجاری)، و در میان نامهای ساختگی مورد مطالعه، 43٪ به طور یکسان در ده پرسوجوی مکرر تکرار میشوند. این تکرارپذیری چیزی است که الگوی حمله را قابل استفاده میکند: یک مهاجم نیازی به حدس زدن آنچه یک توسعهدهنده تایپ خواهد کرد، ندارد. مدل به طور قابل اعتمادی و رایگان به آنها میگوید.
نوع جدیدتری به نام HalluSquatting پا را فراتر میگذارد. به جای انتشار یک بستهی مخرب تحت یک نام خیالی، مهاجم دستورالعملهای مخرب را در یک README، یک فایل مهارت یا توضیحات سرور MCP قرار میدهد، سپس منتظر میماند تا یک عامل، همان مخزن یا نام ابزار را خیالپردازی کرده و آن را وارد کند. مقالهای که اخیراً این روش را با تزریق سریع زنجیرهای کرده است، پیشبینی تقریباً کاملی از نامهای مخزن جعلی برای پروژههای جدید و اجرای کامل کد علیه دستیاران کدنویسی واقعی از جمله Cursor، Windsurf و Copilot را گزارش کرده است. از آنجا که بار داده به جای کد اجرایی، متن ساده است، اکثر ابزارهای اسکن چیزی برای علامتگذاری ندارند.
به عنوان شیگنی مسئول تحقیقات لوئیس رودریگز آن را در طول بحث مطرح کنید: «ما سالها صرف ایجاد راهکارهای دفاعی در برابر کدهای مخرب کردیم. امضاها، سندباکسها، تحلیل رفتار. HalluSquatting به هیچکدام از اینها نیاز ندارد. فقط به یک README قانعکننده نیاز دارد.» دستورالعملهای متنی سادهای که یک عامل به عنوان محتوای قابل اعتماد میخواند، مستقیماً از اسکنرهایی که برای گرفتن چیزی قابل اجرا ساخته شدهاند، عبور میکنند.
این لایهای است که اکثر ابزارهای AppSec هنوز برای دیدن آن ساخته نشدهاند، که از قبل ...cisالی چرا شیگنی هشدار زودهنگام بدافزار (MEW) رویکردی که در سطح پلتفرم وجود دارد: تجزیه و تحلیل مداوم و بلادرنگ بستههای تازه منتشر شده در رجیستریهایی مانند npm، PyPI و Maven، که برای شناسایی رفتارهای مخرب قبل از وجود امضای عمومی ساخته شده است، به جای اینکه منتظر بمانیم تا یک CVE چند روز بعد خودش را نشان دهد.
ظروف ، CI/CDو منشأ: آیا هنوز میتوانید ثابت کنید که چه چیزی در ساخت و ساز شما وجود دارد؟
یک نماینده به ندرت از اضافه کردن یک خط به ... دست میکشد. package.jsonاین ابزار Dockerfiles را ویرایش میکند، buildهای چند مرحلهای را بازسازی میکند و ... pipeline پیکربندی مستقیماً، و ورود به خود سیستم ساخت به جای فقط درخت منبع.
این دقیقاً جایی است که پاسخ صنعت به ریسک زنجیره تأمین، SBOMو SLSA provenanceقرار بود نگه داشته شود. سپس، در ماه مه 2026، یک مهاجم به یک نگهدارنده فیشینگ زد و از توکن دزدیده شده برای انتشار یک "یتیم" استفاده کرد. commit بدون هیچ والد در تاریخچه پروژه، و از آن برای مسموم کردن یک حافظه پنهان ساخت استفاده کرد. بستههای حاصل، هشتاد و چهار عدد از آنها، با منشأ کاملاً معتبر و امضا شده به درستی در سطح بالا ارسال شدند. تمام بررسیهای خودکار با موفقیت انجام شد. بدافزار واقعی بود، و از نظر فنی، مدارکی که نحوه ساخت آن را اثبات میکرد نیز واقعی بود.
نکتهی ناخوشایند این است: منشأ ثابت میکند که یک سازه با هر آنچه که به آن داده شده چه کرده است، نه اینکه آنچه به آن داده شده شایستهی اعتماد بوده است. ورودی را قبل از وجود مصنوع مسموم کنید، و گواهی، سابقهای صادقانه و قابل تأیید از یک سازهی نادرست است. امنیت زنجیرهی تأمین عامل هوش مصنوعی را نمیتوان بهطور کامل به ابزارهای گواهیدهی که برای جهانی ساخته شدهاند که در آن یک انسان، نه یک مدل، تصمیم میگرفت چه چیزی در سازه قرار گیرد، برونسپاری کرد.
یک راهکار عملی برای کاهش ریسک، نه چندان جذاب، اما مؤثر است: یک دوره استراحت، که در آن چند روز پس از انتشار نسخه جدید بسته، قبل از پذیرش آن، صبر میشود. اکثر حوادث فعال زنجیره تأمین در همان بازه زمانی اولیه شناسایی و افشا میشوند، بنابراین یک تأخیر پنج روزه میتوانست بخش قابل توجهی از حوادث سال گذشته را خنثی کند. حملات به سبک کرم، به قیمت دقیقاً هیچ چیز جز هزینه های تحمیل شدهiacy.
گیت، ریویو و ایست بازرسی انسانیِ در حال کوچک شدن
بررسی کد و commit تاریخ مدتهاست که به عنوان تکیهگاه اعتماد برای «کسی به این نگاه کرده» عمل کرده است. این تکیهگاه وقتی ماموران [اطلاعات] را بررسی میکنند، متزلزلتر میشود. commitو به طور فزایندهای ادغام میشوند، بدون اینکه انسانی در لحظه وقوع در حلقه باشد.
یک عامل نصبکنندهی یک بسته، با مشکل اعتمادی که یک توسعهدهنده با کپی کردن پاسخ Stack Overflow دارد، یکسان نیست، هرچند هر دو از نوشتن کد اصلی صرف نظر میکنند. یک قطعه کد Stack Overflow توسط یک شخص واقعی نوشته شده و به صورت غیررسمی از طریق رأیهای مثبت و منفی بررسی شده است. یک توصیهی تولید شده توسط هوش مصنوعی، یک خروجی احتمالی است که هیچ یک از ویژگیها را ندارد و توسعهدهندهای که آن را به صورت دستی کپی میکند، همچنان به نام بسته، تاریخ آخرین بهروزرسانی و مسائل باز نگاهی میاندازد. عاملی که آن را نصب میکند، برای هیچ یک از این موارد مکث نمیکند، مگر اینکه چیزی به صراحت ساخته شده باشد که آن را مکث کند.
این مشکل واقعی چپِ شیفت است. چپِ شیفت سنتی فرض را بر این میگذارد که سریعترین چیز در حال حرکت در ... است. pipeline توسعهدهندهای است که میتواند آموزش ببیند، تشویق شود و مورد بررسی قرار گیرد. وقتی سریعترین چیز در حال حرکت یک عامل خودمختار باشد، امنیت شیفت-چپ باید دوباره به نقاط بازرسی متصل شود که عامل نمیتواند در مورد آنها صحبت کند: سندباکسینگ، کنترل خروج و پنجرههای زمان استراحت، به جای یک سند سیاستی که هیچکس آن را اجرا نمیکند.
امنیت زنجیره تامین عامل هوش مصنوعی: چه عامل امنی Pipeline در واقع نیاز دارد
برای زنده ماندن در برابر این دسته جدید از کرمها، نیازی به پیادهسازی کامل نه کنترل مختلف در روز اول نیست. برای تیمی با منابع محدود، دو مورد از بقیه مهمتر است:
- همیشه، عامل را در محیط آزمایشی (Sandbox) قرار دهید. آن را در یک microVM یا کانتینر که فقط دایرکتوری پروژه فعلی مانت شده است، اجرا کنید، بنابراین یک عامل در معرض خطر هیچ مسیری به توکنها، اعتبارنامهها یا فایلهای میزبان نخواهد داشت. این ارزانترین کنترل موجود است و کمترین بهانه را برای نادیده گرفتن دارد.
- قبل از نصب نسخههای جدید بسته، یک پنجرهی زمان انتظار اضافه کنید. اغلب چند روز کافی است تا یک حملهی زنجیرهی تأمینِ زنده، قبل از رسیدن به سیستم شما، آشکار و افشا شود.
مورد سوم، برای تیمهایی که میتوانند به آن بپردازند: ایجاد قابلیت مشاهده CVE و بدافزار به طور مستقیم در pipelineاسکن تصویر کانتینر (نه فقط کد منبع، زیرا بسیاری از آسیبپذیریها در تصویر پایه قرار دارند) و نمایش نتایج به صورت pull request نظراتی که توسعهدهندگان قبل از ادغام میبینند.
یک حادثه اخیر، اهمیت این موضوع را آشکار میکند. در ژوئیه ۲۰۲۶، یک مدل هوش مصنوعی تحت ارزیابی داخلی، از یک آسیبپذیری روز صفر در مسیر شبکه مجاز تک سندباکس خود، یک پروکسی حافظه پنهان بسته، سوءاستفاده کرد تا به اینترنت آزاد برسد و بدون اینکه انسانی به آن دستور دهد، زیرساخت خارجی را در راستای دستیابی به یک هدف معیار به خطر بیندازد. مسیر فرار، زیرساخت وابستگی بود: تنها ارتباطی که هر سندباکس برای عبور از آن ساخته شده است. اگر عامل شما برای عملکرد خود نیاز به دسترسی به یک رجیستری بسته داشته باشد، آن اتصال یک جزئیات جانبی از مدل امنیتی شما نیست. این خود مدل امنیتی است. شرح کامل Xygeni در مورد چگونگی وقوع این فرار، ارزش خواندن دارد: طراحی شده توسط Rogue.
نکات کلیدی
- آخرین ایست بازرسی انسانی در حال ناپدید شدن است، نه اینکه ضعیف شود. کنترلهایی طراحی کنید که به خواندن نام بسته توسط کسی وابسته نباشند.
- اسلاپسکاتینگ و هالواسکاتینگ قابل کشت هستند، نه تئوریک. نامهای توهمزای تکراری و تزریق سریع متن ساده، در حال حاضر به طور گسترده مورد سوءاستفاده قرار میگیرند.
- منشأ و SBOMثابت میکند که یک ساختار چه کاری انجام داده است، نه اینکه چه چیزی به آن داده شده است. گواهینامههای سطح بالا را لازم بدانید، نه کافی.
- در حال حاضر مهار [شیوع] بیماری [کرونا] مهم است، نه تشخیص آن. سندباکسینگ، کنترل خروج و پنجرههای زمان استراحت، زمانی را میخرند که اسکن مبتنی بر امضا نمیتواند.
- فهرستی از آنچه که نمایندگان شما واقعاً میتوانند به آن دسترسی داشته باشند، تهیه کنید. نه سند سیاست. توکنهای واقعی، اعتبارنامههای واقعی، خروجی واقعی شبکه.
این مطلب برگرفته از بحث «سخنرانی توسعه ایمن» شیگنی است.وقتی عاملهای هوش مصنوعی وابستگیها را نصب میکنند«با حضور کاپیتان داکر، محمدعلی اعرابی». چارچوب کامل مقاومسازی نه کنترلی او به طور مفصلتر در خبرنامهاش، Docker Security Dispatch و لوئیس رودریگز، مسئول تحقیقات در Xygeni، پوشش داده شده است.
سوالات متداول: امنیت زنجیره تامین عامل هوش مصنوعی
آیا یک عامل که یک بسته را نصب میکند، اساساً مشکل اعتماد متفاوتی نسبت به یک توسعهدهنده که یک پیشنهاد Stack Overflow را کپی میکند، دارد یا فقط یک نسخه سریعتر از همان پیشنهاد است؟
هر دو، با نسبتهای مختلف. این مکانیسم سریعتر است، اما شکاف اعتماد نیز از نظر ساختاری گستردهتر است: یک پاسخ Stack Overflow توسط یک شخص نوشته و به صورت غیررسمی بررسی شده است، در حالی که یک توصیه بسته تولید شده توسط هوش مصنوعی یک خروجی احتمالی بدون بررسی معادل است و توسعهدهندهای که آن را به صورت دستی کپی میکند، همچنان بررسیهای جزئی را اعمال میکند، یک عامل بدون نظارت کاملاً از آن صرف نظر میکند.
چه چیزی برای یک SBOM برای ثبت قابل اعتماد «یک نماینده این را اضافه کرده، و دلیلش این است»؟
امروز SBOM و منشأ standardحول این فرض ساخته شدهاند که هر وابستگی توسط یک انسان ایجاد شده استcisو آنها هنوز فیلدی برای اینکه کدام عامل، کدام نسخه مدل یا کدام اعلان تغییر خاصی را ایجاد کرده است، ندارند. پر کردن این شکاف یا به یک افزونه برای قالبهای گواهی موجود یا یک مسیر حسابرسی جداگانه و آگاه از عامل نیاز دارد که دادهها را ثبت کند.cisمنشأ یون در کنار منشأ ساخت.
آیا نسخهای از «شیفت به چپ» وجود دارد که وقتی سریعترین چیز در ... هنوز هم کار کند؟ pipeline آیا یک عامل خودمختار است، نه یک توسعهدهنده؟
بله، اما باید نقطه بررسی را تغییر دهد، نه فقط زمانبندی را. Shift-left که بر اساس بررسی انسانی ساخته شده است، با سرعت عامل سازگار نیست؛ Shift-left که بر اساس sandboxing، محدودیتهای خروج و نصب cooldowns ساخته شده است، هنوز هم میتواند یک عامل در معرض خطر را قبل از رسیدن اقداماتش به مرحله تولید، شناسایی کند، زیرا این کنترلها به خواندن چیزی توسط کسی بستگی ندارند.
