# npm تتيح tokens للـ CI تجهّز النسخة ولا تستطيع نشرها دون موافقة بشرية

> **المغزى:** token مسرّب من خط الـ CI كان كافيًا لنشر نسخة خبيثة باسم صاحب الحزمة. الخيار الجديد يضع إنسانًا بخاصية 2FA بين التسريب والنشر.

- المصدر: المغزى (https://almaghza.com/a/2026-09-19-npm-stage-only-tokens/)
- التاريخ: 8 ربيع الآخر - 19 سبتمبر 2026 (2026-09-19)
- القسم: أمن سيبراني
- الوسوم: npm، GitHub، هجمات سلسلة التوريد، الأمن السيبراني

أعلنت GitHub في 18 سبتمبر 2026 عن خيار جديد عند إنشاء granular access token على npm، اسمه "Read and write (stage only)". هذا النوع من الـ tokens يستطيع تجهيز نسخة جديدة من الحزمة، لكنه لا يستطيع نشرها.

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

الآلية الجديدة تفصل الخطوتين. يستخدم الـ workflow الأمر npm stage publish لتقديم النسخة، فتبقى معلّقة. ثم يراجعها أحد مشرفي الحزمة ويوافق على إصدارها باستخدام 2FA الخاص به.

والنقطة الجوهرية بحسب الإعلان أن محاولات النشر المباشر بهذا الـ token تُرفض حتى لو كان تجاوز 2FA للأتمتة مفعّلًا. في المقابل، يحتفظ الـ token ببقية صلاحيات الكتابة، مثل إدارة الـ dist-tag ووسم النسخ بأنها مهملة، فلا تخسر الفرق أيًّا من أتمتتها الحالية.

يتطلب الخيار npm CLI بالإصدار 11.15.0 أو أحدث، وNode.js بالإصدار 22.14.0 أو أحدث، مع تفعيل 2FA.

ويذكر الإعلان أن npm تستهدف يناير 2027 لإزالة النشر المباشر عبر الـ tokens التي تتجاوز 2FA بالكامل. أي أن ما يبدو اليوم خيارًا إضافيًا قد يصبح قريبًا الطريقة المعتادة للنشر من الأتمتة، وأن الفرق التي تنشر حزمها من الـ CI ستحتاج إلى مراجعة طريقة نشرها قبل ذلك الموعد.

## المصادر

- [إعلان GitHub الرسمي](https://github.blog/changelog/2026-09-18-stage-only-npm-tokens-for-safer-automation/)
- [توثيق granular access tokens على npm](https://docs.npmjs.com/about-access-tokens)
- [توثيق trusted publishing على npm](https://docs.npmjs.com/trusted-publishers)