ممكن نظامك يخترق بدون ما تدري!

تخيل إنك مأمّن السيرفر، مقفل منافذ SSH، مفعّل MFA، ومطبّق أفضل ممارسات الحماية.

لكن في يوم من الأيام، تحدّث مكتبة بسيطة تستخدمها في مشروعك، ومن دون ما تنتبه، يدخل كود خبيث إلى بيئة التشغيل!

كيف ممكن يصير هذا؟

هنا ندخل في مفهوم مهم جدًا في الأمن السيبراني اسمه Software Supply Chain Security أو أمن سلسلة توريد البرمجيات.

أولًا، وش المقصود بسلسلة توريد البرمجيات؟

أي نظام تطوره اليوم غالبًا ما تبنيه من الصفر.

تستخدم مكتبات (Libraries)، وحزم (Packages)، وأطر عمل (Frameworks)، وأدوات بناء ونشر (CI/CD).

مثلًا:

• تستخدم npm أو pnpm لمشاريع JavaScript.
• تستخدم Maven أو Gradle لمشاريع Java.
• تستخدم pip لمشاريع Python.
• تستخدم Docker Images لتشغيل خدماتك.

كل مكوّن خارجي تضيفه لمشروعك يعتبر جزءًا من سلسلة توريد البرمجيات.

المشكلة إن أمان نظامك ما يعتمد على الكود اللي كتبته فقط، بل يعتمد أيضًا على كل مكتبة وأداة وخدمة تستخدمها.

كيف ممكن ينخترق نظامك؟

خلنا نتكلم عن ثلاث طرق شائعة:

١. Dependency Confusion

تخيل عندك مكتبة داخلية اسمها techsea-utils تستخدمها داخل شركتك.

المهاجم ينشر مكتبة بنفس الاسم في مستودع عام مثل npm.

إذا كانت إعدادات مدير الحزم عندك غير مضبوطة، ممكن يتم تحميل مكتبة المهاجم بدل المكتبة الداخلية.

والنتيجة؟ كود خبيث يدخل مشروعك من خلال عملية تثبيت عادية، من دون ما أحد يلمس السيرفر مباشرة.

٢. Malicious Package Updates

مو كل مكتبة موثوقة اليوم بتكون موثوقة بكرة.

ممكن يتم اختراق حساب المطور المسؤول عن المكتبة، أو نشر تحديث يحتوي على كود خبيث.

وإذا كانت التحديثات عندك تلقائية ومن دون مراجعة، ممكن ينتقل الكود الخبيث إلى بيئة البناء أو الإنتاج.

وهنا الخطورة، لأنك ممكن تثق بالتحديث لمجرد أنه صادر من مكتبة تستخدمها من سنوات.

٣. CI/CD Pipeline Compromise

حتى لو كان الكود اللي كتبته آمن، هذا ما يعني إن عملية البناء والنشر آمنة.

تخيل إن المهاجم قدر يستغل إعدادات غير آمنة في GitHub Actions أو وصل إلى Secrets داخل Pipeline.

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

يعني ممكن يكون السيرفر محمي بالكامل، لكن الاختراق يبدأ من البيئة اللي تبني وتنشر النظام.

طيب، كيف تحمي نظامك؟

فيه مجموعة إجراءات مهمة تقلل احتمالية هالنوع من الهجمات:

١. Dependency Scanning

افحص المكتبات والاعتماديات بشكل مستمر باستخدام أدوات مثل:

• Dependabot
• OSV-Scanner
• OWASP Dependency-Check

الأدوات هذي تساعدك تكتشف الثغرات الأمنية المعروفة في المكتبات اللي يستخدمها مشروعك.

لكن انتبه، عدم ظهور ثغرات ما يعني بالضرورة إن المكتبة خالية من الأكواد الخبيثة.

٢. Lockfiles

استخدم ملفات تثبيت الإصدارات مثل:

• package-lock.json
• pnpm-lock.yaml
• poetry.lock

هذي الملفات تساعدك تثبّت إصدارات المكتبات والاعتماديات، وتقلل التغييرات غير المتوقعة أثناء التثبيت.

لكنها ما تعتبر بديلًا عن فحص مصدر المكتبات ومراجعة تحديثاتها.

٣. Software Bill of Materials (SBOM)

الـ SBOM هو سجل يوضح المكونات البرمجية والاعتماديات المستخدمة في نظامك.

تخيل اكتشفت ثغرة خطيرة في مكتبة منتشرة، لكن عندك عشرات المشاريع وما تدري أي مشروع يستخدمها!

هنا تجي أهمية SBOM.

بدل ما تفحص كل مشروع يدويًا، تقدر ترجع للسجل وتحدد الأنظمة المتأثرة بشكل أسرع.

ومن الأدوات المستخدمة لإنشائه:

• Syft
• CycloneDX
• Trivy

٤. CI/CD Security

لا تعطِ أدوات البناء والنشر صلاحيات أكثر من احتياجها.

طبّق مبدأ Least Privilege، وافصل بين صلاحيات البناء والاختبار والنشر.

وتأكد من حماية Secrets وعدم إتاحتها لعمليات بناء غير موثوقة.

وإذا كنت تستخدم GitHub Actions، انتبه لصلاحيات GITHUB_TOKEN، وثبّت إصدارات الـ Actions أو معرّفات الـ Commit الموثوقة، وراجع أي Action خارجي قبل استخدامه.

٥. Artifact Signing & Provenance

كيف تتأكد إن النسخة اللي وصلت للإنتاج هي فعلًا النسخة اللي بنيتها واعتمدتها؟

هنا يجي دور التوقيع الرقمي وإثبات مصدر البرمجيات.

من التقنيات المهمة:

• Sigstore: يساعد في توقيع المكونات البرمجية والتحقق من التوقيعات.
• SLSA: إطار عمل لتحسين سلامة سلسلة توريد البرمجيات ورفع مستوى الثقة في عملية البناء.
• Artifact Provenance: معلومات توضح مصدر النسخة والعملية اللي تم بناؤها من خلالها.

الهدف إنك ما تعتمد فقط على اسم الملف أو مصدر التحميل، بل يكون عندك دليل قابل للتحقق على أصل المكوّن وسلامته.

الخلاصة

ممكن تطبّق أقوى إعدادات Firewall، وتستخدم Zero Trust، وتفعّل MFA، وتعزل السيرفرات عن الإنترنت.

ومع ذلك، تظل عندك نقطة ضعف إذا ما كنت تراقب المكتبات والأدوات اللي تدخل في بناء نظامك.

الأمن السيبراني ما يبدأ من السيرفر، ولا ينتهي عنده.

الحماية الفعلية تشمل دورة حياة البرمجيات بالكامل، من أول مكتبة تثبّتها، إلى آخر إصدار تنشره في بيئة الإنتاج.

لأن المهاجم مو لازم يخترق السيرفر مباشرة، أحيانًا يكفيه يخترق شيء أنت تثق فيه.

وهذا بالضبط سبب أهمية Software Supply Chain Security.