انتحال أسماء الحزم في سجلات الحزم هو ممارسة نشر حزم خبيثة بأسماء تمثّل تنويعات إملائية لحزم مشروعة وشائعة، استغلالًا لميل المطورين إلى الخطأ في كتابة أسماء الحزم، أو قبول اقتراح إكمال تلقائي خاطئ، أو النسخ واللصق من وثائق تحتوي على خطأ. وتُصمَّم الحزمة المنتحِلة عادةً لتبدو مشروعة في صفحتها على السجل، فتطابق وصف الحزمة الأصلية وملف التعريف بها بل وواجهة شيفرتها، بينما تنفّذ بصمت وظائف خبيثة: تسريب متغيرات البيئة، أو تثبيت أبواب خلفية، أو إنشاء وصول دائم إلى بيئة المطور.
آلية التعرّض المتعدي هي المخاطر المحددة التي تجعل انتحال أسماء الحزم خطيرًا بوجه خاص. فالمطور الذي يراجع بعناية الحزم التي يثبّتها مباشرة قد يظل يشغّل حزمًا منتحِلة دون أن يعلم، لأن حزمة مشروعة ثبّتها تعتمد على حزمة منتحِلة كانت بدورها مُدرجة في شجرة اعتماديات حزمة موثوقة. فالاعتماديات المتعدية، أي اعتماديات اعتمادياتك، لا تُراجع بالتدقيق نفسه الذي تُراجع به الاعتماديات المباشرة. والحزمة المنتحِلة التي تدسّ نفسها في شجرة اعتماديات حزمة شائعة تصل إلى جميع مستخدمي تلك الحزمة دون أن يختارها أي منهم مباشرة.
مشكلة غياب CVE تضاعف المخاطر. فأدوات الفحص الأمني التي تكشف الثغرات المعروفة بمعرّف CVE لن تشير إلى حزمة منتحِلة، لأن الحزم المنتحِلة ليست ثغرات معروفة بالمعنى التقليدي، بل شيفرة خبيثة ليس لها CVE مُسند، ولا مدخل في NVD، ولا توقيع في قواعد بيانات الثغرات التقليدية. وفحص SCA الذي يوفّر تغطية شاملة للثغرات المعروفة في الحزم المشروعة لا يوفّر أي تغطية للحزم الخبيثة المتنكرة في هيئة حزم مشروعة.
لماذا يهم هذا
يكتسب انتحال أسماء الحزم أهميته لـTPRM لأن منتجات مورّديك البرمجية مبنية على أشجار اعتماديات قد تتضمن حزمًا منتحِلة دون علم المورّد، لأن الحزمة المنتحِلة كانت اعتمادية متعدية، ولأنها لم يكن لها CVE، ولأن فحوص SCA لديهم لا تكشف الحزم الخبيثة بحكم تعريفها. وSBOM التي تسرد جميع المكونات لا تميّز الحزم المشروعة من المنتحِلة، إذ تظهر حزمة منتحِلة مثل «lodash-utils» في SBOM إلى جانب الحزم المشروعة.
- الحزم المنتحِلة ليس لها CVE، وفحوص الثغرات عبر SCA لا تكشفها
- عدم مراجعة الاعتماديات المتعدية بالتدقيق نفسه المطبَّق على المباشرة
- تتضمن SBOM حزمًا منتحِلة، والجرد لا يميّز الخبيث من المشروع
- غياب تقييم مشروعية الحزم عن مراجعة الاعتماديات
- عدم تطبيق رصد السجلات للتنويعات في أسماء الحزم
كيف تبدو الممارسة الجيدة
تطبّق برامج الدفاع الناضجة ضد انتحال أسماء الحزم فحوصًا لمشروعية الحزم إلى جانب فحص الثغرات، فتتحقق من عمر الحزمة وسجل تنزيلاتها وسمعة القائمين على صيانتها، وتراجع شيفرة الاعتماديات المضافة حديثًا، وترصد الحزم الجديدة ذات الأسماء المشابهة للاعتماديات الداخلية والخارجية الشائعة الاستخدام.
- فحوص مشروعية الحزم: العمر، وعدد التنزيلات، وسمعة القائمين على صيانة الحزم الجديدة
- عملية مراجعة الاعتماديات الجديدة: مراجعة بشرية للحزم المضافة حديثًا
- رصد السجلات بحثًا عن تنويعات منتحِلة للحزم الشائعة الاستخدام
- تثبيت إصدارات الاعتماديات: تحديد الإصدار بدقة لمنع استبدال الحزم بشكل غير متوقع
- التحقق من الحزم وقت البناء: التحقق من قيم التجزئة لجميع الحزم المحلولة
الأدوات
أمن الحزم: Socket.dev لكشف الحزم الخبيثة في الوقت الفعلي؛ وSnyk لتقييم مخاطر سلسلة التوريد
يوفّر Socket.dev فحصًا عميقًا للحزم يتجاوز فحص CVE، فيحلل شيفرة الحزم بحثًا عن سلوك خبيث، ويكشف أنماط انتحال الأسماء، ويقيّم مؤشرات مشروعية الحزم مثل سمعة القائمين على الصيانة وتطور الشيفرة. وبالنسبة إلى ممارسي TPRM، فإن السؤال عمّا إذا كان المورّدون يستخدمون Socket أو أدوات مكافئة تكشف الحزم الخبيثة بما يتجاوز فحص CVE يمثّل سؤالًا محددًا عن الدفاع ضد انتحال أسماء الحزم.
تحديات الحوكمة
يتمثل تحدي الحوكمة في انتحال أسماء الحزم في ضخامة منظومة الاعتماديات. فقد يكون لمشروع برمجي حديث مئات الاعتماديات المباشرة وآلاف الاعتماديات المتعدية، ومراجعتها جميعًا يدويًا أمر غير ممكن. ويكمن حل الحوكمة في أدوات آلية تقيّم الحزم وفق مؤشرات المشروعية وتحيل الحالات الشاذة إلى المراجعة البشرية، مقرونةً بتثبيت إصدارات الاعتماديات الذي يمنع التغييرات غير المتوقعة في الحزم بين عمليات البناء.
- نشر socket.dev أو ما يعادله لكشف الحزم الخبيثة بما يتجاوز CVE
- تطبيق تثبيت إصدارات الاعتماديات: إنفاذ ملفات القفل لمنع انجراف الإصدارات
- مراجعة الاعتماديات المباشرة الجديدة قبل إضافتها إلى بيئة الإنتاج
- رصد التنويعات المنتحِلة للحزم الشائعة الاستخدام
- إدراج كشف الحزم الخبيثة في تقييم أمن البناء لدى المورّد
إذا كنت فريقًا صغيرًا
فعّل Socket.dev أو إجراء مراجعة الاعتماديات في GitHub لمستودعات بيئة الإنتاج لديك. تحلل هذه الأدوات مؤشرات مشروعية الحزم، كتغييرات الشيفرة وسلوك القائمين على الصيانة ونصوص التثبيت، وتشير إلى الحزم ذات الخصائص المريبة. شغّلها على شجرة اعتمادياتك الحالية وراجع الحزم التي تشير إليها. فالحزم التي يعدّها Socket مريبة هي تلك التي لن يكشفها أبدًا فحص قائم على CVE.
- تفعيل Socket.dev أو مراجعة الاعتماديات في GitHub لمستودعات بيئة الإنتاج
- مراجعة الحزم التي يشير إليها تحليل المشروعية
- تطبيق إنفاذ ملفات القفل: تثبيت إصدارات الاعتماديات
- إضافة فحوص المشروعية إلى تقييم أمن البناء لدى المورّد
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«إلى جانب فحص CVE، كيف تكشفون الحزم الخبيثة التي ليس لها CVE مُسند، وتحديدًا الحزم المنتحِلة أو غيرها من الحزم الخبيثة في شجرة اعتمادياتكم؟ وهل تستخدمون أدوات تحلل مؤشرات مشروعية الحزم بما يتجاوز قواعد بيانات الثغرات؟»
ما تتوقعه دليلًا
- كشف الحزم الخبيثة بما يتجاوز فحص CVE
- عملية تقييم مشروعية الحزم
- تثبيت التبعيات وفرض ملفات القفل
- نهج مراجعة الاعتماديات المتعدية
ينبغي أن يُسأل المورّد الذي يؤكد فحص الثغرات عبر SCA عن كشف الحزم الخبيثة. فـSCA يفحص الثغرات المعروفة، والحزم المنتحِلة ليست ثغرات معروفة، بل شيفرة خبيثة ليس لها CVE. أدوات مختلفة، ونموذج تهديد مختلف.
كيف تُثبت ذلك
- تنفيذ أدوات التحقق من مشروعية الحزم
- تنفيذ تثبيت إصدارات الاعتماديات
- سجلات عملية مراجعة الحزم الجديدة
- القدرة على كشف الحزم الخبيثة
الخلاصة الرئيسية
lodash: مشروعة، 47 مليون تنزيل أسبوعيًا. lodash-utils: منتحِلة، 43,000 تنزيل، سبعة أشهر على npm، 312 عملية نشر في بيئات الإنتاج لدى مؤسسات لم تثبّتها مباشرة قط. لا CVE. لا تنبيه من SCA. مجرد شيفرة جرى تشغيلها. الحزم المنتحِلة ليست مدخلات في قواعد بيانات الثغرات، بل شيفرة خبيثة تبدو كحزم مشروعة. ففحص CVE يكشف الثغرات المعروفة في الحزم المشروعة، لكنه لا يوفّر أي تغطية للحزم الخبيثة. وأدوات تحليل المشروعية، مثل Socket.dev وتحليل سلوك الحزم، توفّر التغطية المكمّلة لنموذج التهديد الذي لا يعالجه فحص CVE.