يُعد اختطاف حزم NPM هجوماً يستهدف سلسلة توريد البرمجيات، حيث يُستغل الثقة في الحزمة لتكون مساراً للهجوم. ولا يحتاج المهاجمون إلى تعديل كود المستودع إذا تمكنوا من السيطرة على الحساب الذي ينشر الحزمة.
وهذا ما يجعل حزم npm الموثوقة هدفاً سهلاً للهجمات. فعندما يتعرض حساب أحد القائمين على الصيانة للاختراق، يصبح كل مشروع يقوم بتثبيت الحزمة المتأثرة عرضة للخطر من خلال عملية التحديث الروتينية للتبعيات. وقد أظهرت حادثة Axios التي وقعت في مارس 2026 كيف يمكن لحساب npm واحد تم اختراقه أن يعرض أكثر من 100 مليون عملية تنزيل أسبوعية للخطر دون إجراء أي تغيير ملحوظ على كود مصدر Axios.
إن فهم كيفية عمل اختطاف حزم npm يساعد فرق الأمن على وضع ضوابط تعالج مسار الهجوم الفعلي، بدلاً من الاكتفاء بمراجعة الملفات المصدرية التي تركز عليها معظم الفرق.
ماذا حدث في هجوم Axios على npm
كان هجوم Axios على npm عبارة عن عملية استيلاء على حساب أحد القائمين على الصيانة، أدت إلى تحويل حزمة موثوقة إلى آلية لنشر البرامج الضارة. فقد اخترق المهاجم حساب npm الخاص بالقائم الرئيسي على صيانة Axios، وقام بتغيير عنوان البريد الإلكتروني المسجل إلى عنوان يخضع لسيطرته، ومنع القائم الشرعي على الصيانة من الوصول إلى الحساب.
كانت العملية مدبرة ومتعمدة. فقد تم نشر حزمة خادعة قبل حوالي 18 ساعة من تفعيل الحمولة الخبيثة، مما أدى إلى إنشاء سجل نشر دون إثارة أي شكوك فورية. ثم، في غضون حوالي 39 دقيقة، نشر المهاجم نسختين خبيثتين: axios 1.14.1 لفرع الإصدارات الحديثة وaxios 0.30.4 لفرع الإصدارات القديمة.
تم استهداف كلا الإصدارين في الوقت نفسه بهدف تحقيق أقصى قدر من الانتشار. وقد زاد هذا الاختيار من احتمالية قيام كل من البيئات الحالية والقديمة بسحب حزمة ضارة من خلال إجراءات التحديث القياسية.
كيف أصبح سطر واحد في ملف package.json نقطة دخول للهجوم
يمكن أن يشكل تغيير واحد في التبعيات الموجودة في ملف package.json مسار الهجوم بأكمله في هجوم يستهدف سلسلة التوريد الخاصة بـ npm. وفي حادثة Axios، لم تكن هناك حاجة لتعديل أي من ملفات مصدر Axios لأن السلوك الخبيث تم إدخاله من خلال تبعيات جديدة.
يتم تنفيذ هذا التبعية من خلال ربط "postinstall" في npm. وبمجرد قيام محطة عمل المطور أو مسار CI/CD أو نظام البناء بتشغيل الأمر "npm install"، يمكن للحزمة الخبيثة الاتصال بخادم يتحكم فيه المهاجم، واسترداد حمولة مخصصة لنظام التشغيل المعني، والبدء في التنفيذ.
تم إعداد الحمولات لنظامي التشغيل macOS وWindows وLinux. وكان الهجوم متعدد المنصات بحكم تصميمه. وبعد تشغيله، قام برنامج التوزيع بإزالة آثاره واستبدل ملف package.json الأصلي بنسخة مزورة، مما جعل عملية الفحص الجنائي اللاحقة أكثر صعوبة.
لماذا لم تكتشف عملية مراجعة الكود التقليدية هجوم Axios
صُممت عملية مراجعة الكود التقليدية لفحص التغييرات التي تطرأ على كود المصدر داخل مستودع الكود، لكن مسار الهجوم هذا لم يكن موجودًا في كود مصدر Axios. ولم يعتمد هجوم Axios على تغييرات مرئية في مستودع الكود، لأن المنطق الخبيث كان موجودًا في تبعيات منفصلة وليس في كود مصدر Axios.
هذا الاختلاف مهم. فالناقد الذي يطلع على تحديث الحزمة لن يرى سوى سطر جديد للتبعية في ملف package.json. أما السلوك الخبيث الفعلي فلم يظهر إلا بعد حل مشكلة التبعية وتثبيتها.
ولهذا السبب يصعب اكتشاف هجمات الحزم الموثوقة من خلال المراجعة القائمة على مقارنة التغييرات وحدها. فمسار الهجوم يقع خارج نطاق ملفات المصدر التي تفحصها معظم الفرق، على الرغم من أن الحزمة تظل تبدو شرعية بما يكفي لتمريرها عبر إجراءات سير العمل الروتينية في عملية التطوير.
لماذا يمتد نطاق الانفجار ليشمل كل ما تلامسه العبوة
نطاق التأثير الناجم عن حزمة npm مخترقة لا يقتصر على الحزمة نفسها. بل يشمل كل ما تتعامل معه هذه الحزمة.
بالنسبة لمعظم المؤسسات، يشمل ذلك مسارات CI/CD ذات الصلاحيات المرتفعة، ونقاط نهاية المطورين المزودة بمفاتيح SSH ورموز السحابة، وخوادم البناء التي تتمتع بحق الوصول للكتابة إلى مستودعات المكونات، وأدوات النشر المتصلة بأنظمة الإنتاج. ولا تحتاج الحزمة الخبيثة إلى البقاء داخل شجرة التبعيات لتسبب الضرر؛ بل يكفيها وجود نقطة تنفيذ واحدة موثوقة.
ولهذا السبب فإن حادثة Axios تتجاوز مجرد مسألة إدارة حزم جافا سكريبت. فاختراق النظام بعد التثبيت يمكن أن يحول عملية تثبيت عادية إلى سرقة بيانات اعتماد، أو انتقال أفقي، أو وصول إلى البنية التحتية التابعة.
نقاط الضعف الهيكلية التي كشفها هجوم «أكسيوس»
كشفت حادثة Axios عن نقاط ضعف هيكلية شائعة في بيئات تطوير البرمجيات الحديثة. وهذه ليست حالات استثنائية نادرة، بل هي افتراضات معتادة في العديد من المؤسسات.
الثقة في هويات مسؤولي صيانة الحزم
غالبًا ما ترتبط ثقة حزمة npm بحساب المسؤول الذي ينشر الحزمة. وإذا تعرض هذا الحساب للسرقة أو التصيد الاحتيالي، فإن المهاجم يكتسب نفس صلاحيات النشر التي يتمتع بها المسؤول الشرعي.
إصدارات التبعيات المتغيرة
تزيد الإصدارات ذات التثبيت المؤقت أو غير الثابت من التعرض للإصدارات الضارة. فقد تدخل نسخة مخترقة تم نشرها حديثًا إلى البيئة تلقائيًا دون الحاجة إلى خطوة موافقة متعمدة.
نصوص برمجية ما بعد التثبيت غير الخاضعة للمراقبة
يمكن لبرامج npm النصية التي تُنفَّذ بعد التثبيت تنفيذ تعليمات برمجية عشوائية باستخدام أذونات عملية التثبيت. ولا تقوم العديد من المؤسسات بفحص البرامج النصية الخاصة بدورة الحياة أو تقييدها قبل تشغيلها.
مسارات CI/CD ذات رؤية محدودة لوقت التشغيل
غالبًا ما تتمتع مسارات CI/CD بامتيازات وصول واسعة النطاق إلى الأنظمة الداخلية والبنية التحتية الخاصة بالبناء وبيئات السحابة. وغالبًا ما يُعتمد على هذه المسارات بشكل افتراضي، ونادرًا ما يتم مراقبة سلوك الحزم الضارة أثناء التثبيت.
نقاط نهاية المطورين خارج نطاق التغطية الأمنية الكاملة
تخزن أجهزة المطورين أصولاً عالية القيمة، بما في ذلك مفاتيح SSH وبيانات اعتماد الخدمات السحابية ورموز التعريف الخاصة بالمؤسسات. كما تُعد نقاط نهاية المطورين أهدافاً شائعة للهجمات، لأنها قد تتمتع بقدر أقل من الرؤية وضوابط أقل أثناء التشغيل مقارنة بأنظمة الإنتاج.
مخازن بيانات الاعتماد التي لا تحتوي على مشغلات للتجديد السريع
غالبًا ما يتحول الهجوم على سلسلة توريد البرمجيات إلى حادثة تسرب لبيانات الاعتماد. ولا تزال العديد من الفرق تفتقر إلى إجراءات عمل موثوقة تسمح بتحديد المعلومات السرية المعرضة للخطر وتغييرها على الفور.
ما هي الإجراءات الأمنية التي كانت ستغير النتيجة
كان من شأن ثلاث فئات من الضوابط الأمنية أن تقلل بشكل كبير من تأثير هجوم Axios. تتناول كل ضابط نقطة مختلفة في سلسلة الهجوم: تنفيذ الحزم، وكشف بيانات الاعتماد، وشفافية التبعيات.
1. فحص البرامج الضارة على مستوى الحزمة قبل التثبيت
يساعد فحص البرامج الضارة على مستوى الحزم في منع التبعيات الخبيثة قبل تنفيذها. وهذا أمر مهم في هجمات npm لأن "hooks" ما بعد التثبيت تعمل أثناء عملية التثبيت، مما لا يترك سوى القليل من الوقت للمراجعة اليدوية بمجرد سحب الحزمة.
يمكن أن يؤدي فحص الحزم والتبعيات ونصوص دورة الحياة قبل التثبيت إلى الكشف عن البرامج الضارة المعروفة والسلوكيات المشبوهة ونقاط الضعف والأسرار المبرمجة بشكل ثابت قبل وصول الحزمة إلى نقطة نهاية المطور أو بيئة التكامل المستمر/التسليم المستمر.
MetaDefender Software Supply Chain هو حل OPSWATلأمن سلسلة توريد البرمجيات للتحقق من صحة مكونات البرمجيات والموردين وخطوط الإنتاج. ويستخدم هذا الحل نظامًا متعدد المحركات للكشف عن التهديدات، بما في ذلك نظام Metascan متعدد المسح الذي يشمل أكثر من 30 محركًا لمكافحة الفيروسات، لفحص الحزم بحثًا عن البرامج الضارة ونقاط الضعف والأسرار المبرمجة قبل دخولها إلى دورة حياة التطوير.
2. الإدارة الاستباقية للأسرار باستخدام مشغلات التناوب
تقلل الإدارة الاستباقية للأسرار من قيمة أي اختراق ناجح. فعندما يتم تحديد حزمة مشبوهة، تحتاج الفرق إلى مسار استجابة يتعامل مع بيانات الاعتماد المحلية ومفاتيح SSH والرموز المميزة وأسرار خطوط الأنابيب على أنها معرضة للخطر، ويقوم بتغييرها بسرعة.
ويساعد الكشف عن الأسرار المضمنة في الكود على تحقيق الهدف نفسه. ففي حين يمكن لحزمة برمجية خبيثة أن تسرق الأسرار من الذاكرة أو القرص، فإن الأسرار المكشوفة الموجودة بالفعل في الكود أو التبعيات تشكل طبقة إضافية من المخاطر يمكن تجنبها.
3. Supply Chain ومراقبة التبعية
تساعد شفافية سلسلة التوريد الفرق على اكتشاف التغييرات غير المتوقعة في الحزم البرمجية قبل أن تتحول هذه التغييرات إلى مشكلات في المراحل اللاحقة. ويحتاج فريق الأمن إلى معرفة الحزم المثبتة، والإصدارات المثبتة، والتبعيات الجديدة التي ظهرت، وأين يتم تشغيل هذه المكونات.
بدون الرصد ومراقبة التبعيات، قد تكون أول علامة على حدوث اختراق هي إساءة استخدام بيانات الاعتماد أو إساءة استخدام البنية التحتية بعد مرور وقت طويل على عملية التثبيت الأصلية.
تعرف على المزيد حولSupply Chain Software
يعتمد أمن سلسلة Software على فحص الحزم قبل تنفيذها، ومراقبة التبعيات الجديدة، والحد من تعرض بيانات الاعتماد للخطر في حالة اختراق إحدى الحزم.
شاهد الندوة عبر الإنترنت حسب الطلب:Supply Chain Software — نقاط الضعف التي يستغلها المهاجمون
الأسئلة المتداولة
ما هو هجوم سلسلة التوريد عبر npm؟
هجوم سلسلة التوريد في npm هو عملية توزيع شفرة خبيثة عبر منظومة npm أثناء الأنشطة العادية لتطوير البرمجيات. وعادةً ما يحقق المهاجمون ذلك عن طريق اختراق حساب أحد القائمين على الصيانة، أو نشر حزمة خادعة، أو إدخال سلوك خبيث في التبعيات التي يقوم المطورون وأنظمة التكامل المستمر/التسليم المستمر (CI/CD) بتثبيتها تلقائيًا.
كيف تمكن المهاجمون من اختراق حزمة Axios على npm؟
اخترق المهاجمون حساب npm الخاص بالمسؤول الرئيسي عن صيانة مكتبة Axios، واستخدموا صلاحيات النشر تلك لإصدار إصدارات ضارة عبر فروع الإصدارات 1.x و0.x على حد سواء. كما قام المهاجمون بتغيير عنوان البريد الإلكتروني للحساب إلى عنوان يخضع لسيطرتهم، مما ساعدهم في الحفاظ على السيطرة على الحزمة.
ماذا فعلت البرمجية الخبيثة في هجوم «أكسيوس»؟
استخدمت البرمجية الخبيثة في هجوم Axios «خطافًا» (hook) يعمل بعد التثبيت للتنفيذ أثناء عملية تثبيت npm. وقد اتصل هذا الخطاف بخادم يسيطر عليه المهاجم، وقام بتنزيل حصان طروادة للوصول عن بُعد لنظامي macOS أو Windows أو Linux، ثم شغّله، وحاول بعد ذلك محو الآثار عن طريق استبدال بيانات تعريف الحزمة بمحتوى مزور.
لماذا لم تكشف مراجعة الكود عن هجوم سلسلة التوريد الذي تعرضت له شركة Axios؟
لم تكتشف عملية مراجعة الكود هجوم Axios لأن المنطق الخبيث لم يُدرج في كود مصدر Axios. وكان التغيير الظاهر على مستوى المستودع هو إدراج تبعيات في ملف package.json، في حين تم توصيل البرمجية الخبيثة الفعلية عبر حزمة خارجية تقع خارج النطاق المعتاد لمراجعة كود المصدر.
كيف يمكن للمؤسسات اكتشاف حزم npm الضارة قبل تثبيتها؟
يمكن للمؤسسات الكشف عن حزم npm الضارة قبل تثبيتها من خلال فحص محتويات الحزمة، وأشجار التبعيات، ونصوص دورة الحياة قبل تنفيذها. وتجمع الضوابط الفعالة بين فحص البرامج الضارة، وتحليل التبعيات، وتطبيق السياسات، والتكامل مع عمليات التكامل المستمر/التسليم المستمر (CI/CD)، بحيث يمكن حظر الحزم المشبوهة قبل وصولها إلى بيئات المطورين أو بيئات البناء.
هل يمنع تثبيت الإصدارات هجمات سلسلة التوريد التي تستهدف npm؟
يقلل تثبيت الإصدار من التعرض للإصدارات الضارة التي يتم نشرها حديثًا لأنه يحد من عمليات الترقية التلقائية. ولا يقضي تثبيت الإصدار على مخاطر سلسلة التوريد، لأن الإصدار المثبت قد يكون قد تعرض للاختراق بالفعل أو قد تظل هناك حالات أخرى لفشل الثقة. ويحقق تثبيت الإصدار أفضل النتائج عند دمجه مع التحقق من سلامة البيانات وفحص الحزم وضوابط وقت التشغيل.
