npm تتيح أكثر من إعداد trusted publishing للحزمة وتربط الموافقة على النشر بانتهاء فحص البرمجيات الخبيثة
النشر على مرحلتين يضع بابًا بين اختطاف الـ workflow ووصول الحزمة إلى المستخدمين، ومن يستهلك الحزم فقط يستفيد دون أن يفعل شيئًا.
أعلنت GitHub في 3 سبتمبر 2026 ثلاثة تغييرات على آلية trusted publishing في npm، أهمها أن النسخة المرحّلة (staged) لا يمكن الموافقة على نشرها إلا بعد انتهاء فحصها بحثًا عن البرمجيات الخبيثة.
وtrusted publishing طريقة للنشر من الـ CI دون token دائم. فبدل تخزين سر في خط الأتمتة، يثبت الـ workflow هويته لحظة النشر عبر OIDC token مؤقت، مرتبط بالمستودع والـ workflow والبيئة (environment). ولا يوجد سر مخزّن، وبالتالي لا يوجد سر يمكن سرقته.
والتغييرات الجديدة:
- يمكن أن يكون للحزمة الواحدة أكثر من إعداد، فيُفصل نشر النسخة المستقرة عن نسخ الـ prerelease دون العودة إلى الـ tokens الدائمة.
- صار النشر على مرحلتين: يرفع الـ workflow نسخة معلّقة، ويجب أن يوافق عليها شخص.
- والموافقة نفسها مقفلة حتى ينتهي الفحص.
وفي كثير من هجمات سلسلة التوريد الكبيرة على npm، كان النمط واحدًا: اختطاف حساب أو workflow، ثم نشر نسخة خبيثة فورًا تصل إلى آلاف المشاريع قبل أن ينتبه أحد. والنشر على مرحلتين يضع حاجزًا بين اختطاف الـ workflow ووصول الحزمة إلى المستخدمين.
وبالنسبة لمن ينشر حزمًا، يصبح الـ token الدائم في الـ CI الحلقة الأضعف دون مبرر، بعد أن صار البديل يغطي حالات كانت تتطلبه. أما من يستهلك الحزم فقط، فيستفيد من هذه الحماية دون أي تغيير من جانبه.