‏نقطه‌کور بازبینی امنیتی Claude Code

آنتروپیک اخیراً یه افزونهٔ امنیتی جدید برای Claude Code منتشر کرده که موقع تغییر کد، خودکار دنبال آسیب‌پذیری می‌گرده و مکمل اسکیل قدیمی‌تر /security-review هست. نویسندهٔ این مقاله تصمیم گرفت هر دو رو روی یه مجموعهٔ عمدیِ پر از حفرهٔ امنیتی تست کنه تا ببینه ابزار جدید واقعاً پوشش رو بهتر می‌کنه یا نه. هدف اعلام‌شدهٔ افزونهٔ جدید اینه که مشکل سوگیری لنگرانداختن مدل (model anchoring bias) رو حل کنه.

این سوگیری رو با یه مثال انسانی می‌شه فهمید: اگه از نویسندهٔ کد بخوای کد خودشو بازبینی کنه، احتمالاً می‌گه مشکلی نداره، چون خودش نوشته. وقتی Claude کد رو می‌نویسه و تو همون جلسه بازبینی می‌کنه، کل تاریخچهٔ گفتگو و همهٔ تصمیم‌های طراحی تو حافظه‌شه و به جای به‌چالش‌کشیدنشون، فقط تأییدشون می‌کنه. افزونهٔ جدید این رو با اجرای یه جلسهٔ جدا و با حافظهٔ تازه حل می‌کنه؛ ولی نویسنده می‌گه این کار خودش یه محدودیت داره: بازبینی که فقط diff همون نوبت رو می‌بینه، نمی‌تونه دربارهٔ تعامل بین کد قدیمی و اضافه‌های جدید استدلال کنه.

برای تست، نویسنده سه حفره با سختی‌های مختلف کاشت. اولی (F1) یه احراز هویت fail-open بود: لیست کاربران مجاز از یه متغیر محیطی خونده می‌شه و اگه اون متغیر خالی باشه، کل شرط نگهبان رد می‌شه و هر کاربری پذیرفته می‌شه؛ در حالی که حالت درست باید deny-all باشه. دومی (F2) مجوز بیش‌ازحدِ بازِ زیرپروسه بود: به نمونهٔ داخلی Claude اجازهٔ اجرای پایتون بدون محدودیت مسیر داده شده بود. سومی (** F3**) ظریف‌ترین بود: مجوز پایتون به یه مسیر مشخص محدود شده ولی مجوز Write هم باقی مونده، و هیچ‌کدوم به‌تنهایی خطرناک نیستن؛ خطر فقط وقتیه که هر دو با هم باشن.

نتیجهٔ فرضیهٔ اول جالب بود. تو جلسه‌ای که خود کد رو نوشته بود، بازبین صفر آسیب‌پذیری گزارش داد، چون مدل تهدید رو «دسترسی فقط برای کاربران مجاز» فرض کرد و حفرهٔ fail-open اصلاً به چشمش نیومد. ولی جلسهٔ سرد (بدون پیش‌زمینه) همون باگ رو با اطمینان بالا گزارش داد و حتی یه path traversal واقعی رو هم پیدا کرد که نویسنده عمداً نکاشته بود و خود مدل موقع نوشتن ساخته بودش. نویسنده می‌گه این یعنی فرضیهٔ اول تأیید شد: سوگیریِ جلسه واقعاً باعث می‌شه باگ‌ها سرکوب بشن.

یه نکتهٔ جانبیِ مهم هم درآمد: چرا هیچ‌کدوم F2 رو نگرفتن؟ جواب تو مرز اجزای سیستمه. تماس با زیرپروسه تو یه فایل دیده می‌شه ولی اسکیلی که صدا زده می‌شه فایل جداست و بیرون محدودهٔ بازبینیه. تو جلسهٔ سرد، بازبین چون شکل امنِ فراخوانی رو دید (لیستی، بدون shell=True) همون‌جا خیالش راحت شد و دیگه سراغ این نرفت که آیا مجوز پایتون زیادی بازه یا نه. نویسنده می‌گه دیدن یه الگوی امنِ شناخته‌شده، باعث شد مدل زودتر از موعد بررسی رو ببنده.

فرضیهٔ دوم هم تأیید شد. وقتی هر دو مجوز Write و پایتون با هم تو یه diff اومدن، افزونه هر دو رو جدا جدا درست گرفت ولی به‌عنوان یه زنجیره نشناختشون، برای همین F3 زنده موند. وقتی هم Write تو نسخهٔ پایه بود و فقط مجوز پایتونِ محدودشده تو یه diff جدید اضافه شد، افزونه گفت «هیچ آسیب‌پذیری‌ای پیدا نشد»، چون Write بیرون از diff و نامرئی بود. جمع‌بندی نهایی نویسنده اینه که بازبینی کاملاً خودکار جای قضاوت آدم رو نمی‌گیره؛ این ابزارها برد تو رو بیشتر می‌کنن ولی باید بدونی چی رو می‌تونن ببینن و چی رو نه — اعتماد کن، ولی راستی‌آزمایی هم بکن.

نکات کلیدی:

• افزونهٔ امنیتی جدید Claude Code با جلسهٔ جدا و حافظهٔ تازه، سوگیری «لنگرانداختن» رو کم می‌کنه.
• بازبینی تو همون جلسهٔ نوشتن، باگ‌ها رو سرکوب می‌کنه؛ جلسهٔ سرد همونا رو پیدا کرد.
• افزونه چون فقط diff رو می‌بینه، زنجیرهٔ آسیب‌پذیریِ پخش‌شده بین دو تغییر رو از دست می‌ده.
• مرز بین اجزای سیستم باعث می‌شه مجوزهای بیش‌ازحدِ بازِ زیرپروسه از بازبینی جا بمونن.
• راه‌حل ساده‌ست: /security-review رو تو یه جلسهٔ تازه اجرا کن، نه جلسه‌ای که کد رو نوشتی.