تست جهش در AliceLabs ۴۰ مورد از ۴۶ نقص امنیتی نسخه ۱.۷.۰ را شناسایی کرد

اگر زیرساخت امنیتی شما نتواند نقص‌های ایجادشده در کد خودش را شناسایی کند، در واقع یک نقطه ضعف است نه یک حفاظ. AliceLabs با انتشار فهرستی از شکست‌های نسخه ۱.۷.۰ ثابت کرد که تأییدات داخلی در نهایت به بن‌بست می‌رسند و برای امنیت عامل‌های هوش مصنوعی (AI Agents)، باید از لنگرهای خارجی استفاده کرد.

این نسخه در واقع تحقق تعهدی است که پیش‌تر برای نسخه ۱.۴.۰ برنامه‌ریزی شده بود و با عبارت «هر سه نقد وارد است» (all three critiques land) دنبال می‌شد. اما به دلیل پیشرفت‌های حاصل از شواهد interoperability با شخص ثالث در حالی که این کار در صف انتظار بود، این مجموعه به نسخه ۱.۷.۰ (پکیج ۱.۵.۰) ارتقا یافت. اکنون در هر push کد، کل مجموعه تست‌ها از جمله تست جهش تحت حالت --strict در محیط CI اجرا می‌شود.

بسیاری از ابزارهای امنیتی به مجموعه‌ای ثابت از تست‌ها تکیه می‌کنند که توسط توسعه‌دهندگان انتخاب شده‌اند؛ این موضوع باعث ایجاد اثر «حفظ‌کننده» (memorizer effect) می‌شود، یعنی سیستم فقط تست‌هایی را پاس می‌کند که قبلاً دیده است. ادیسون فلورس (Edison Flores)، بنیان‌گذار AliceLabs، معتقد است این رویکرد بسته، حس امنیت کاذبی ایجاد می‌کند. برای حل این مشکل، نسخه جدید از برچسب‌های زمانی استاتیک فاصله گرفته و به رویکرد توزیعی برای پنجره‌های اعتبار روی آورده است.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تکیه بر تست‌های پیش‌بینی‌شده هرگز کافی نیست.

نمونه‌برداری پنجره خصمانه

به نقل از مستندات نسخه ۱.۷.۰، یک مولد جدید به نام generate-accept-vectors.mjs معرفی شده است که کارت‌هایی را برای شکست دادن بررسی‌های انقضا تولید می‌کند. این کارت‌ها از نظر امضا، لنگر و وضعیت فعال بودن صحیح هستند، اما حاوی یک پنجره اعتبار نقض‌شده می‌باشند. توزیع این کارت‌های خصمانه به سه حالت شکست متمایز تقسیم می‌شود:

• صادرشده در آینده (۵۵٪): کارت‌هایی با پنجره‌های اعتبار که به باندهای مرزی تقسیم شده‌اند: ۲+ تا ۷ روز، ۸ تا ۹۰ روز، ۹۱ تا ۷۳۰ روز و ۷۳۱ تا ۱۴۶۰ روز.
• منقضی‌شده (۳۵٪): کارت‌هایی که تاریخ انقضای آن‌ها گذشته است، شامل مرز دقیقی که در آن expires_at == NOW است.
• پنجره خالی (۱۰٪): کارت‌هایی که در آن‌ها تاریخ صدور و انقضا در آینده یکسان است (issued_at == expires_at).

برای جلوگیری از این اتفاق که مولد نتواند نقص خودش را تولید کند، یک «قاعده آینه بسته-شکست» (fail-closed mirror rule) اعمال شده است: در حالت کارت‌های معتبر، نقض پنجره یک خطای FATAL است؛ اما در حالت خصمانه، اگر کارتی در پنجره اعتبار قرار بگیرد، FATAL تلقی می‌شود. علاوه بر این، حالت پذیرش (accept mode) ۲۰٪ از کارت‌ها را برای «امروز» (باند داخل مرز) صادر می‌کند تا خطاهای استفاده از < به‌جای <= یا ساعت‌های عقب‌مانده شناسایی شوند. این کار از طریق یک بررسی متقاطع Sidecar انجام می‌شود که ساعت زمان تولید را پین (ثابت) می‌کند.

تست جهش مکانیکی

تیم توسعه به‌جای تست‌های دستی، از mutate-runner.mjs استفاده کرد تا مجموعه‌ای از عملگرهای تعریف‌شده را روی هر مقایسه در مسیر امتیازدهی (cmp-swap)، هر گارد تک‌خطی (guard-drop)، هر شرط بلوک (branch-negate) و ساعت با تلورانس ۱± روز اعمال کند. این فرآیند «جهش‌یافته‌ها» (mutants) یا نسخه‌هایی از کد با خطاهای عمدی ایجاد می‌کند تا مشخص شود آیا مجموعه تست‌ها آن‌ها را می‌گیرد یا خیر.

طبق گزارش فنی شرکت، طبقه‌بندی این جهش‌ها به‌صورت مکانیکی انجام می‌شود:

• گرفته‌شده (Caught): مجموعه تست با شکست مواجه می‌شود.
• معادل در مجموعه (Equivalent-on-suite): خروجی با کد Exit 0 و خروجی --json کاملاً یکسان است.
• فرار قابل‌مشاهده (Observable-escape): خروجی با کد Exit 0 است، اما محتوای خروجی تغییر کرده است.

از ۴۶ جهش ایجادشده، ۴۰ مورد شناسایی شدند، ۶ مورد معادل بودند و هیچ مورد فراری مشاهده نشد. این روش سوگیری انسانی در «انتخاب دستی» تست‌ها را حذف می‌کند. جالب اینجاست که همین فرآیند، سه آسیب‌پذیری جدید را کشف کرد که سپس وصله شدند:
۱. فلگ --generated در خط فرمان اکنون در صورت عدم تجزیه یا تولید صفر کارت، به‌جای یک اجرای سبزِ بی‌صدا، خطای FATAL می‌دهد.
۲. بررسی‌های Sidecar اکنون با استفاده از sha256 به بایت‌های کارت متصل شده‌اند تا از توافق ردیف‌های نادرست روی expected_verify جلوگیری شود.
۳. پیاده‌سازی شمارنده‌های تکمیل (completion counters) برای بررسی‌های داخلی اصلاح شد.

فهرست بازماندگان

«فهرست بازماندگان» (survivor list) جهش‌های خاصی را شناسایی می‌کند که سیستم نتوانست آن‌ها را بگیرد. یکی از بازماندگان قابل توجه، جهش clock+1d است. این یک سبک‌سنگین کردن (trade-off) عمدی بود؛ تیم محدودیت کف آفست‌های آینده را روی ۲+ روز گذاشت تا مجموعه‌های تولیدشده پس از نیمه‌شب همچنان قابل امتیازدهی باشند. اگر از کارت ۱+ روز استفاده می‌شد، بعد از نیمه‌شب وضعیت آن به «داخل پنجره» تغییر می‌کرد در حالی که Sidecar حقیقت قدیمی را پین کرده بود. شناسایی یک جابجایی ساعت ۱+ روزه، قابلیت جابجایی (portability) هر مجموعه تولیدشده را از بین می‌برد.

بازماندگان دیگر شامل مسیرهای مرده تحت --json و تغییرات صرفاً در پیام‌های خطا و یک جهش مقایسه‌گر JCS بود که ثابت شد نسبت به ترتیب خنثی است. اکنون Runner بررسی‌های خود (دقت بایت، Sidecar و بررسی‌های متقاطع مرحله‌ای) را دقیقاً یک‌بار برای هر ورودی می‌شمارد و هر بررسی حذف‌شده منجر به FATAL می‌شود. تست جهش نشان داد که حتی این تأییدیه شمارش را هم می‌توان نفی کرد.

این یافته یک نکته معماری حیاتی را تقویت می‌کند: بررسی‌های داخلی نمی‌توانند اجرای خودشان را گواهی کنند. تنها راه دستیابی به یکپارچگی مطلق، لنگرگذاری متقاطع خارجی (external cross-anchoring) است؛ یعنی بازنشر همان Digest از منابعی که کنترل مشترکی ندارند؛ قابلیتی که برای نسخه‌های آینده برنامه‌ریزی شده است.

ماتریس عملکرد

اثربخشی پنجره توزیعی در ماتریس Runner مشهود است. برای مثال، یک Runner که فقط رمزنگاری را بررسی می‌کند (crypto-only) و نظارتی بر پنجره اعتبار ندارد، در تست‌های خصمانه نمره ۰ از ۴۰ گرفت. پیش از این، چنین Runnerی ممکن بود با یک برچسب زمانی ثابت در سال ۲۰۳۰ پاس شود، اما اکنون در برابر توزیع متنوع نقض‌های پنجره شکست می‌خورد.

برای توسعه‌دهندگانی که زیرساخت عامل‌های هوش مصنوعی را می‌سازند، این تغییر به معنای گذار از سؤال «آیا تست پاس شد؟» به «آیا می‌توان تست را بدون متوجه شدن سیستم تغییر داد؟» است. معیار موفقیت از نرخ پاس/شکست به گزارش شفافیت بازماندگان شناخته شده تغییر کرده است.

کاربران می‌توانند این ادعاها را با Node نسخه ۱۸ به بالا و بدون نیاز به وابستگی، با اجرای دستورات زیر تأیید کنند:
node vectors/generate-accept-vectors.mjs --mode adversarial --count 40 --seed 7 --out .gen-adv
node score-runner.mjs --generated .gen-adv
node mutate-runner.mjs --generated .gen-adv --out survivors.json

گام بعدی شما

• اگر از تست‌های استاتیک برای امنیت کد استفاده می‌کنید، متدولوژی تست جهش (Mutation Testing) را برای شناسایی نقاط کور بررسی کنید.
• در طراحی سیستم‌های اعتبارسنجی، به‌جای استفاده از یک مقدار ثابت برای تست، از توزیع‌های احتمالی (Distributional Approach) استفاده کنید.
• برای تضمین یکپارچگی، به دنبال پیاده‌سازی لنگرهای خارجی (External Anchors) باشید تا سیستم شما وابسته به خود-تأییدی نباشد.

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