أمن سلسلة التوريد البرمجية

📚 محتوى دفاعي بحت للمطوّرين.

المشكلة: أنت تثق بكود لم تكتبه

مشروع حديث متوسّط الحجم يعتمد عادة على مئات الحزم غير المباشرة (اعتماديات اعتمادياتك). كل واحدة منها كود ينفَّذ بصلاحيات مشروعك الكاملة وقت التثبيت أو التشغيل — سلسلة التوريد البرمجية هي كل هذه الحلقات، وأي حلقة ضعيفة فيها تعرّض المشروع كاملًا.

مثال معروف كأثر واسع: اختراق SolarWinds (2020) حيث زُرع كود خبيث داخل عملية بناء (build) موثوقة، فوصل تلقائيًّا لأكثر من 18 ألف مؤسّسة عبر تحديث "رسمي" بالكامل.

أشهر أنماط الهجوم

1) Typosquatting (تقليد الاسم)

نشر حزمة باسم قريب جدًّا من حزمة شهيرة (خطأ إملائي شائع)، فيثبّتها مطوّر بالغلط بدل الحزمة الحقيقية:

npm install expres     ← خطأ إملائي بسيط بدل express

الحزمة المزيّفة قد تحتوي كود سرقة أسرار أو باب خلفي، وتعمل بصلاحيات المشروع كاملة فور تثبيتها.

2) Dependency Confusion (خلط الاعتماديات)

عندما تستخدم مؤسّسة حزمة داخلية خاصة بنفس اسمها في السجلّ العام (npm)، يمكن لمهاجم نشر حزمة عامة بنفس الاسم ورقم إصدار أعلى — فتُفضّلها أنظمة البناء المُعدَّة بشكل خاطئ تلقائيًّا على النسخة الداخلية الآمنة.

3) اختراق حساب الصيانة (Maintainer Account Compromise)

مهاجم يستولي على حساب صاحب حزمة شهيرة موثوقة أصلًا (عبر تسريب كلمة مرور أو هندسة اجتماعية)، وينشر إصدارًا خبيثًا تحت اسم الحزمة الحقيقية نفسها — لا حاجة لخداع أحد بالاسم، الثقة موجودة مسبقًا.

الدفاع

ملفّات القفل (Lock Files)

package-lock.json / pnpm-lock.yaml / yarn.lock تثبّت رقم الإصدار الدقيق ومصدره لكل اعتمادية، بدل مدى مرن (^1.2.0). دون ملفّ قفل مُلتزَم به بالمستودع، كل تثبيت قد يجلب إصدارًا مختلفًا دون أن تلاحظ.

✅ التزم بملفّ القفل في Git — لا تضفه لـ .gitignore
✅ ثبّت الحزم دائمًا بأمر يحترم القفل (npm ci بدل npm install في CI)

الفحص الآلي للثغرات

npm audit              # فحص الاعتماديات مقابل قاعدة ثغرات معروفة
npm audit fix          # ترقية تلقائية للإصلاحات المتوافقة

💡 أضِف npm audit (أو ما يعادله بأداة الحزم لديك) كخطوة إلزامية بخط CI — فشل الفحص يوقف الدمج بدل الاكتشاف بعد النشر.

تقليل السطح المهاجَم

• عطّل تشغيل سكربتات ما بعد التثبيت (postinstall) تلقائيًّا لحزم غير موثوقة إن أمكن — أشهر طريق لتنفيذ كود خبيث فور npm install.
• راجع الاعتماديات الجديدة قبل إضافتها: تاريخ آخر تحديث، عدد الصيانين، الشعبية الفعلية — لا الاسم فقط.
• استخدم أداة مراجعة اعتماديات ضمن الـ Pull Request (تُظهر أي ثغرة يدخلها تغيير الإصدارات قبل الدمج).
• لأسماء داخلية: احجز النطاق (scope) نفسه بالسجلّ العام، أو اضبط أنظمة البناء لتفضّل المصدر الداخلي دائمًا صراحة — لا تعتمد على "الرقم الأعلى يفوز" الافتراضي.

قائمة تحقّق سريعة

• ملفّ قفل مُلتزَم بالمستودع، وتثبيت بأمر يحترمه في CI.
• فحص ثغرات آلي بكل عملية دمج، لا يدويًّا بين حين وآخر.
• تحقّق من اسم أي حزمة جديدة حرفيًّا قبل تثبيتها — خطأ إملائي واحد كافٍ.
• تحديث الاعتماديات باستمرار بدل تجميد المشروع على إصدارات قديمة تراكمت ثغراتها.

🎯 التالي: خلاصة المسار.