تسريب جديد في منظومة npm يضع المطورين أمام خطر مباشر
كشفت تحقيقات أمنية عن حملة خبيثة جديدة استهدفت حزم npm مرتبطة باسم Red Hat Cloud Services، بعدما جرى التلاعب بأكثر من 30 إصدارًا ونشرها داخل منظومة التطوير على نحو يهدف إلى جمع بيانات حساسة من أجهزة المطورين وبيئات التكامل المستمر.
الحادثة لا تبدو مجرد اختراق محدود لحزم برمجية، بل مثال جديد على الطريقة التي تحوّلت بها سلاسل التوريد البرمجية إلى نقطة ضعف مركزية في عالم تطوير البرمجيات الحديث. فبمجرد أن يثق المطورون بحزمة منشورة ضمن مساحة اسم موثوقة، يمكن أن ينتقل التهديد بسرعة إلى الأجهزة المحلية وخوادم البناء ومستودعات الأكواد.
البرمجية ارتبطت بعائلة Shai-Hulud ذاتية الانتشار
يرجح الباحثون أن الحملة تمثل تطورًا أحدث لعائلة برمجية خبيثة تعرف باسم Shai-Hulud، وهي مجموعة من الشيفرات الضارة التي ظهرت مرارًا في هجمات تستهدف منظومة npm. ما يميز هذه العائلة أنها لا تكتفي بجمع البيانات، بل تحاول الانتشار داخل بيئات النشر والتطوير لتوسيع نطاق الوصول والاحتفاظ بموطئ قدم أطول.
وبحسب التحليل الأمني، فإن النسخة المكتشفة دخلت عبر تعديلات غير مصرح بها على حزم منشورة رسميًا، ثم نفذت تعليماتها أثناء التثبيت بصورة تلقائية. هذا السلوك يجعل الخطر أكبر من مجرد ملف ضار داخل مشروع واحد، لأن تأثيره يمتد إلى أي بيئة تعتمد على تلك الحزم أثناء البناء أو النشر.
ما الذي كانت البرمجية تحاول سرقته؟
أظهر الفحص أن الهدف الأساسي للحملة كان الحصول على أكبر قدر ممكن من الأسرار الرقمية، وعلى رأسها رموز المصادقة الخاصة بـnpm، ومتغيرات البيئة، ومفاتيح الوصول السحابية، ومعلومات أخرى غالبًا ما تُخزن على أجهزة المطورين أو داخل منصات CI/CD.
هذا النوع من البيانات بالغ الحساسية، لأنه قد يتيح للمهاجمين تجاوز الحزمة الأولى المخترقة إلى حسابات إضافية ومستودعات خاصة، وربما إلى أدوات النشر نفسها. وفي بيئات التطوير الحديثة، غالبًا ما تمنح هذه الرموز وصولًا مباشرًا إلى أنظمة إنتاجية أو خطوط إصدار تلقائية، ما يضاعف أثر الحادثة.
إخفاء الهجوم داخل عملية النشر
أحد الجوانب اللافتة في هذه الحملة أن المهاجمين لم يكتفوا بزرع شيفرة خبيثة داخل الحزم، بل حاولوا أيضًا جعل الإصدارات تبدو طبيعية وذات سلسلة توريد موثوقة. فقد جرى توظيف سير عمل في GitHub Actions لطلب رموز هوية OIDC وتنفيذ حمولة مشوشة ساعدت في نشر الحزم مع بيانات اعتماد وتوثيق يبدو رسميًا.
هذا الأسلوب مهم لأنه يوضح كيف بات المهاجمون يستغلون آليات الثقة نفسها التي تعتمد عليها الشركات لتسريع النشر والتحقق من سلامة الإصدارات. وعندما تُستخدم آليات التوثيق السلسلي أو إثبات المصدر بطريقة مضللة، يصبح من الصعب تمييز الإصدار الشرعي من الإصدار المصاب قبل وقوع الضرر.
أكثر من مجرد سرقة كلمات مرور
رغم أن جمع بيانات الاعتماد كان الهدف العاجل، فإن مؤشرات الحملة توحي بأن المهاجمين كانوا يخططون أيضًا للاستمرار داخل بيئات التطوير وتوسيع قدرتهم على التحرك. ويعني ذلك أن الهجوم لم يكن مجرد سرقة لحظية، بل محاولة لبناء وصول دائم إلى منظومة أكثر اتساعًا داخل سلسلة التوريد.
كما لاحظ الباحثون أن بعض التعديلات على الشيفرة كانت سطحية أو تجميلية فقط، بينما ظل المنطق الأساسي للبرمجية كما هو تقريبًا. وتشير هذه التفاصيل إلى أن الجهة المنفذة كانت تعتمد على إعادة تدوير أدوات معروفة مع تغييرات محدودة لتفادي الكشف السريع وإرباك عمليات التحليل.
ما الذي يجب أن تفعله الفرق التقنية الآن؟
بالنسبة للمنظمات التي تعتمد على npm في البناء أو النشر، فإن الأولوية تتمثل في التحقق من الحزم التي تم تثبيتها خلال الفترة الزمنية المرتبطة بالحملة، ثم مراجعة ما إذا كانت أي أسرار أو رموز وصول قد تعرضت للكشف. وفي حال وجود احتمال ولو بسيط، ينبغي تدوير هذه الرموز وإصدار بدائل جديدة فورًا.
وينصح الباحثون أيضًا بإلغاء وإعادة إصدار رموز النشر الخاصة بـnpm، وفحص أنشطة المستودعات وسير العمل في GitHub أو أي منصة مشابهة، مع مراجعة سجلات الوصول ومحاولات النشر غير المعتادة. كما أن التحقق من سلامة الإصدارات السابقة أمر أساسي، خصوصًا إذا كانت الحزم قد استُخدمت داخل خطوط إنتاج أو بيئات اختبار حساسة.
دروس أمنية تتجاوز هذه الحادثة
تعكس هذه القضية واقعًا أوسع في أمن البرمجيات: الثقة العمياء في الحزم المفتوحة المصدر لم تعد كافية. فكلما أصبحت سلاسل التوريد أكثر أتمتة، زادت الحاجة إلى ضوابط أدق مثل التحقق متعدد الطبقات، والعزل بين بيئات البناء والإنتاج، والحد من صلاحيات الرموز المستخدمة في النشر.
كما تبرز أهمية مراقبة سلوك الحزم بعد تثبيتها، وليس فقط قبل تنزيلها. فالتهديدات الحديثة قد تتصرف بشكل طبيعي في البداية، ثم تنفذ حمولة خبيثة في لحظة معينة أو داخل خطوة نشر محددة. ولهذا، فإن أمن سلسلة التوريد لم يعد يتعلق بمصدر الحزمة فقط، بل بكل نقطة وصول تمر بها حتى تصل إلى التطبيق النهائي.
وفي الوقت الذي يؤكد فيه الباحثون أن معظم النسخ الضارة أُزيلت أو أُبطلت وقت الكشف، يبقى الخطر الحقيقي في ما إذا كانت أي جهات قد ثبّتتها بالفعل خلال فترة نشاطها. عندها يصبح الحدث متعلقًا بإدارة الأثر والاستجابة للحادثة بقدر ما هو متعلق بمنع انتشار البرمجية من الأساس.