npm يسمح بعشرة ناشرين موثوقين ويؤخر الإصدار حتى فحص البرمجيات الخبيثة

أتاحت npm عموماً في 3 سبتمبر 2026 استخدام عدة إعدادات مستقلة للنشر الموثوق عبر OIDC للحزمة الواحدة، وربطت اعتماد الحزم المرحلية باكتمال فحص البرمجيات الخبيثة. وتؤكد تغطية ReleaseBytes للتحديث أن المزايا خرجت كإصدار متاح عموماً، لا كاختبار محدود.

يمكن للحزمة الآن الاحتفاظ بما يصل إلى عشرة ناشرين موثوقين في الوقت نفسه، مع السماح بالنشر المرحلي افتراضياً للإعدادات الجديدة وبقاء النشر المباشر خياراً مستقلاً. وتحدد وثائق npm المحدثة في 3 سبتمبر هذا الحد وسلوك الصلاحيات الجديدة، إضافة إلى مسار الانتقال من رموز النشر طويلة العمر إلى OIDC.

كل ناشر مسار تفويض مستقل

يعالج التغيير القيد السابق الذي كان يحصر الحزمة في إعداد نشر موثوق واحد. تستطيع الفرق الآن فصل مسار الإصدار الثابت عن الإصدارات التجريبية أو المرحلية، أو استخدام مزودي CI/CD مختلفين، من دون دمج العمليات في ملف عمل واحد أو إبقاء رمز كتابة طويل العمر للمسارات الأخرى.

يحمل كل إعداد معاييره الخاصة للمستودع وملف سير العمل والبيئة. وتوضح ملاحظات إصدار GitHub أن عملية النشر أو الإيداع المرحلي تُقبل إذا طابق رمز OIDC الوارد أي إعداد صالح؛ فالإعدادات تراكمية ولا يقيّد أحدها الآخر، كما أن ترتيب تقييمها غير مضمون.

لهذا لا يعمل الإعداد الأكثر تشدداً كسياسة عليا للحزمة. إذا كان مسار الإنتاج مقصوراً على النشر المرحلي، بينما يسمح إعداد آخر مطابق بالنشر المباشر، تظل الصلاحية الأوسع قائمة عبر الإعداد الثاني. الحد الأقصى البالغ عشرة اتصالات يزيد مرونة الفصل، لكنه يفرض تدقيق كل اتصال باعتباره مدخلاً مستقلاً إلى عملية الإصدار.

تشمل البيئات المدعومة حالياً GitHub Actions على مشغلات GitHub، وGitLab CI/CD على المشغلات المشتركة في GitLab.com، وCircleCI السحابي؛ ولا تشمل المشغلات ذاتية الاستضافة. ويتطلب النشر الموثوق npm CLI 11.5.1 أو أحدث وNode.js 22.14.0 أو أحدث، بينما يحتاج أمر النشر المرحلي نفسه إلى npm CLI 11.15.0 أو أحدث.

الفحص يوقف اعتماد النسخة المرحلية لا إنشاءها

يستطيع الناشر الموثوق إرسال الحزمة إلى منطقة staging، لكن النسخة لا تصبح متاحة في السجل العام بمجرد وصولها. يحتاج المشرف إلى مراجعتها واعتمادها بالمصادقة الثنائية، ومع تحديث 3 سبتمبر يبقى زر الاعتماد معطلاً ما دام فحص البرمجيات الخبيثة جارياً، ثم يتاح بعد اكتماله.

هذه هي حدود عبارة «يؤخر الإصدار» في العنوان: التأخير الإلزامي يخص اعتماد الحزمة المرحلية، وليس مدة ثابتة مفروضة على جميع عمليات النشر. لم تحدد npm زمناً أقصى معلناً للفحص، لذلك قد يختلف الانتظار، ولا يمكن اشتقاق موعد مضمون لظهور النسخة من التحديث.

النشر المباشر لم يُلغَ. يستطيع مشرف الحزمة منح إعداد محدد صلاحية تنفيذ npm publish إلى جانب npm stage publish، لكن GitHub توصي بإبقاء الإعدادات في وضع staging فقط لإضافة موافقة بشرية قبل وصول النسخة إلى السجل. كما تعرض صفحة إصدارات الحزمة للمشرفين تاريخ النسخ المرحلية وحالات اعتمادها أو رفضها أو بقائها قيد الانتظار.

المسارات المتعددة توسّع سطح التفويض

يستبدل OIDC رمز الكتابة القابل للاحتفاظ به بهوية قصيرة العمر ومقيدة بسير عمل محدد، لكنه لا يجعل جميع المسارات آمنة تلقائياً. نجاح المهاجم في مطابقة شروط أي اتصال يتيح له استخدام الصلاحيات الممنوحة لذلك الاتصال، حتى لو كانت بقية الإعدادات أشد تقييداً.

ينبغي لذلك أن يشمل نموذج التهديد المستودع المصرح به وملف سير العمل والبيئة والأشخاص القادرين على تعديل كل منها. كما يجب مراجعة خيار النشر المباشر اتصالاً باتصال؛ فإضافته إلى مسار تجريبي أو ثانوي ليست مجرد راحة تشغيلية، بل إزالة لحاجز الموافقة البشرية عن ذلك الطريق.

للإصدارات الثابتة، يقلل إعداد مرتبط ببيئة إنتاج محمية ومقصور على npm stage publish احتمال وصول سير عمل مخترق مباشرة إلى السجل. ويمكن فصل الإصدارات التجريبية في اتصال آخر بمعاييرها الخاصة، مع إبقائها مرحلية أيضاً أو منحها النشر المباشر فقط عندما تقبل الجهة المشرفة هذا التوسع في الصلاحيات صراحة.

ترحيل OIDC من دون قطع خط الإصدار

المسار الذي توصي به وثائق npm يبدأ بإعداد الناشر الموثوق واختباره قبل تقييد الرموز التقليدية. يحافظ ذلك مؤقتاً على طريق الرجوع إذا أخطأ الفريق في اسم المستودع أو ملف سير العمل أو البيئة، وهي حقول لا تتحقق npm من صحتها عند الحفظ وقد لا يظهر خطؤها إلا وقت النشر.

1. إنشاء اتصال OIDC مستقل لكل مسار إصدار مستخدم فعلياً، وتحديد المستودع وسير العمل والبيئة بدقة.
2. اختبار المسار الجديد عبر npm stage publish والتأكد من وصول الحزمة إلى قائمة النسخ المرحلية وإمكان اعتمادها بعد انتهاء الفحص.
3. تحديد الاتصالات التي تحتاج فعلاً إلى npm publish، وإبقاء بقية الاتصالات بصلاحية النشر المرحلي فقط.
4. تفعيل خيار طلب المصادقة الثنائية ومنع الرموز للنشر التقليدي، ثم إلغاء رموز الأتمتة القديمة بعد ثبوت نجاح OIDC.

لا يمكن تعديل حقول اتصال موثوق قائم؛ يتطلب تغييرها حذف الاتصال وإنشاء آخر. كما أن OIDC يغطي npm publish وnpm stage publish، لكنه لا يغطي أوامر عرض الحزمة المرحلية أو اعتمادها أو رفضها، لأنها تتطلب مصادقة تفاعلية. وقد يظل تثبيت التبعيات الخاصة داخل CI محتاجاً إلى رمز قراءة محدود، وهو سبب لا يبرر الاحتفاظ برمز كتابة شامل.

ما بقي خارج التحديث

المؤكد منذ 3 سبتمبر 2026 هو إتاحة الإعدادات المتعددة عموماً، وحد أقصى قدره عشرة اتصالات للحزمة، وتعطيل اعتماد النسخة المرحلية إلى أن ينتهي الفحص. أما الإعدادات السابقة فلا تتغير صلاحياتها تلقائياً، بينما تبدأ الإعدادات المنشأة بعد ذلك التاريخ بالسماح بالنشر المرحلي ويمكن توسيعها اختيارياً إلى النشر المباشر.

لم تنشر npm مدة مضمونة للفحص أو مقياساً يتيح اعتبار اجتيازه ضماناً مطلقاً لخلو الحزمة من البرمجيات الخبيثة. التحديث يضيف بوابة فحص قبل الاعتماد ومساحة أوضح لفصل مسارات الإصدار، لكنه يبقي حماية المستودعات وملفات العمل وبيئات CI جزءاً أساسياً من أمن النشر.