npm قابلیت انتشار مرحله‌ای (staged publishing) را عمومی کرد تا قبل از در دسترس شدن نسخه‌های جدید بسته‌ها یک مرحلهٔ تأیید انسانی اضافه شود. به‌جای انتشار فوری، tarball به صف مرحله‌ای ارسال می‌شود و پس از پاسخ به چالش احراز هویت دو مرحله‌ای (2FA) توسط یک نگهدارنده، برای انتشار آزاد می‌گردد.

آیین‌کار و پیش‌نیازها

صف مرحله‌ای در npmjs.com و در رابط خط فرمان نمایش داده می‌شود. خودِ فرایند staging برای آپلود به 2FA نیاز ندارد و با هر نوع توکن کار می‌کند؛ بنابراین خطوط CI غیرتعاملی تحت‌تأثیر قرار نمی‌گیرند و اثبات حضور به مرحلهٔ تأیید منتقل می‌شود. پیش‌نیازها: npm CLI نسخهٔ 11.15.0+، Node نسخهٔ 22.14.0+ و وجود قبلی بسته در رجیستری.

npm stage publish       # ارسال نسخه به صف مرحله‌ای
npm stage list          # فهرست نسخه‌های در انتظار تأیید
npm stage view <id>  # بازبینی tarball مرحله‌ای
npm stage approve <id> # ارتقاء به رجیستری (در این مرحله 2FA پرسیده می‌شود)
npm stage reject <id>  # رد یا حذف از صف

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

پیشنهاد شده این قابلیت در کنار انتشار مبتنی بر OIDC به‌کار رود. می‌توان پیکربندی CI را طوری محدود کرد که تنها قادر به ارسال به صف باشد و تلاش برای npm publish مستقیم رد شود. تیم‌هایی که از فرآیندهای انتشار جمعی امن استفاده می‌کنند می‌توانند همین تنظیمات را برای مهاجرت به staged publishing اعمال و سپس فرمان انتشار در CI را به‌روزرسانی کنند.

پرچم‌ها و تغییرات امنیتی دیگر

در نسخهٔ جدید چند پرچم کنترلی افزوده شده: --allow-file، --allow-remote و --allow-directory در کنار --allow-git. هر کدام فقط دو مقدار all یا none می‌پذیرند و از طریق .npmrc یا package.json قابل تنظیم‌اند. نکتهٔ مهم: در نسخهٔ v12 مقدار پیش‌فرض --allow-git روی none قرار می‌گیرد.

واکنش جامعه و نقش در امنیت زنجیرهٔ تأمین

این تغییر در زمینهٔ افزایش حملات زنجیرهٔ تأمین نرم‌افزار رخ داده است. پژوهشگر امنیتی Adnan Khan در یک پست کوتاه نوشت:

هر کسی که بسته در NPM منتشر می‌کند باید همین امروز این ویژگی را فعال کند: از CI از طریق OIDC منتشر کنید و سپس قبل از زنده شدن بسته آن را تأیید نمایید.

در مقابل، برخی منتقدان هشدار داده‌اند که staged publishing ممکن است صرفاً راه‌حلی موقتی باشد و موجب تعویق در ساختن زیرساخت‌های امن‌تر شود؛ با این حال طرفداران معتقدند این مکانیزم می‌تواند تعداد قابل‌توجهی از حملات ناشی از تصاحب CI را خنثی کند.

واکنش رقبا و ابزارهای مکمل

ابزارهای مکمل سریع واکنش نشان دادند: pnpm در نسخهٔ 11.3 دستور مشابه pnpm stage را اضافه کرده، Yarn فرمان yarn npm stage list را در دسترس گذاشته و ابزارهایی مانند release-it گزینهٔ "stage": true را پشتیبانی می‌کنند. علاوه بر این، pnpm به‌صورت پیش‌فرض نصب نسخه‌های بسیار جدید را با تأخیر انجام می‌دهد که دفاع مکملی در برابر انتشار سریع بسته‌های آلوده فراهم می‌کند.

قدم‌های بعدی و توصیه برای تیم‌ها

GitHub قصد دارد توکن‌های دسترسی خردی که از 2FA عبور می‌کنند را به‌صورت پیش‌فرض محدود به حالت «فقط مرحله‌ای» کند و فیلدی به‌نام allowScripts اضافه نماید تا اجرای اسکریپت‌های نصب در v12 به‌صورت opt-in باشد. توصیه‌های عملی برای توسعه‌دهندگان و نگهدارندگان:

  • CLI را به نسخهٔ 11.15.0 یا بالاتر ارتقا و Node را به 22.14.0 یا بالاتر برسانید.
  • CI را برای انتشار از طریق OIDC پیکربندی کرده و ارسال به صف مرحله‌ای را جایگزین انتشار مستقیم کنید.
  • سیاست‌های --allow-* را مرور کرده و حداقل مجوز لازم را اعمال نمایید.

انتشار مرحله‌ای درمان قطعی نیست، ولی یک لایهٔ دفاعی عملی است که می‌تواند سرعت انتشار بسته‌های مخرب در اکوسیستم را کاهش دهد و فرصت بازبینی انسانی فراهم آورد. تیم‌هایی که امنیت زنجیرهٔ تأمین برایشان اولویت دارد بهتر است هر چه زودتر مسیر مهاجرت را برنامه‌ریزی کنند.

منابع: مستندات رسمی npm، راهنمای OIDC در GitHub و بررسی واکنش جامعه در فروم‌ها و پست‌های عمومی.