وقتی مرحلهٔ Build به Payload تبدیل شد: حملهٔ arrayref دربارهٔ CI در Rust چه می‌گوید؟

در ۲۰ اوت ۲۰۲۶، تیم پاسخ‌گویی امنیتی Rust از یک حملهٔ زنجیرهٔ تأمین کوتاه‌مدت اما مهم در crates.io خبر داد. نسخهٔ مخرب arrayref یعنی 0.3.10 وابستگی‌ای به نام proc-macro1 اضافه کرده بود؛ نامی شبیه به proc-macro2 قانونی و شناخته‌شده. این وابستگی یک build script داشت که هنگام کامپایل، payload مخرب را دانلود می‌کرد.

اهمیت عملی حادثه در همین جزئیات است. لازم نبود برنامه از APIهای arrayref استفاده کند و توسعه‌دهنده هم مجبور نبود نصب‌کننده‌ای ویژه اجرا کند. یک Cargo build یا check معمولی و فرایندهای مشابه می‌توانست وابستگی را کامپایل و build script آن را اجرا کند. تیم Rust گزارش داد که arrayref@0.3.10 در ساعت ۰۷:۱۵ به وقت UTC منتشر و ۸۶ دقیقه بعد حذف شد. همچنین نسخه‌های مخرب internment@0.8.7، append-only-vec@0.1.9 و چند crate دیگر، از جمله proc-macro1 در هر نسخه، شناسایی شدند.

در نتیجه، این حادثه مرحلهٔ build در Cargo را—نه فقط کد زمان اجرا را—در مرکز بررسی امنیتی قرار می‌دهد. Build scriptها بخشی مشروع از زیرساخت Rust هستند: crateها از آن‌ها برای تولید کد، تشخیص پلتفرم، اتصال کتابخانه‌های بومی و آماده‌سازی artifactها استفاده می‌کنند. اما این اسکریپت‌ها با مجوزهای محیط build اجرا می‌شوند. در یک runner مربوط به CI، این مجوزها می‌توانند شامل دسترسی به درخت منبع، credentialهای cache‌شده، متغیرهای محیطی، مواد امضای دیجیتال یا tokenهای ابری باشند.

اولین واکنش باید بررسی جرم‌شناسانهٔ وابستگی‌ها باشد. تیم‌ها باید lockfileها و cacheهای محلی Cargo را برای نسخه‌های فهرست‌شده بررسی کنند، به‌ویژه محیط‌هایی را که در بازهٔ زمانی انتشار، وابستگی‌ها را resolve کرده‌اند. ماشین‌های درگیر باید بالقوه آلوده فرض شوند و پیش از اعتماد دوباره به cache یا credentialهای آن‌ها بررسی شوند. اطلاعیهٔ Rust مشخصاً توصیه می‌کند cache رجیستری محلی برای فایل‌های .crate نام‌برده‌شده بررسی شود.

درس بلندمدت دربارهٔ مرز بازبینی است. تمیز بودن فایل منبع یک کتابخانه تضمین نمی‌کند که فرایند build بی‌خطر است: Cargo manifestها را resolve می‌کند، وابستگی‌ها را دریافت می‌کند، مؤلفه‌های procedural و زمان build را کامپایل می‌کند و در ادامه build scriptهای اعلام‌شده را اجرا می‌کند. CI باید این فرایند را تا حد ممکن قابل مشاهده کند، secretها را از مراحل build غیرقابل‌اعتماد دور نگه دارد و تغییرات lockfile را به‌جای نویز روزمره، قابل بازبینی کند.

این حادثه نشانهٔ شکست تضمین‌های ایمنی حافظه در Rust نیست. حمله، زنجیرهٔ تأمین نرم‌افزار و اختیاری را هدف گرفت که به ابزارهای build داده می‌شود. تیم پاسخ‌گویی امنیتی Rust گمان می‌کند رایانه یا credentialهای انتشار maintainer قانونی به خطر افتاده‌اند، اما مسیر دقیق نفوذ هنوز به‌طور عمومی مشخص نشده است. برای سازندگان Rust، نتیجهٔ عملی محدود اما مهم است: به‌روزرسانی وابستگی‌ها باید به‌عنوان ورودی‌های اجرایی build بازبینی شوند، نه صرفاً کتابخانه‌های منبع.