«نادیده گرفتن وصله‌های حیاتی»؛ پیامد اشتباه در طبقه‌بندی ریسک‌های هوش مصنوعی

تصور کنید یک خطای کوچک در برچسب‌گذاری شدتِ یک آسیب‌پذیری، یک حفره امنیتی بحرانی را مستقیماً به محیط عملیاتی (Production) منتقل کند. برای سنجش این خطر، یک توسعه‌دهنده در ۱۸ آگوست ۲۰۲۶ با استفاده از دسترسی‌های رایگان و گزینه‌های سروری MonkeyCode ثابت کرد که «رایگان بودن» در تریاژ امنیتی لزوماً به معنای «ایمن بودن» نیست. افشای رابطه: این مقاله به عنوان بخشی از فعالیت‌های معرفی محصول MonkeyCode تهیه شده است.

این بررسی در ادامه تحلیل‌های پیشین ما درباره شکست APIهای رایگان در مواجهه با بارهای عملیاتی سنگین صورت گرفته است. برای اکثر برنامه‌نویسان، استفاده از یک مدل رایگان شبیه استفاده از نسخه آزمایشی یک ابزار است؛ برای دمو عالی است، اما هرگز آن را برای نگهبانی از درِ ورودی خانه استخدام نمی‌کنید. در دنیای امنیت، یک «منفی کاذب» (False Negative) بسیار خطرناک‌تر از یک «مثبت کاذب» (False Positive) است؛ زیرا باعث می‌شود وصله‌های امنیتی نادیده گرفته شوند. در واقع، نادیده گرفتن یک ارتقای بحرانی بسیار آسیب‌زاتر از صرف یک بازبینی بیهوده است.

مشکل خلاصه‌سازی توصیه‌های امنیتی

متون توصیه‌های امنیتی ذاتاً آشفته‌اند چون هر سازنده از اصطلاحات متفاوتی استفاده می‌کند. یک شرکت ممکن است ریسکی را «مهم» (important) بنامد و دیگری آن را «متوسط» (moderate) توصیف کند. این چالش در مدیریت ریسک‌های سیستمی ریشه دارد و نشان می‌دهد چرا جایگزینی برچسب‌های مبهم با ردیابی مکانیسمی برای دقت بیشتر ضروری است. در اینجا مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن کتاب‌ها جواب می‌دهد — باید این اصطلاحات متغیر را به یک اقدام واحد و درست تبدیل کند. هدف در اینجا کمال نیست، بلکه ایمنی است.

به نقل از مستندات این پروژه، نویسنده برای اندازه‌گیری این دقت، یک محیط تست (Test Harness) با استفاده از یک فایل JSONL و اسکریپت پایتون طراحی کرد. این سامانه به‌جای استفاده از توصیه‌های زنده، مدل‌ها را روی ۳۰ رکورد بازبینی‌شده انسانی می‌سنجد تا نتایج با تغییر صفحات وب سازندگان و تغییر رفتار مدل‌ها، تکرارپذیر باقی بماند. هر رکورد دو قابلیت خاص را می‌سنجد: استخراج درست نام بسته (Package Name) و تخصیص کلاس شدت درست (کم، متوسط یا بحرانی).

زیرساخت فنی آزمون

این اسکریپت برای سادگی طراحی شده است. برنامه فایل JSONL را می‌خواند و برای هر رکورد یک پاسخ JSON-only درخواست می‌کند و سپس نتیجه را با فیلدهای مورد انتظار مقایسه می‌کند. طبق گزارش فنی، این پیاده‌سازی از پیکربندی .gitlab-ci.yml با ایمیج python:3.12-slim استفاده می‌کند و کتابخانه httpx را برای اجرای eval_advisories.py از طریق یک اندپوینت مدل و توکن به کار می‌گیرد.

پرامپت برای محدود کردن حجم خروجی و اجبار به فرمت خاص، بسیار سخت‌گیرانه نوشته شده است:
PROMPT = """ Return JSON only with keys: package, severity, action. Severity must be one of: low, moderate, critical. Action must be one of: patch, minor, major. Do not include markdown. Advisory: {description} """

الگوهای شکست فنی

این آزمون سه الگوی تکرارشونده از شکست مدل را آشکار کرد:

• عدم تطابق واژگان: مدل با عبارات مبهم مشکل داشت. برای مثال، توصیه‌ای با برچسب «مهم» را «متوسط» طبقه‌بندی کرد، در حالی که کلاس مورد انتظار «بالا» (high) بود. این یک مشکل واژگانی است که با افزایش تعداد توکن‌ها حل نمی‌شود.
• تداخل نام‌ها: مدل برای رکوردی که صراحتاً به libxml2 اشاره داشت، خروجی libxml داد. چون این‌ها دو بسته متفاوت هستند، ابزارهای پایین‌دستی ممکن است وصله را رد کنند یا اصلاح اشتباهی اعمال کنند.
• بریدگی زمینه: توصیفات طولانی باعث می‌شد مدل بخش میانی متن را گم کند. از آنجا که نسخه اصلاحی یا محدوده نسخه‌های آسیب‌پذیر معمولاً در وسط متن قرار دارند، مدل بر اساس جمله اول حدس می‌زد که چه اقدامی لازم است و این رویکرد بسیار خطرناک است.

در یک اجرای محلی، مدل به بازخوانی (Recall) ۰.۹۰ برای تهدیدات بحرانی رسید — چون این موارد معمولاً از عبارات تند و واضح مثل «اجرای کد از راه دور» (remote code execution) استفاده می‌کنند — اما این عدد برای تهدیدات متوسط به ۰.۶۲ سقوط کرد (با دقت (Precision) ۰.۶۰). این موضوع تأیید می‌کند که مدل‌ها اغلب ریسک‌هایی مانند «منع سرویس در شرایط نادر» را به سطح «کم» تنزل می‌دهند و احتمال نادیده گرفتن آپدیت را بالا می‌برند.

این تغییر در متدولوژی تست نشان می‌دهد که مهندسی پرامپت (Prompt Engineering) — هنر سؤال درست پرسیدن، مثل کسی که می‌داند چطور از یک مشاور باتجربه بهترین جواب را بگیرد — به‌تنهایی نمی‌تواند ابهام واژگانی را حل کند. این محدودیت‌ها مشابه مواردی است که در آن عامل‌های کدنویس پیشرفته در مواجهه با آزمون‌های سخت‌افزاری شکست خوردند و نشان دادند که منطق AI هنوز در شرایط بحرانی متزلزل است. برای یک توسعه‌دهنده عملیاتی، این یعنی هوش مصنوعی باید برای پیش‌نویس یادداشت‌ها یا تریاژ اولیه استفاده شود، اما هرگز نباید برای درخواست‌های ادغام (Merge Request) خودکار در سیستم‌های تحت نظارت و رگوله شده به کار رود. اگر ابزار آپدیت شما بدون بازبینی انسانی عمل می‌کند یا اگر به گزارش‌های آماده برای حسابرسی (Audit-ready) نیاز دارید، باید از این رویکرد صرفاً مبتنی بر AI صرف‌نظر کنید. این هشدار به‌ویژه زمانی اهمیت می‌یابد که بازبینی‌های دقیق اما بیش از حد توسط AI منجر به چرخه‌های بی‌پایان از اصلاحات بی‌ثمر شود.

گام بعدی شما

اگر در حال مدیریت یک درخت وابستگی (Dependency Tree) هستید، این استراتژی را دنبال کنید:

• ابتدا ۱۰ رکورد را به صورت دستی علامت‌گذاری کنید و یک پارسر روی آن‌ها اجرا کنید تا نقاط توهم (Hallucination) مدل را بیابید.
• تماشای ۱۰ خطا درباره محدودیت‌های مدل، بیشتر از ۱۰۰ مورد موفقیت به شما می‌آموزد.
• اگر الگوی شکست مدل پایدار بود، تعداد رکوردها را افزایش دهید؛ در غیر این صورت، ابزار را فعلاً مقیاس نکنید. قبل از اعتماد، اندازه‌گیری کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.