جيت هاب تفرض المصادقة الثنائية في npm لحماية سلاسل التوريد

مقدمة تحليلية

في خطوة تهدف إلى إعادة رسم خارطة الأمان في بيئة تطوير برمجيات JavaScript، أعلنت منصة GitHub المملوكة لشركة Microsoft عن إطلاق ميزة 'النشر المرحلي' (staged publishing) بشكل رسمي وعام في سجل حزم npm. يأتي هذا التحديث الاستراتيجي في توقيت حرج تشهد فيه الساحة البرمجية موجة غير مسبوقة من هجمات سلاسل التوريد البرمجية (Software Supply Chain Attacks) التي تستهدف مستودعات الأكواد المفتوحة المصدر. من الآن فصاعداً، لن تتاح الحزم البرمجية الجديدة للجمهور فور رفعها برمجياً؛ بل ستتطلب موافقة بشرية صريحة معززة بتحدي المصادقة الثنائية (2FA). يمثل هذا التغيير تحولاً جذرياً في فلسفة النشر التلقائي التي اعتمد عليها المطورون لسنوات عبر منصات التطوير المستمر (CI/CD). فبدلاً من الثقة العمياء في المفاتيح والرموز البرمجية الآلية التي قد تتعرض للاختراق، تفرض الآلية الجديدة خطوة تحقق بشرية تضمن 'إثبات الحضور' (proof of presence) للمطور المسؤول قبل أن تصل الأكواد إلى ملايين الأجهزة حول العالم. يأتي هذا القرار بعد سلسلة من الاختراقات المدوية التي قادتها مجموعات تخريبية متطورة مستغلةً الثغرات في خطوط الإنتاج الآلية. إن الأرقام والبيانات الصادرة عن الجهات الأمنية تؤكد أن سد هذه الثغرة لم يعد خياراً ترفيهياً؛ إذ باتت بيئة npm المستهدف الأول للهجمات نظراً لانتشارها الواسع واعتماد الملايين من تطبيقات الويب والمؤسسات عليها. ومن خلال فرض طبقة أمان إضافية تتطلب التفاعل البشري المباشر، تسعى GitHub إلى كسر حلقة الاختراقات الذاتية والآلية التي تلوث حزم المطورين دون علمهم.

التحليل التقني

تعتمد ميزة 'النشر المرحلي' (staged publishing) على فصل عملية رفع الكود عن إتاحته للمستخدمين بشكل كامل. عندما يقوم المطور بإرسال تحديث برمي جديد، لا يتم توجيهه مباشرة إلى سجل npmjs.com العام، بل يمر بالمراحل والآليات التقنية التالية:

• منطقة الانتظار المؤقتة: يتم رفع الملف البرمجي المضغوط (tarball) مسبق البناء إلى خط انتظار مرحلي (staging queue) مغلق تماماً وغير قابل للتحميل العام.
• تحدي المصادقة الثنائية (2FA): يرسل النظام إشعاراً فورياً للمطور الذي يمتلك صلاحية النشر، حيث يتعين عليه تخطي تحدي 2FA لإعطاء الموافقة النهائية واليدوية على تحرير الحزمة.
• التكامل مع الهويات الموثوقة: يضمن هذا الإجراء حماية تدفقات العمل غير التفاعلية وأنظمة النشر التلقائي عبر OIDC (OpenID Connect)، مما يعني أنه حتى لو نجح المهاجم في تزوير رموز الاتصال الخاصة بالـ CI/CD، فلن يتمكن من إطلاق الحزمة دون تأكيد بشري محمي بـ 2FA.

لكي يتمكن مطورو الحزم من تفعيل واستخدام هذه الآلية الجديدة، وضعت GitHub مجموعة من المعايير والاشتراطات التقنية الصارمة:

• يجب أن يمتلك الحساب صلاحية نشر وتعديل صريحة على الحزمة المعنية (Publish Access).
• يجب أن تكون الحزمة موجودة بالفعل في سجل npm، حيث لا تنطبق ميزة النشر المرحلي على الحزم الجديدة تماماً التي تُنشر لأول مرة.
• تفعيل ميزة المصادقة الثنائية (2FA) بشكل إلزامي على حساب المطور المسؤول.
• تحديث واجهة سطر الأوامر الخاصة بـ npm إلى الإصدار CLI 11.15.0 أو أي إصدار أحدث لتشغيل الأمر البرمجي الجديد npm stage publish من المجلد الرئيسي للمشروع.

بالتوازي مع هذه الميزة، قدمت npm ثلاثة خيارات تحكم جديدة (flags) لضبط مصادر تثبيت الحزم البرمجية لمنع عمليات التثبيت العشوائية أو الخبيثة من خارج السجل الرسمي، وهي تعمل بالتكامل مع الخيار السابق --allow-git:

• --allow-file: للتحكم الصارم في عمليات التثبيت البرمجي التي تتم من خلال مسارات ملفات محلية أو حزم tarballs مخزنة محلياً على الجهاز.
• --allow-remote: لإدارة وتدقيق عمليات التثبيت التي تتم عبر روابط الإنترنت البعيدة، بما في ذلك ملفات tarballs المستضافة عبر بروتوكول HTTPS.
• --allow-directory: لتنظيم وتحديد التثبيت المباشر من المجلدات والمسارات المحلية على نظام التشغيل.

بالإضافة إلى ذلك، تعتمد ميزة النشر المرحلي على تشفير متطور للاتصال بين واجهة سطر الأوامر (CLI) وسجل npmjs.com. فعند استدعاء الأمر npm stage publish، يقوم النظام بإنشاء بصمة رقمية فريدة (hash) للحزمة ومقارنتها بالبصمة التي ستنتج بعد الموافقة النهائية. يمنع هذا التصميم أي محاولات للاعتراض في المنتصف (Man-in-the-Middle) أو استبدال الملفات أثناء وجودها في منطقة الانتظار المؤقتة. كما توفر المنصة لوحة تحكم رسومية للمطورين تتيح لهم استعراض التغييرات البرمجية والملفات المدرجة في ملف tarball قبل الضغط على زر الموافقة وتمرير تحدي الـ 2FA، وهو ما يمنح المطورين فرصة ذهبية لمراجعة الأكواد للتأكد من عدم تسلل أي ملفات تكوين سرية (secrets) أو مفاتيح تشفير خاصة بطريق الخطأ إلى السجل العام.

السياق وتأثير السوق

يأتي هذا التحرك الدفاعي من جانب GitHub لمواجهة هجمة شرسة وممنهجة تستهدف النظم البيئية المفتوحة المصدر. وخلال الأشهر القليلة الماضية، رصد الباحثون الأمنيون قفزة هائلة في هجمات تسميم الحزم وتسلل البرمجيات الخبيثة. وتبرز في هذا السياق مجموعة تسلل إلكتروني تُعرف باسم TeamPCP، والتي نجحت في اختراق مستودعات داخلية تابعة لمنصة GitHub نفسها ونشر حزم ملوثة على نطاق واسع عبر استغلال ملحقات برمجية خبيثة مثل ملحق Nx Console لتطبيق VS Code، مما أدى إلى تسريب أكثر من 3800 مستودع داخلي واختراق أجهزة المطورين الشخصية. إن خطورة هجمات سلاسل التوريد تكمن في قدرتها على التكاثر الذاتي؛ حيث يستغل المهاجمون صلاحيات المطورين المخترقة لرفع إصدارات خبيثة من حزم شهيرة يثق بها ملايين المطورين. وبمجرد تحديث هذه الحزم تلقائياً في المشاريع الأخرى، تنتقل العدوى إلى بيئات عمل جديدة بالكامل. ومن خلال تطبيق نهج 'القائمة البيضاء الصريحة' (explicit-allowlist) عبر أعلام التثبيت الجديدة وميزة النشر المرحلي، تسعى الصناعة إلى إجبار المؤسسات التقنية على التدقيق في كل سطر برمي يدخل إلى خوادمها، مما يحد من الانتشار التلقائي للديدان البرمجية وضمان جفاف منابع الهجمات قبل أن تبدأ بالانتشار. تاريخياً، كانت هجمات سلاسل التوريد تقتصر على محاولات تخمين كلمات المرور أو سرقة رموز الوصول (tokens). لكن المشهد المعقد يظهر تحولاً نحو استهداف بيئة عمل المطور ذاتها (Developer Workstation)؛ حيث تشير التقارير الأمنية إلى أن محطات عمل المطورين أصبحت الحلقة الأضعف والهدف الأسهل للمخترقين. إن الهجمات التي نفذتها مجموعة TeamPCP أثبتت أن امتلاك المهاجم لصلاحيات وصول إلى جهاز المطور يمنحه القدرة على تعديل الأكواد محلياً قبل تشفيرها ورفعها. لذلك، فإن فرض قيود التثبيت الجديدة يمثل جدار حماية داخلي يمنع البرمجيات الخبيثة المزروعة في جهاز المطور من تثبيت حزم ملوثة إضافية دون علمه، مما يمنح مدراء الأنظمة والمسؤولين عن أمن المعلومات في الشركات الكبرى قدرة غير مسبوقة على تطبيق سياسات ثقة صفرية (Zero Trust) داخل بيئة التطوير المحلية.

رؤية Glitch4Techs

في Glitch4Techs، نرى أن فرض ميزة النشر المرحلي والمصادقة الثنائية خطوة تأخرت كثيراً ولكنها ضرورية للغاية لإنقاذ ما يمكن إنقاذه في أمان المصادر المفتوحة. ومع ذلك، يجب ألا ننظر إلى هذه الحلول على أنها رصاصة فضية تقضي على التهديدات تماماً. فالاعتماد على العنصر البشري لمنح الموافقة النهائية يضيف 'نقطة احتكاك' (friction) قد تؤدي إلى إبطاء وتيرة عمليات التطوير السريع وخرق مفاهيم الأتمتة الكاملة التي تتبناها شركات التقنية الكبرى في بيئات الـ DevOps. علاوة على ذلك، فإن استثناء الحزم الجديدة تماماً من النشر المرحلي يمثل ثغرة واضحة قد يستغلها المهاجمون لإنشاء وتمرير حزم وهمية بأسماء مشابهة لحزم شهيرة (Typosquatting) دون الحاجة للمرور ببوابة الموافقة المرحلية في المرة الأولى. كما أن هناك خطراً حقيقياً يتعلق بإرهاق المطورين من كثرة التنبيهات (Notification Fatigue)؛ حيث قد يؤدي تكرار طلبات الموافقة عبر 2FA إلى قيام المطورين بالموافقة السريعة والعمياء دون فحص دقيق لمحتوى الكود الفعلي المرسل، مما يعيدنا إلى المربع الأول. نوصي في Glitch4Techs بضرورة دمج هذه الأدوات مع برمجيات فحص الأكواد التلقائية وجعل محطة العمل الخاصة بالمطور بيئة أمنية مغلقة، لأن اختراق جهاز المطور نفسه سيعني حتماً قدرة المهاجم على تجاوز حتى ميزة النشر المرحلي بكل سهولة.