فحص التبعيات وتحليل مكونات البرمجيات
فحص التبعيات وتحليل مكونات البرمجيات
كل تطبيق حديث هو في معظمه كود من طرف ثالث. خدمة Node.js نموذجية تسحب مئات التبعيات غير المباشرة؛ وتطبيق Java Spring Boot يُشحن بالآلاف من ملفات JAR التي لم تطلبها مباشرةً قط. حين ظهرت ثغرة حرجة في إحدى تلك المكتبات — كـ Log4Shell في مكتبة log4j، CVE-2021-44228 — أوقفت أنظمة الإنتاج في شركات حول العالم خلال ساعات من الإفصاح. المؤسسات التي نجت بأقل الأضرار كانت تعرف بالضبط أين تستخدم تلك المكتبة، وتمكنت من إصدار التصحيح في اليوم ذاته. أما من قضى ثلاثة أيام في البحث اليدوي داخل قواعد الكود فقد عاش تجربةً مختلفة تماماً.
تحليل مكونات البرمجيات (SCA) هو انضباط يقوم على حصر مستمر وتحليل وتصحيح المكوّنات مفتوحة المصدر والطرف الثالث التي يعتمد عليها برنامجك. يجيب على أربعة أسئلة بشكل آلي ومدمج مع خط التسليم: ماذا نعتمد؟ ما الثغرات المعروفة في تلك التبعيات؟ هل تراخيصنا تتعارض مع أسلوب توزيعنا للبرمجيات؟ وكم نستغرق في العلاج؟
كيف تعمل قواعد بيانات الثغرات
أدوات SCA لا تكتشف الثغرات — بل تُنسّق. تحلّ شجرة تبعياتك إلى قائمة دقيقة من صيغة package-name@version، ثم تبحث عنها في قواعد بيانات متعددة:
- NVD (قاعدة بيانات الثغرات الوطنية) — تديرها NIST، المصدر الأساسي. كل CVE يصل إليها مع تقييم CVSS ونطاقات الإصدارات المتأثرة.
- OSV (ثغرات المصدر المفتوح) — تديرها Google، أسرع وأكثر قابلية للقراءة آلياً، تغطي PyPI وnpm وMaven وRubyGems وGo modules وغيرها.
- GHSA (قاعدة بيانات الاستشارات الأمنية لـ GitHub) — تغذّي Dependabot مباشرةً. غالباً تحتوي على إشعارات قبل NVD بأيام لأن المطوّرين يُنسّقون الإفصاح مباشرة عبر أدوات GitHub الأمنية.
- Snyk Intel — قاعدة بيانات تجارية مع تحليل إمكانية الاستغلال الفعلية، وتحليل قابلية الوصول، وطلبات المراجعة التصحيحية. مدفوعة لكنها الأعلى دقةً في تقييم مخاطر الاستغلال الحقيقي.
درجة CVSS وحدها مؤشر ضعيف للتصنيف. ثغرة CVSS 9.8 في مكتبة تستخدمها فقط لوظيفة مساعدة بريئة، حيث مسار الكود المعيب غير قابل للوصول، هي أولوية أقل من CVSS 7.0 في مكتبة مصادقة مكشوفة شبكياً. تضيف أدوات SCA التجارية المتقدمة تحليل قابلية الوصول: تتتبع مخطط استدعاء تطبيقك الفعلي وتخبرك إن كانت الدالة المعيبة قابلة للوصول من نقاط دخول تطبيقك.
Dependabot: تحديثات تبعيات آلية على نطاق واسع
يعمل Dependabot من GitHub بنمطين متمايزين كثيراً ما تخلط بينهما الفرق. تنبيهات Dependabot سلبية — تُخطرك حين تحتوي تبعية في فرعك الرئيسي على CVE معروف. تحديثات الأمان في Dependabot نشطة — تفتح تلقائياً طلب مراجعة (PR) بأدنى ترقية لإصدار تعالج الثغرة. تحديثات الإصدار في Dependabot تذهب أبعد: تفتح PRs بجدول منتظم للحفاظ على التبعيات محدّثة بصرف النظر عن CVEs، وهي أفضل استراتيجية طويلة الأمد لأن إبقاء الفجوة صغيرة يجعل كل تحديث منخفض المخاطر.
اضبط Dependabot عبر .github/dependabot.yml في جذر المستودع:
Renovate: قدرة أكبر وتحكم أدق
Renovate (Mend Renovate) هو البديل مفتوح المصدر الذي تفضله معظم المؤسسات الهندسية الكبيرة على Dependabot لمستودعات monorepo المعقدة أو متعددة البيئات. يدعم مدراء حزم أكثر (بما فيها مخططات Helm، ومزوّدي Terraform، وRegex المخصص)، ولديه قواعد auto-merge أكثر ثراءً، ويوفر issue لوحة تبعيات تمنحك نظرة شاملة على جميع التحديثات المعلّقة.
كتلة vulnerabilityAlerts في Renovate بالغة الأهمية: تتجاوز الجدول الزمني العادي وتفتح PRs تصحيح الأمان فوراً، بصرف النظر عن أي حدود للدُفعات أو التزامن. في خط أنابيب مُهيَّأ جيداً، تُدمج هذه PRs تلقائياً بعد نجاح CI، مما يعني أن CVE حرجة يمكن تصحيحها واختبارها ونشرها دون تدخل بشري — في دقائق لا أيام.
تشغيل SCA في CI: Trivy وGrype وSnyk
يتولى Dependabot وRenovate التصحيح. للـتطبيق — حظر البناء عند إدخال ثغرة عالية الخطورة — تحتاج ماسحاً مدمجاً مع CI. ثلاثة أدوات تهيمن على الاستخدام الإنتاجي:
- Trivy (Aqua Security) — مفتوح المصدر، سريع، يمسح حزم نظام التشغيل وتبعيات اللغات وطبقات الحاويات والبنية التحتية كأكواد والـ SBOMs. لا يحتاج إعداداً للبيئات الشائعة.
- Grype (Anchore) — مفتوح المصدر، يتكامل مع Syft لإنشاء SBOM. ممتاز لخطوط أنابيب السياسة كأكواد.
- Snyk — SaaS تجاري بمستوى مجاني، مع تحليل قابلية الوصول وطلبات مراجعة تصحيحية موجّهة للمطوّر. الأفضل لمن لديه ميزانية ويركز على تجربة المطوّر.
ignore-unfixed: true: هذا الخيار يُخفي النتائج التي لا يوجد لها إصدار مُصحَّح. في معظم خطوط الأنابيب الحقيقية هذا صحيح — حظر بناء بسبب CVE غير قابل للإصلاح يُدرّب المطوّرين على تجاهل الماسح. لكن للثغرات CRITICAL التي لا يوجد لها إصلاح بعد، تحتاج لا تزال إلى ضابط تعويضي: قواعد WAF وقت التشغيل، أو تعطيل مسار الكود المعيب، أو قبول المخاطرة وتوثيقها رسمياً. لا تُخفِ أبداً بصمت؛ وثّق دائماً.نظافة ملفات القفل: أساس إعادة الإنتاج
ملفات القفل (package-lock.json، yarn.lock، Pipfile.lock، poetry.lock، go.sum، Gemfile.lock، pom.xml بإصدارات مثبّتة) ليست اختيارية. هي الدفاع الأساسي ضد فئتين من هجمات سلسلة التوريد:
- هجمات ارتباك التبعيات — يُنشر مهاجم حزمة ضارة باسم مطابق لحزمة داخلية على سجل عام. بدون نطاق سجل مُثبَّت، قد يحل مدير الحزم النسخة العامة. ملفات القفل تسجّل URL السجل الدقيق وتجزئة السلامة، مما يجعل الحل محدداً.
- الكتابة المشابهة (Typosquatting) — اسم حزمة ضارة يشبه حزمة شائعة (
lodahsمقابلlodash). ملفات القفل تمنع حل الحزمة الخاطئة بالخطأ بعد اكتمال تثبيت صحيح.
قواعد ملفات القفل الحرجة لخطوط الأنابيب الإنتاجية: احرص دائماً على إيداع ملفات القفل؛ استخدم npm ci (لا npm install) في CI — أمر ci يفشل إن كان ملف القفل غير متزامن مع package.json ولا يعدّله أبداً؛ وتحقق من تجزئات السلامة. ملف قفل Node v2/v3 وgo.sum في Go يضمّنان تجزئات sha512 أو sha256 للأرشيفات المحلولة. إن عُبث بحزمة بعد قفلها، فشل فحص التجزئة وقت التثبيت.
السياسة كأكواد: تطبيق مستوى المخاطر المقبول
أعداد CVEs الخام ليست سياسة. الممارسة الناضجة لـ SCA تُحدد معايير قبول صريحة — عادةً في ملف .trivyignore أو سياسة OPA/Rego — وتعامل الاستثناءات على أنها محدودة زمنياً ومراجعة وخاضعة للتدقيق. كحد أدنى، احظر:
- أي CVE بمستوى CRITICAL مع إصلاح متاح ودرجة CVSS للاستغلال أعلى من 8.0
- التراخيص غير المتوافقة مع نموذج توزيعك (GPL في منتج مغلق المصدر)
- الاعتماد المباشر على حزم تخلى عنها مطوّروها أو أرشفوها
استخدم trivy fs . --format cyclonedx --output sbom.json لإصدار SBOM بصيغة CycloneDX جنباً إلى جنب مع تقرير الثغرات — هذا يُغذّي مباشرةً سير عمل SBOM المُغطَّى في الدرس السابع. حين تنكشف ثغرة zero-day، تتيح لك SBOM المحدّثة البحث في بنيتك التحتية بالكامل في ثوانٍ لا أيام.