پژوهشی تازه از دانشگاه مریلند یک ایراد مهم در ارزیابی عاملهای هوش مصنوعی برای اصلاح آسیبپذیریها را نشان میدهد: بسیاری از آزمونها فقط میسنجند آیا ورودیای که قبلاً باعث کرش شده بود، بعد از اعمال وصله هنوز همان خطا را ایجاد میکند یا نه. معیار جدید PatchBench تلاش میکند پرسش سختتری را پاسخ دهد: آیا عامل واقعاً علت آسیبپذیری را برطرف کرده و در عین حال رفتار سالم برنامه را حفظ کرده است؟
این مقاله که ۳ سپتامبر در arXiv ثبت شده، ۱۱ عامل را در اصلاح آسیبپذیریهای C و C++ بررسی میکند. به گزارش نویسندگان، اتکا به یک ورودی اثبات مفهوم، نرخ موفقیت را به طور متوسط ۱٫۸۳ برابر بیشتر نشان میدهد. سه عامل برتر در آزمون اولیه بیش از ۹۷ درصد موارد را پشت سر میگذارند، اما با اضافه شدن بررسیهای امنیتی گستردهتر و آزمونهای صحت رفتاری، نتیجه آنها به حدود نیمی از وظایف کاهش مییابد. برای تیم امنیت، همین فاصله از رتبه عامل مهمتر است: متوقف شدن یک کرش لزوماً به معنی رفع آسیبپذیری نیست.
PatchBench تعریف «وصله موفق» را سختگیرانهتر میکند
PatchBench شامل ۲۱۳ وظیفه از ۱۶ دسته CWE و ۳۲ پروژه واقعی است. طراحان آن دو میانبر رایج را هدف گرفتهاند که میتوانند توان عاملها را بیش از واقعیت نشان دهند.
نخست، آسیبپذیریهای تاریخی به نسخههای جدیدتر مخزن منتقل میشوند و کد اطراف محل اصلاح نیز تغییر میکند. هدف این است که مدل نتواند صرفاً وصلهای را که احتمالاً قبلاً در دادههای آموزشی دیده، بازسازی کند. در بررسی جداگانهای روی SEC-bench، نویسندگان برآورد کردهاند حدود ۲۵ درصد وصلههای تولیدشده توسط عاملهای سطح مخزن شباهت زیادی به وصله تاریخی توسعهدهنده دارند. خود مقاله تأکید میکند که این شباهت به تنهایی اثبات نمیکند داده آموزشی آلوده بوده است، اما برای اعتبار یک بنچمارک خطر قابل توجهی محسوب میشود.
دوم، وظایفی انتخاب شدهاند که اصلاح واقعی آنها در تابعی خارج از پشته فراخوانی منتهی به کرش قرار دارد. بنابراین عامل نمیتواند فقط در همان نقطهای که ابزار تشخیص خطا نشان میدهد یک شرط محافظ اضافه کند و با این کار آزمون را پشت سر بگذارد.
ارزیابی نیز چندلایه است. بخش امنیتی با ورودیهای کرشکننده بیشتری که از فازینگ به دست آمدهاند، بررسی میکند آسیبپذیری واقعاً حذف شده باشد. بخش رفتاری نیز ورودیهای سالم، خطاهای جدید ابزارهای حافظه، خروجی برنامه و آزمونهای واحد را با نسخه مرجع مقایسه میکند. وصله فقط زمانی پذیرفته میشود که هم مشکل امنیتی را رفع کند و هم رفتار درست برنامه را خراب نکند.
ناپدید شدن کرش با رفع علت اصلی فرق دارد
مهمترین نتیجه این پژوهش برتری یک عامل خاص نیست، بلکه افت شدید امتیازها هنگام سختتر شدن معیار پذیرش است.
طبق نتایج مقاله، سه عامل برتر با یک ورودی اثبات مفهوم بیش از ۹۷ درصد موفقیت دارند. وقتی چند مسیر امنیتی بررسی میشود، این عدد به ۷۵ تا ۸۲ درصد میرسد و پس از اضافه شدن کنترلهای رفتاری، بهترین نتایج تقریباً به نیمی از مجموعه محدود میشوند. ۶۷ وظیفه نیز توسط هیچیک از ۱۱ عامل حل نشدهاند.
نمونهای که پژوهشگران توضیح میدهند علت این اختلاف را روشن میکند. ممکن است نقص در یک بخش برنامه ایجاد شود، اما اثر آن بعداً در جزء دیگری به شکل کرش ظاهر شود. عامل میتواند در محل کرش یک کنترل اضافه کند و همان ورودی آزمایشی را بیاثر سازد، در حالی که وضعیت نادرست برنامه یا مسیرهای دیگر سوءاستفاده همچنان باقی ماندهاند. در یک آزمون ساده این تغییر «موفق» دیده میشود، اما برای امنیت نرمافزار چنین نتیجهای کافی نیست.
پذیرش وصله باید مستقل از عامل تولیدکننده باشد
جمعبندی عملی Aipolix این است که در فرایندهای خودکار اصلاح آسیبپذیری، تولید وصله و تأیید نهایی آن نباید یک مرحله واحد باشند.
عامل میتواند اصلاح پیشنهادی را بسازد، اما پیش از انتشار باید یک کنترل مستقل دستکم سه سؤال را جواب دهد: آیا وصله فقط همان مسیر گزارششده را میبندد یا مسیرهای مشابه را هم پوشش میدهد؟ آیا رفتار عادی نرمافزار و آزمونهای موجود بدون تغییر ناخواسته باقی ماندهاند؟ و آیا تغییر روی علت اصلی اعمال شده یا فقط محل بروز کرش را پوشانده است؟
این تفکیک، مرز اعتماد در یک خط لوله امنیتی مبتنی بر عامل را عوض میکند. اگر همان عامل وصله را تولید کند و بعد با اجرای دوباره یک ورودی اعلام کند مشکل حل شده، فرایند از نظر ساختاری ضعیف است. فازینگ مستقل، آزمونهای رگرسیون و مقایسه رفتار برنامه باید بخشی از شرط انتشار باشند.
PatchBench یک هشدار دیگر هم درباره بنچمارکها دارد. وقتی آسیبپذیریهای عمومی و قدیمی دوباره استفاده میشوند، امتیاز بالا ممکن است ترکیبی از استدلال واقعی و یادآوری الگوهای وصله قبلی باشد. انتقال آسیبپذیری به زمینهای تازه و تغییر کد اطراف آن این مشکل را به طور کامل حل نمیکند، اما احتمال موفقیت صرفاً از راه بازتولید وصله شناختهشده را کمتر میکند.
نتیجه مهم است، اما بازتولید کامل هنوز ممکن نیست
این مقاله نسخه نخست یک پیشچاپ arXiv است و هنوز یک مطالعه مستقل آن را تکرار نکرده است. آزمایشها نیز روی C و C++ متمرکزند؛ بنابراین نباید نتیجه را بدون شواهد بیشتر به همه زبانها، انواع باگ یا مخزنهای سازمانی تعمیم داد.
یک ناهماهنگی در انتشار نیز وجود دارد. مقاله میگوید کد و بنچمارک در نشانی github.com/ai-sec-lab/PatchBench منتشر شدهاند. Aipolix این نشانی را در ۴ سپتامبر بررسی کرد، اما مخزن با خطای 404 در دسترس نبود و امکان بررسی فایلهای آن وجود نداشت. این موضوع نتایج گزارششده در مقاله را باطل نمیکند، ولی در حال حاضر مانع از آن است که یک پژوهشگر یا تیم فنی بتواند خروجی اعلامشده را از همان نشانی بازبینی و اجرا کند.
بنابراین برداشت درست این نیست که عاملهای هوش مصنوعی نمیتوانند آسیبپذیری را اصلاح کنند. پیام دقیقتر این است که یک آزمون ساده میتواند کیفیت اصلاح را بسیار بیشتر از واقعیت نشان دهد. برای تیمهایی که به سراغ اصلاح خودکار رفتهاند، قاعده عملی روشن است: وصله تولیدشده توسط عامل تا زمانی که بررسی مستقل امنیتی و رفتاری را نگذرانده، فقط یک پیشنهاد است.