عامل AI مایکروسافت ۱۵۵ گزارش معتبر ساخت؛ گلوگاه هنوز اصلاح است

مایکروسافت در گزارش ۷ اکتبر ۲۰۲۶ دربارهٔ FORGE اعلام کرد اعضای این گروه، با کمک عامل‌های هوش مصنوعی، طی سه ماه ۱۵۵ گزارشِ اعتبارسنجی‌شدهٔ داخلی را به ۲۳ پروژهٔ متن‌باز فرستاده‌اند. تا زمان انتشار گزارش، برای ۹۳ مورد از سوی نگه‌داران دریافت یا پذیرش ثبت شده بود. این پاسخ‌ها وضعیت همهٔ گزارش‌ها را روشن نمی‌کنند و به معنی وصله‌شدن آن‌ها نیستند.

بررسی DiggingBeagle میان این گزارش‌های متن‌باز و ۱۴۰ آسیب‌پذیری Windows که پژوهش FORGE از مه تا سپتامبر ۲۰۲۶ به شناسایی آن‌ها کمک کرد تفاوت می‌گذارد؛ ۵۲ مورد از گروه Windows در به‌روزرسانی امنیتی سپتامبر رسیدگی شدند. بنابراین عدد گزارش‌های ارسالی را نمی‌توان به‌جای شمار اصلاحات منتشرشده خواند. نتیجهٔ عملی FORGE افزایش ظرفیت کشف و آماده‌سازی گزارش است، در حالی که بررسی نگه‌دارنده و رساندن اصلاح به نسخهٔ منتشرشده مسیر جداگانه‌ای دارد.

از یافتهٔ عامل تا پاسخ نگه‌دارنده

نخستین مرز میان مسیر مشکوکی است که عامل در کد پیدا می‌کند و گزارشی که گروه پژوهشی حاضر است برای پروژه بفرستد. FORGE برای سامان‌دهی جست‌وجو از سامانهٔ چندمدلی MDASH استفاده می‌کند، اما خروجی جست‌وجو هنوز باید از نظر تکراری‌بودن، دسترس‌پذیری مسیر اجرا و امکان بازتولید رفتار معیوب بررسی شود. ورودی‌ای که خطا را دوباره ایجاد کند و توضیحی که علت آن را نشان دهد، به گزارش ارزش رسیدگی می‌دهد.

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

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

عامل‌ها کدام بخش مسیر را کوتاه می‌کنند؟

عامل‌ها می‌توانند جست‌وجوی مسیرهای مشکوک و تولید شاهد بازتولیدپذیر را در مقیاسی انجام دهند که بررسی دستی همهٔ نامزدها دشوار است. در شرح FORGE، ابزارهای تحلیل کد، بررسی دسترس‌پذیری مسیر اجرا و تولید ورودیِ ایجادکنندهٔ خطا به تبدیل حدس اولیه به یافتهٔ قابل بررسی کمک می‌کنند. وقتی چنین شاهدی همراه گزارش باشد، پژوهشگر و نگه‌دارنده می‌توانند توجه خود را به اثر امنیتی و علت نقص معطوف کنند.

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

مرحلهٔ اصلاح به قضاوتی متفاوت نیاز دارد: مسئولان پروژه باید دامنهٔ اثر را تعیین کنند، تغییر مناسب را بسازند یا بازبینی کنند، آزمایش بازگشت خطا را انجام دهند و انتشار آن را هماهنگ سازند. شیوهٔ افشای محرمانه، محیط ساخت و معیار پذیرش میان پروژه‌ها یکسان نیست. FORGE نیز برای رساندن گزارش به نگه‌داران ناچار بوده شواهد و شیوهٔ ارائه را با روند هر پروژه تطبیق دهد؛ خودکارشدن جست‌وجو این بخش از همکاری را حذف نمی‌کند.

چرا آمار Windows به گزارش‌های متن‌باز اضافه نمی‌شود؟

آمار Windows و آمار پروژه‌های متن‌باز دو محیط و دو مرحلهٔ متفاوت را اندازه می‌گیرند. شناسه‌های CVE مربوط به Windows در چرخهٔ رسیدگی و انتشار امنیتی مایکروسافت قرار گرفته‌اند؛ گزارش‌های متن‌باز به نگه‌داران مستقل با برنامهٔ بررسی و انتشار خودشان سپرده شده‌اند. جمع‌زدن این دو گروه، تصویری از تعداد نقص‌های اصلاح‌شده در یک فرایند واحد به دست نمی‌دهد.

زمان‌بندی نیز معنای عددها را تغییر می‌دهد. گروه‌های ماهانهٔ Windows به اعلام و ارائهٔ به‌روزرسانی مربوط‌اند، نه لزوماً به تاریخ کشف هر نقص یا خروجی یک نوبت پویش. در سوی متن‌باز، فاصلهٔ میان ارسال گزارش، پاسخ نگه‌دارنده، ادغام تغییر و رسیدن آن به نسخهٔ قابل استفاده می‌تواند برای هر پروژه متفاوت باشد. مقایسهٔ صرفِ شناسه‌ها با گزارش‌های ارسالی، این مرحله‌های میانی را پنهان می‌کند.

کدام یافته به وصله رسید؟

در نتایج متن‌باز، یک نمونهٔ مشخص از عبور گزارش به اصلاح وجود دارد: یکی از گزارش‌های Linux که از مسیر هماهنگی Akrites گذشت، به وصله‌ای ادغام‌شده در هسته رسید. Akrites ابتکار بنیاد Linux برای هماهنگی محرمانهٔ اصلاح و افشای آسیب‌پذیری‌های نرم‌افزار متن‌باز مهم است. ادغام در کد بالادستی نتیجه‌ای ملموس است، اما به‌تنهایی زمان انتشار تغییر در همهٔ توزیع‌ها یا نصب‌شدن آن نزد کاربران را مشخص نمی‌کند.

مخزن عمومی Microsoft Security FORGE Lab فهرست ماشین‌خوان شناسه‌های CVE مجازشده برای افشا را به‌صورت مجموعه‌ای تجمعی نگه می‌دارد. این فهرست همهٔ یافته‌های خام عامل یا جدول وضعیت همهٔ گزارش‌های فرستاده‌شده به نگه‌داران نیست. در نتیجه، شمردن رکوردهای آن نرخ تبدیل گزارش به وصله را نشان نمی‌دهد؛ سرنوشت بسیاری از گزارش‌ها باید در روند رسیدگی همان پروژه‌ها روشن شود.

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

بیشتر بخوانید:

• Google گزارش‌های آسیب‌پذیری متن‌باز را بست؛ سیل گزارش‌های خودکار مقصر است
• SPUR مصرف محتوا توسط AI را ثبت می‌کند؛ اما گزارش‌ها هنوز خوداظهاری‌اند
• رونویسی زندهٔ Microsoft رکورد زد؛ اما هنوز برای تولید آماده نیست