مشکل ارزیابی در اصلاح خودکار آسیب‌پذیری‌ها توسط هوش مصنوعی

پژوهشگران دانشگاه نورث‌وسترن (Northwestern University) با آزمایش عامل‌های کدنویسی مبتنی بر هوش مصنوعی بر روی ۱۱۲ باگ امنیتی واقعی، به نتیجه‌ای تکان‌دهنده رسیدند: بسیاری از اصلاحاتی (Patches) که باعث توقف کرش (Crash) برنامه می‌شوند، در تست‌های سخت‌گیرانه‌ای که توسعه‌دهندگان اصلی پروژه برای رفع باگ نوشته‌اند، شکست می‌خورند.

توهم رفع آسیب‌پذیری

در بررسی مدل Claude Opus 4.7، مشخص شد یک‌سوم از اصلاحاتی که توانستند از کرش کردن برنامه جلوگیری کنند، همچنان در تست‌های Maintainers رد شدند. این موضوع یک هشدار جدی برای سازمان‌هایی است که قصد دارند از ابزارهای AI برای Patching خودکار استفاده کنند.

بسیاری از بنچ‌مارک‌های (Benchmarks) فعلی برای ارزیابی اصلاحات امنیتی تنها یک سوال می‌پرسند: «آیا ورودی PoC (اثبات مفهوم) که باعث تحریک باگ می‌شد، هنوز برنامه را کرش می‌دهد؟» اگر پاسخ منفی باشد، ابزار AI موفق شناخته می‌شود. اما مشکل اینجاست که یک Patch می‌تواند صرفاً مسیر رسیدن به کرش را مسدود کند، در حالی که خودِ آسیب‌پذیری همچنان در کد باقی مانده باشد. نویسندگان این تحقیق این نوع اصلاحات را «بدتر از نبود هیچ اصلاحی» می‌نامند، زیرا حس کاذبی از امنیت ایجاد می‌کنند در حالی که مشکل حل نشده است.

جزئیات فنی و متدولوژی

این تیم داده‌های خود را از باگ‌های ۸۴ پروژه متن‌باز (Open-source) نوشته شده به زبان‌های C/C++، Go و Rust جمع‌آوری کردند. آن‌ها تست‌هایی را که توسعه‌دهندگان اصلی در کنار اصلاحات واقعی اضافه کرده بودند، استخراج کرده و اصلاحات پیشنهادی AI را با این تست‌ها سنجیدند.

به عنوان مثال، در یک باگ مربوط به PHP، یک اصلاحیه به روشی منطقی (مشابه روش Maintainers) عمل کرد، اما اصلاحیه دیگر صرفاً هرگاه ورودی‌های غیرمعمول مشاهده می‌کرد، یک خطا (Error) صادر می‌کرد. هر دو روش باعث توقف کرش شدند و در تست‌های عمومی پذیرفته شدند، اما تنها تست‌های تخصصی Maintainers توانستند تفاوت بین «رفع واقعی» و «مسدود کردن سطحی» را تشخیص دهند.

عملکرد مدل‌های Claude

نتایج بررسی سه نسل از مدل‌های Claude نشان داد که جدیدترین مدل در حدود ۹۰٪ موارد توانست جلوی کرش را بگیرد، اما تنها در ۶۱٪ موارد تست‌های Maintainers را پاس کرد. به عبارت دیگر، حتی بهترین مدل مورد آزمایش در حدود ۴۰٪ از باگ‌ها، اصلاحی ارائه داد که از نظر فنی ناقص بود.

چالش‌های ابزارهای Remediation

تیم تحقیقاتی با بررسی ۱۳ بنچ‌مارک و مجموعه داده، دریافت که اکثر آن‌ها نقاط ضعف اساسی در ارزیابی دارند و نمی‌توانند تفاوت بین یک راهکار مهندسی شده و یک راهکار سطحی را تشخیص دهند. برای سازمان‌هایی که در حال ارزیابی ابزارهای AI Remediation هستند، پرسیدن این سوالات حیاتی است:

• آیا ابزار شما تنها توقف کرش (Crash) را معیار موفقیت می‌داند یا تست‌های منطقی (Logic Tests) را نیز بررسی می‌کند؟
• چگونه اطمینان حاصل می‌کنید که Patch ایجاد شده، قابلیت‌های مورد نیاز برنامه را مختل نکرده است؟
• آیا ابزار امکان اجرای تست‌های رگرسیون (Regression Testing) را فراهم می‌کند؟