برای دومین بار در چند هفته: بسته‌های مایکروسافت آلوده به سرقت اطلاعات ورود که عاملان هوش مصنوعی را هدف می‌گیرند

برای دومین بار در عرض چند هفته، محققان امنیتی ده‌ها بسته متن‌باز منتشرشده تحت نام مایکروسافت (Microsoft) را کشف کردند که به‌طور مخفیانه با کدی برای سرقت اطلاعات ورود (Credential Stealer) آلوده شده بودند — بسته‌هایی که به‌طور خاص طراحی شده بودند تا زمانی فعال شوند که توسط عاملان کدنویسی هوش مصنوعی باز می‌شوند، نه لزوماً توسط یک توسعه‌دهنده انسانی.

۱. چه اتفاقی افتاد: کالبدشکافی حمله

محققان امنیتی ده‌ها بسته را شناسایی کردند که با گواهی‌های تأییدشده رمزنگاری (Cryptographically Verified) منتشر شده بودند — یعنی از منظر سیستم‌های اعتبارسنجی خودکار، این بسته‌ها کاملاً قانونی و قابل‌اعتماد به نظر می‌رسیدند. کد مخرب داخل این بسته‌ها به‌گونه‌ای طراحی شده بود که تنها در شرایط خاصی — از جمله زمانی که یک عامل کدنویسی هوش مصنوعی محتوای بسته را برای تحلیل یا اجرا باز می‌کند — فعال می‌شد.

این رویکرد یک تحول نگران‌کننده در تاکتیک مهاجمان زنجیره تأمین (Supply Chain) نشان می‌دهد: به‌جای هدف قرار دادن مستقیم توسعه‌دهنده انسانی که ممکن است کد مشکوک را تشخیص دهد، مهاجمان اکنون رفتار خودکار و قابل‌پیش‌بینی عاملان هوش مصنوعی را هدف می‌گیرند.

۲. چرا «تأییدشده» دیگر به معنای «امن» نیست

یکی از یافته‌های نگران‌کننده این حادثه، دور زدن مکانیزم‌های تأیید امضای دیجیتال بود که معمولاً به‌عنوان خط دفاعی اصلی در برابر بسته‌های جعلی در نظر گرفته می‌شوند. مهاجمان به‌جای جعل امضا، از حساب‌های توسعه‌دهنده به‌ظاهر قانونی یا آسیب‌پذیری‌های در فرآیند انتشار بسته سوءاستفاده کردند تا کد مخرب را داخل بسته‌های به‌ظاهر معتبر جاسازی کنند.

این یافته اصل بنیادینی از امنیت زنجیره تأمین نرم‌افزار را زیر سؤال می‌برد: اعتبارسنجی رمزنگاری‌شده تضمین می‌کند بسته دستکاری نشده، اما هیچ تضمینی نمی‌دهد که محتوای اصلی بسته از ابتدا عاری از کد مخرب بوده است.

«عصر عامل هوش مصنوعی که همه چیز را باز می‌کند، دقیقاً همان کابوسی است که تیم‌های امنیت زنجیره تأمین از آن می‌ترسیدند. اگر عامل شما بتواند به رمزهای عبور دسترسی داشته باشد، این داستان دقیقاً مدل تهدید شماست.» — از تحلیل‌های پس از حادثه

۳. چرا عاملان کدنویسی هوش مصنوعی هدف جذابی هستند

عاملان کدنویسی هوش مصنوعی معمولاً با سطح دسترسی گسترده‌ای اجرا می‌شوند — دسترسی به فایل‌های محیطی، متغیرهای پیکربندی، و گاهی حتی توکن‌های احراز هویت ذخیره‌شده روی سیستم توسعه‌دهنده. این سطح دسترسی که برای انجام وظایف پیچیده برنامه‌نویسی ضروری است، همزمان یک سطح حمله بسیار وسوسه‌انگیز برای مهاجمان ایجاد می‌کند.

برخلاف یک توسعه‌دهنده انسانی که ممکن است پیش از اجرای یک اسکریپت ناشناس مکث کند، عاملان هوش مصنوعی معمولاً به‌صورت خودکار و بدون تردید محتوای یک بسته را برای تحلیل اجرا می‌کنند — رفتاری که دقیقاً همان چیزی است که این کد مخرب برای فعال‌سازی خود به آن نیاز داشت.

۴. واکنش جامعه امنیت سایبری و مایکروسافت

این حادثه در انجمن‌های امنیتی مانند ردیت (به‌ویژه در انجمن‌های تخصصی امنیت سایبری) و هکرنیوز بازتاب گسترده‌ای داشت. کارشناسان امنیتی بر لزوم بازنگری در فرآیندهای انتشار بسته‌های متن‌باز — از جمله اعمال بررسی‌های امنیتی خودکار عمیق‌تر پیش از انتشار عمومی — تأکید کردند.

این واقعیت که این دومین حادثه مشابه در بازه زمانی کوتاه بود، فشار قابل توجهی بر مایکروسافت و پلتفرم‌های میزبانی بسته وارد کرد تا فرآیندهای اعتبارسنجی خود را تقویت کنند — به‌ویژه با در نظر گرفتن این‌که سرعت رشد استفاده از عاملان کدنویسی هوش مصنوعی، دامنه بالقوه آسیب هر حادثه مشابه در آینده را بزرگ‌تر می‌کند.

۵. چگونه تیم‌های توسعه می‌توانند از خود محافظت کنند

در غیاب یک راه‌حل نهادی کامل، مسئولیت عملی کاهش ریسک اکنون روی دوش تیم‌های توسعه است. اقدامات کلیدی شامل اجرای عاملان کدنویسی هوش مصنوعی در محیط‌های ایزوله (Sandboxed Environments) بدون دسترسی مستقیم به رمزهای عبور تولید، بررسی دستی وابستگی‌های جدید پیش از افزودن به پروژه، و استفاده از ابزارهای اسکن خودکار وابستگی (Dependency Scanning) است که می‌توانند رفتار مشکوک زمان اجرا را — نه فقط امضای استاتیک — شناسایی کنند.

این رویکرد با اصل کلی‌تری در امنیت هوش مصنوعی هم‌راستا است: هر چه یک عامل خودمختارتر عمل کند، اصل کمترین امتیاز (Principle of Least Privilege) اهمیت حیاتی‌تری پیدا می‌کند — زیرا خطای انسانی دیگر تنها نقطه شکست نیست.

مقایسه بردار حمله سنتی و بردار حمله هدفمند برای عاملان AI