GitLab 19.0 تطلق فحص التبعيات المستند إلى SBOM للحماية من الثغرات الأمنية

تشكّل البرمجيات الخارجية الجزء الأكبر من قواعد الشيفرة البرمجية، وتُظهر الحوادث الأخيرة في سلسلة التوريد أن حزمة واحدة مخترقة قد تصيب جميع المشاريع التي تعتمد عليها. ويزيد الذكاء الاصطناعي المشكلة تعقيداً، إذ تشير الدراسات إلى أن نحو نصف الشيفرة التي يولّدها الذكاء الاصطناعي تقريباً يحتوي على ثغرات أمنية.

ما الذي تغيّر

كانت أدوات فحص التبعيات التقليدية، ومنها GitLab Gemnasium، تطرح سؤالاً واحداً: أيّ من الحزم المُعلَنة في مشروعي تحمل ثغرات CVE معروفة؟ وحين كانت أشجار التبعيات أقل عمقاً، ودورات الإصدار أبطأ بكثير، كان هذا النهج يؤدي الغرض. أما اليوم فالواقع أكثر تعقيداً.

يتعيّن على فرق أمن التطبيقات الآن الإجابة عن أسئلة أشد تعقيداً بكثير. كيف وصلت الحزمة المعرّضة للثغرات إلى المشروع؟ وما الذي جاء معها كأثر جانبي؟ والأهم: أي التبعيات تستخدمها شيفرتكم فعلاً؟ والأدوات القديمة لا تقدّم إجابات عن هذه الأسئلة.

فحص SBOM في GitLab 19.0

في الإصدار الجديد GitLab 19.0 ينتقل فحص التبعيات المستند إلى SBOM (Software Bill of Materials) إلى مرحلة الإتاحة العامة. ويعني ذلك أن الميزة لم تعد في طور الاختبار التجريبي (بيتا)، وأنها متاحة لجميع عملاء Ultimate.

يجرد المحلّل كل تبعية مباشرة وانتقالية (transitive) في المشروع، ويُظهر أيّ الحزم المعرّضة للثغرات يستخدمها تطبيقكم فعلاً. وتُقارَن النتائج بقاعدة بيانات GitLab Advisory Database، وتُوسَم المشكلات المعروفة. وتظهر الثغرات مباشرة في merge request، فيرى المطورون المشكلات قبل إرسال الشيفرة إلى بيئة الإنتاج (production). وهذا يمنع وصول الثغرات إلى النظام الفعلي ويسرّع عملية الإصلاح.

ثلاث مزايا رئيسية

سلسلة التبعيات الكاملة. يتتبع المحلّل التبعيات الانتقالية مهما بلغ عدد مستويات التداخل. فإذا كانت library-a تعتمد على library-b التي تعتمد بدورها على library-c المعرّضة للثغرات، ترون المسار كاملاً وتعرفون بدقة أين يجب التدخل. وهذا مهم خصوصاً في المشاريع الكبيرة التي قد يضم فيها مخطط التبعيات آلاف الحزم.

الثغرات المستخدمة فعلياً فقط. ليست كل تبعية واردة في الملف الوصفي (manifest) مستخدمة فعلاً في التطبيق. فبالنسبة إلى مشاريع Java وJavaScript/TypeScript وPython، يتحقق المحلّل مما إذا كانت شيفرتكم تستورد الحزم المعرّضة للثغرات فعلاً. وهذا يتيح تأجيل إصلاح الثغرات في الحزم غير المستخدمة والتركيز على المواضع التي ينطوي فيها الأمر على خطر حقيقي.

الفحص المستمر. شغّلوا المحلّل عند نشر تنبيهات أمنية (advisories) جديدة، وعند كل merge request وكل عملية بناء (build). وهذا مهم خصوصاً للمشاريع التي تباطأ تطويرها لكن شيفرتها لا تزال تعمل في بيئة الإنتاج وتحتاج إلى حماية.

ما الذي يعنيه ذلك

يمثّل فحص SBOM خطوة جادة نحو إدارة أذكى لسلسلة التوريد. فبدلاً من قائمة طويلة بجميع الثغرات، تحصل الفرق على ترتيب بحسب الخطر الفعلي، فتوفّر أسابيع من العمل على إصلاحات لا حاجة إليها في الواقع.

وبالنسبة إلى المؤسسات المتنامية، تتيح ملفات الأمان المدمجة (security profiles) ضبط الفحص مرة واحدة وتطبيقه على جميع المشاريع دفعة واحدة، من دون تحرير ملف .gitlab-ci.yml يدوياً في كل مشروع.