تعمل سجلات الحزم العامة، مثل npm وPyPI وMaven Central وNuGet، وفق نموذج ثقة يخلق ثغرة محددة لا تحظى بالتقدير الكافي في سلسلة التوريد: فبمجرد أن تُعرف حزمة بأنها مشروعة وواسعة الاستخدام، تمتد الثقة المرتبطة بها إلى جميع الإصدارات المستقبلية التي ينشرها أيًا كان من يتحكم في حساب النشر في ذلك الوقت. فالحزمة التي أنشأها مطوّر موثوق في 2019، ونُزّلت ملايين المرات، وتحقق منها آلاف المطورين على مدى سنوات من الاستخدام، يمكن أن تصبح ناقلًا لتوزيع شيفرة خبيثة في 2024 إذا اختُرق الحساب الذي ينشر الإصدارات الجديدة أو نُقل إلى جهة خبيثة.
آلية الاستيلاء على الحسابات هي التهديد الأكثر مباشرة. إذ يمكن اختراق حسابات سجلات الحزم عبر سرقة بيانات الاعتماد أو التصيد الاحتيالي أو الهندسة الاجتماعية التي تستهدف جهة صيانة الحزمة، تمامًا كما يمكن اختراق أي حساب. فقد اختُرق مستودع GitHub الخاص بحزمة event-stream، وهي حزمة npm واسعة الاستخدام، عبر هجوم هندسة اجتماعية نقل فيه المطوّر الأصلي، المثقل بعبء الصيانة، الملكية إلى جهة خبيثة نشرت إصدارًا يتضمن بابًا خلفيًا. ونُزّل الإصدار الخبيث 8 ملايين مرة قبل اكتشاف الهجوم.
ثغرة تعاقب جهات الصيانة هي الخطر الأدق. فحزم المصادر المفتوحة يصونها في كثير من الأحيان مطورون أفراد قد يصبحون غير متاحين، أو يُنهكون، أو يرغبون في نقل مسؤولية الصيانة مع مرور الوقت. وعندما تُنقل حزمة إلى جهة صيانة جديدة، ولا سيما جهة لا تملك سمعة راسخة في مجتمع المصادر المفتوحة، تنتقل الثقة الراسخة في الحزمة إلى شخص لم تخضع شيفرته للتدقيق ذاته الذي أكسب جهة الصيانة الأصلية سمعتها. ويكفي تحديث إصدار واحد من جهة الصيانة الجديدة لإيصال شيفرة خبيثة إلى كل من يثق بالحزمة.
لماذا يهم هذا
يكتسب نموذج الثقة في سجلات الحزم أهميته بالنسبة إلى TPRM لأن منتجات مورديك البرمجية مبنية على حزم لا تتوقف موثوقيتها على مشروعيتها السابقة، بل على الأمن الحالي لحسابات جهات صيانتها. فالمورّد الذي لم يطبّق ضوابط ضد الاستيلاء على الحسابات، ولا يراقب التغيّرات غير المتوقعة في جهات صيانة تبعياته، ولا يتحقق من مشروعية تحديثات الإصدارات الفرعية قبل دمجها، معرّض لاختراق سلسلة التوريد عبر ناقل لا يتناوله فحص الثغرات في SCA.
- التعامل مع مشروعية الحزمة كخاصية ثابتة؛ واختراق جهة الصيانة لا يمكن كشفه عبر CVE
- لم يُقيَّم أمن حسابات جهات الصيانة في مراجعة حزم المورّد
- لا تخضع التغيّرات المفاجئة في جهات صيانة التبعيات للمراقبة
- تحديثات الإصدارات الفرعية لا تخضع للمراجعة ذاتها التي تخضع لها التبعيات الرئيسية
- مخاطر سلسلة التوريد الناتجة عن الاستيلاء على الحسابات غير مدرجة في النموذج الأمني للمورّد
كيف تبدو الممارسة الجيدة
تطبّق برامج الثقة الناضجة في سجلات الحزم مراقبة مستمرة لتغيّر جهات الصيانة في التبعيات الحرجة، وتشترط المصادقة متعددة العوامل لحسابات نشر الحزم، وتثبّت التبعيات على إصدارات محددة مع التحقق من قيم التجزئة، وتراجع تغييرات الشيفرة في تحديثات الإصدارات الفرعية قبل دمجها في بيئة الإنتاج.
- تثبيت التبعيات: تحديد الإصدار الدقيق وقيمة التجزئة بما يمنع التحديثات غير المتوقعة
- مراقبة تغيّر جهات الصيانة: تنبيهات عند تغيّر ملكية الحزم الحرجة
- اشتراط MFA لحسابات النشر: حماية الحسابات لدى المورّد
- مراجعة تحديثات الإصدارات الفرعية: مراجعة فروق الشيفرة قبل دمج التحديثات
- فرض ملفات القفل: يمنع حل التبعيات إلى إصدارات غير متوقعة
الأدوات
مراقبة السجلات: Socket.dev لكشف تغيّر جهات الصيانة؛ وSnyk لمراقبة تحديثات التبعيات
يوفر Socket.dev مراقبة آنية لمؤشرات مخاطر سلسلة التوريد في سجلات الحزم، بما في ذلك تغيّرات حسابات جهات الصيانة، وحسابات النشر الجديدة، وتغييرات الشيفرة المريبة في تحديثات الحزم. وبالنسبة إلى ممارسي TPRM، فإن سؤال الموردين عمّا إذا كانوا يراقبون تبعياتهم الحرجة بحثًا عن تغيّر جهات الصيانة باستخدام أدوات مثل Socket.dev يوفر سؤالًا محددًا عن الدفاع ضد الاستيلاء على الحسابات.
أمن نشر الحزم: فرض المصادقة الثنائية في npm؛ واشتراط TOTP للنشر في PyPI
تقلل وسائل حماية النشر في سجلات الحزم، مثل اشتراطات MFA وتدوير رموز النشر وضوابط الوصول، من خطر الاستيلاء على الحسابات. وبالنسبة إلى ممارسي TPRM، فإن سؤال المورّد عمّا إذا كانت حسابات نشر الحزم لديه تستخدم MFA ورموزًا مخصصة للنشر بدلًا من كلمات مرور الحسابات يوفر سؤالًا محددًا عن أمن حسابات جهات الصيانة.
تحديات الحوكمة
يتمثل تحدي الحوكمة في الثقة بسجلات الحزم في مشكلة حجم التبعيات. فقد يتضمن مشروع برمجي حديث آلاف التبعيات غير المباشرة، لكل منها حسابات جهات صيانة خاصة بها. ولا تكون المراقبة المستمرة لتغيّر جهات الصيانة عبر جميع التبعيات ممكنة إلا بأدوات آلية. ويكمن حل الحوكمة في المراقبة المتدرجة: مراقبة شاملة للتبعيات المباشرة والتبعيات غير المباشرة واسعة الاستخدام، وكشف آلي للحالات الشاذة في شجرة التبعيات الأوسع.
- طبّق تثبيت التبعيات وفرض ملفات القفل
- راقب التبعيات المباشرة الحرجة بحثًا عن تغيّر جهات الصيانة
- اشترط MFA لجميع حسابات نشر الحزم: حماية الحسابات لدى المورّد
- راجع تغييرات الشيفرة في تحديثات الإصدارات الفرعية للتبعيات الحرجة
- أدرج أمن حسابات جهات الصيانة في تقييم سلسلة توريد برمجيات المورّد
إذا كنت فريقًا صغيرًا
فعّل فرض ملفات القفل لتطبيقاتك الإنتاجية: استخدم npm ci بدلًا من npm install، أو pip install مع قيم التجزئة في ملف المتطلبات، أو ما يعادل ذلك في منظومة لغتك البرمجية. يمنع ذلك تغيّر إصدارات الحزم بشكل غير متوقع حتى لو اختُرق حساب جهة صيانة ونُشر إصدار جديد. ثم هيّئ Socket.dev أو أداة مراقبة مكافئة لتبعياتك المباشرة لتنبيهك عند تغيّر ملكية جهة الصيانة. يعالج هذان الضابطان أخطر أنماط إخفاق الثقة في السجلات.
- فعّل فرض ملفات القفل للتطبيقات الإنتاجية
- هيّئ مراقبة تغيّر جهات الصيانة للتبعيات المباشرة
- اشترط MFA لجميع حسابات نشر الحزم الداخلية
- راجع تغييرات الشيفرة في تحديثات الإصدارات الفرعية للحزم الحرجة
ما الذي ينبغي اشتراطه
اسأل مباشرةً:
«هل تراقبون تبعياتكم الحرجة بحثًا عن تغيّرات غير متوقعة في جهات الصيانة، وهل تستخدم حسابات نشر الحزم لديكم MFA ورموزًا مخصصة للنشر؟ وكيف تتحققون من سلامة تحديثات الإصدارات الفرعية قبل دمجها في عملية البناء لديكم؟»
ما تتوقعه دليلًا
- تطبيق مراقبة تغيّر جهات الصيانة
- MFA لحسابات نشر الحزم
- تثبيت التبعيات وفرض ملفات القفل
- عملية مراجعة تحديثات الإصدارات الفرعية
المورّد الذي يؤكد إدارة التبعيات لديه ينبغي سؤاله عن أمن حسابات جهات الصيانة ومراقبة تغيّرها. فإدارة التبعيات تغطي الإصدارات المستخدمة. أما أمن حسابات جهات الصيانة فيحدد ما إذا كان يمكن اختراق تلك الإصدارات دون استغلال أي ثغرة.
كيف تُثبت ذلك
- سجلات مراقبة تغيّر جهات الصيانة
- فرض MFA على حسابات النشر
- تطبيق فرض ملفات القفل
- عملية مراجعة تحديثات الإصدارات الفرعية
الخلاصة الرئيسية
الحزمة: مشروعة، ومراجَعة جيدًا، و14,000 تنزيل أسبوعيًا. جهة الصيانة: نقل المطوّر الأصلي الملكية بعد تعرضه للهندسة الاجتماعية. جهة الصيانة الجديدة: نشرت إصلاحًا لخلل يتضمن شيفرة لجمع بيانات الاعتماد. مطوّر المؤسسة: ثبّت الإصدار الجديد، وراجع README، وراجع عدد التنزيلات، وراجع GitHub. لم يراجع سجل جهة الصيانة. ولم يراجع فروق الشيفرة في الإصدار الجديد. حزمة صالحة. جهة صيانة مخترقة. تحديث خبيث. كان فرض ملفات القفل سيمنع الاعتماد التلقائي للإصدار الجديد. وكانت مراقبة تغيّر جهات الصيانة سترصد نقل الملكية. وكان MFA على الحساب الأصلي سيمنع نجاح الهندسة الاجتماعية. ثلاثة ضوابط لنموذج التهديد ذاته.