‏امنیت در عصر هوش مصنوعی: وقتی پچ دیر می‌رسه

بعد از اینکه مقاله قبلی نویسنده درباره مرگ سیاست افشای ۹۰ روزه پخش شد و واکنش زیادی گرفت، یه سری سؤال منطقی مطرح شد: «خب، جایگزینش چیه؟» این مقاله جواب اون سؤاله.

مدل جدید شدت‌بندی آسیب‌پذیری بر اساس تعداد تکرار گزارش

ایده اصلی اینه که اگه چند محقق مستقل همزمان یه باگ رو پیدا کردن، احتمال اینکه یه بازیگر مخرب هم اون رو داشته باشه خیلی بالاست. پس شدت باگ باید بر این اساس تنظیم بشه:

• یه گزارش، بدون اکسپلویت: شدت عادی، پنجره زمانی استاندارد
• دو یا چند گزارش مستقل از یه باگ: شدت بالاتر، پنجره کوتاه‌تر
• اکسپلویت کارکرد ضمیمه گزارش: بحرانی، پچ باید ظرف روزها آماده بشه
• اکسپلویت + PoC عمومی: P0، توقف همه چیز، پچ الان

لینوس توروالدز هم هفته پیش همین نکته رو در LKML گفت: «اگه باگ رو با ابزار هوش مصنوعی پیدا کردی، احتمالاً یکی دیگه هم پیداش کرده.» تیم Searchlight Cyber با سال‌ها تجربه روی cPanel کار کرد و با ابزار سفارشی Perl باینری رو دیکامپایل کرد — باز هم یه تهدیدگر دو ماه جلوتر بود.

محقق باید پچ بفرسته، نه فقط گزارش

یه گزارش همراه با پچ سریع‌تر بررسی می‌شه و اعتماد می‌سازه. اگه پروژه اوپن‌سورسه، کد رو بخون و یه PR بفرست. حتی یه پچ اشتباه هم به نگهدارنده یه نقطه شروع می‌ده، برگه سفید نه.

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

نویسنده چند لایه دفاعی پیشنهاد می‌ده که مهم‌ترین‌هاشون اینان:

• قطع ترافیک خروجی به‌صورت پیش‌فرض: اگه سرویس exploited بشه ولی نتونه با سرور C2 ارتباط بگیره، اکسپلویت عملاً ناکام می‌مونه. فقط دامنه‌های مشخص و ضروری allowlist بشن.
• معماری ephemeral (موقتی): کانتینرها هر ۱۲ تا ۲۴ ساعت از یه ایمیج تمیز rebuild بشن. بکدوری که مهاجم نوشته، دیشب وقت ری‌استارت پاک شده.
• sandbox کردن runtime: هیچ اپی نباید به‌عنوان root اجرا بشه. با seccomp یا AppArmor می‌شه جلوی system call های خطرناک رو گرفت — وقتی اکسپلویت سعی کنه shell باز کنه، کرنل رد می‌کنه.
• feature flag برای امنیت: هر integration پرریسک رو پشت یه flag بذار. وقتی vendor یه breach اعلام کرد، flag رو خاموش کن. بدون deploy اضطراری.

در مقابل سؤال «پچ سریع چیزها رو خراب می‌کنه»، جواب صادقانه اینه که canary deploy، auto-rollback و blue-green باید قبل از حادثه آماده باشن — نه وقتی آتش گرفته.

نکات کلیدی:

• تعداد گزارش‌های تکراری یه باگ باید مستقیماً روی شدت‌بندی و پنجره پچ تأثیر بذاره
• محققان باید همراه گزارش، پچ پیشنهادی هم بفرستن
• قطع ترافیک خروجی به‌صورت پیش‌فرض یکی از مؤثرترین دفاع‌ها در برابر zero-day هاست
• معماری موقتی (ephemeral) مهاجم رو مجبور می‌کنه هر چرخه دوباره exploit کنه
• sandbox کردن runtime با seccomp/AppArmor جلوی اجرای shell از داخل کانتینر رو می‌گیره
• feature flag های امنیتی بدون نیاز به deploy اضطراری، سرویس‌های آسیب‌پذیر رو خاموش می‌کنن