بنية إدارة الثغرات الأمنية مفتوحة المصدر

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

مجموعة موثوقة من المكونات مفتوحة المصدر

يتمثل الجزء الرئيسي من الحل في منع استخدام التعليمات البرمجية التي تحتوي على ثغرات أو برمجيات ضارة. وينبغي تنفيذ الإجراءات التالية:

• امتلاك مستودع داخلي للمخرجات البرمجية. ويجب أن يكون المصدر الوحيد للمكونات اللازمة للتطوير الداخلي هو مستودع موحد، لا تُقبل فيه المكونات إلا بعد اجتياز سلسلة من الفحوصات.
• إجراء فحص دقيق للمكونات. ويشمل هذا الفحص عمليات التحقق من: الإصدارات المعروفة للمكون، والإصدارات التي يُعرف أنها عرضة للاختراق والضارة، وتاريخ النشر، وسجل النشاط، وسمعة الحزمة ومؤلفيها. ويعد فحص كامل محتويات الحزمة أمرًا إلزاميًا، بما في ذلك تعليمات الإنشاء، وحالات الاختبار، والبيانات المساعدة الأخرى. ولتصفية السجل أثناء عملية الإدخال، استخدم ماسحات متخصصة للمصادر المفتوحة أو حل شامل لأمان عبء العمل السحابي.
• تشغيل تثبيت التبعيات. يجب على عمليات الإنشاء، وأدوات الذكاء الاصطناعي، والمطورين عدم استخدام قوالب عامة (مثل “latest”) عند تحديد الإصدارات. ويجب أن تستند عمليات بناء المشاريع إلى إصدارات تم التحقق منها. وفي الوقت ذاته، يجب تحديث هذه التبعيات المثبتة بانتظام إلى أحدث الإصدارات التي تم التحقق منها التي تحافظ على التوافق وتخلو من الثغرات الأمنية المعروفة. ويقلل هذا الإجراء بشكل كبير من مخاطر هجمات سلاسل التوريد الناتجة عن اختراق الحزم المعروفة.

تحسين بيانات الثغرات الأمنية

لتحديد الثغرات الأمنية بفعالية أكثر وترتيبها حسب الأولوية بشكل صحيح، تحتاج المؤسسة إلى إنشاء العديد من عمليات تكنولوجيا المعلومات والأمان:

• إثراء بيانات الثغرات الأمنية. بناءً على احتياجات المؤسسة، تبرز الحاجة إما لإثراء المعلومات عبر دمج البيانات من قواعد بيانات مثل NVD وEUVD وBDU وGitHub Advisory Database وosv.dev، أو شراء تغذية تجارية لمعلومات الثغرات الأمنية تكون فيها البيانات مجمعة وتم إثرائها مسبقًا. وفي كلتا الحالتين، يجدر أيضًا مراقبة تغذيات معلومات التهديدات لتتبع اتجاهات الاستغلال الواقعية وفهم طبيعة المهاجمين الذين يستهدفون ثغرات أمنية محددة. وتوفر Kaspersky تغذية بيانات متخصصة تركز بشكل خاص على المكونات مفتوحة المصدر .
• تحليل متعمق لتكوين البرمجيات. تسمح أدوات تحليل مكونات البرمجيات المتخصصة (SCA) بالتنقل الصحيح في سلسلة التبعيات داخل التعليمات البرمجية مفتوحة المصدر، وذلك لإجراء حصر كامل للمكتبات المستخدمة، واكتشاف المكونات القديمة أو غير المدعومة. وتفيد البيانات المتعلقة بالمكونات السليمة في إثراء سجل المخرجات البرمجية.
• تحديد البرمجيات المهجورة. حتى إذا لم يكن المكون مصابًا بثغرة أمنية رسمية ولم يُعلن رسميًا عن توقف دعمه، يجب أن تضع عملية الفحص علامة تحذيرية على المكونات التي لم تتلقَّ تحديثات لأكثر من عام. وتستوجب هذه المكونات تحليلاً منفصلاً واستبدالاً محتملاً، تمامًا مثل المكونات التي وصلت إلى نهاية عمرها الافتراضي.

تأمين التعليمات البرمجية للذكاء الاصطناعي ووكلاء الذكاء الاصطناعي

يجب إحاطة أنشطة أنظمة الذكاء الاصطناعي المستخدمة في البرمجة بمجموعة شاملة من التدابير الأمنية؛ بدءًا من تصفية بيانات الإدخال وصولاً إلى تدريب المستخدمين:

• القيود المفروضة على توصيات التبعية. يجب تكوين بيئة التطوير لضمان عدم إشارة وكلاء ومساعدي الذكاء الاصطناعي إلا إلى المكونات والمكتبات الموجودة في مستودع المخرجات البرمجية الموثوق. وفي حال عدم توفر الأدوات المناسبة فيها، ينبغي للنموذج إرسال طلب لإدراج التبعية المطلوبة في المستودع، بدلاً من سحب أي ملف من مستودع PyPI لمجرد كونه يطابق الوصف.
• تصفية مخرجات النموذج. على الرغم من هذه القيود، يجب التحقق من كل ما يولده النموذج لضمان خلو التعليمات البرمجية التي أنتجها الذكاء الاصطناعي من تبيعات قديمة، أو غير مدعومة، أو مصابة بثغرات أمنية، أو حتى وهمية. وينبغي دمج هذا الفحص مباشرة في عملية قبول التعليمات البرمجية أو مرحلة التحضير للبناء. ولا يحل هذا الإجراء محل عملية التحليل الساكن التقليدية؛ إذ لا بد من استمرار دمج أدوات SAST في مسار التطوير والنشر المستمر.
• تدريب المطورين. يجب أن تكون فرق تكنولوجيا المعلومات والأمان على دراية تامة بخصائص أنظمة الذكاء الاصطناعي، ومبادئ عملها، والأخطاء الشائعة المرتبطة بها. ولتحقيق ذلك، يجب على الموظفين إتمام دورة تدريبية متخصصة مصممة لتناسب أدوارهم الوظيفية المحددة.

الإزالة المنهجية للمكونات المنتهية الصلاحية

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

• الترحيل. تُعد هذه الطريقة الأكثر تعقيدًا وتكلفة من الناحية التنظيمية، حيث تتطلب استبدال المكون بالكامل، يليه تكييف أو إعادة كتابة أو استبدال التطبيقات القائمة عليه. ويُعد قرار الترحيل شاقًا بشكل خاص عندما يتطلب عملية إصلاح شاملة لجميع التعليمات البرمجية الداخلية. وغالبًا ما يؤثر ذلك على المكونات الجوهرية؛ فمن المستحيل، على سبيل المثال، الترحيل من بيئات مثل Node.js 14 أو Python 2 بسهولة.
• الدعم طويل الأمد (LTS). يوجد سوق مخصص لخدمات الدعم للمشاريع القديمة واسعة النطاق. ,يتضمن ذلك أحيانًا العمل على نسخة مشتقة من النظام القديم يتولى صيانتها مطورون من جهة خارجية؛ وفي حالات أخرى، تنقل فرق متخصصة التصحيحات الأمنية التي تعالج ثغرات محددة وتطبيقها على الإصدارات القديمة غير المدعومة. ويتطلب الانتقال إلى خيار الدعم طويل الأمد عادةً تكاليف دعم مستمرة، إلا أنه يظل أكثر فعالية من حيث التكلفة مقارنة بالترحيل الكامل في كثير من الحالات.
• الضوابط التعويضية. استناداً إلى نتائج التحليل التفصيلي، يمكن وضع مجموعة من التدابير الأمنية الشاملة للتخفيف من مخاطر استغلال الثغرات الأمنية الموجودة في المنتج القديم. وتعتمد كل من فعالية هذا النهج وجدواه الاقتصادية على الدور الذي يلعبه البرنامج داخل المؤسسة.

يجب أن تتعاون فرق الأمان وتكنولوجيا المعلومات والإدارة معًا لاختيار واحد من هذه المسارات الثلاثة لكل مكون برمجِي مهجور أو منتهي الصلاحية، وتوضيح هذا الاختيار في سجلات أصول الشركة وقوائم مواد البرمجيات (SBOMs).

إدارة الثغرات الأمنية في المصادر المفتوحة القائمة على المخاطر

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

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

• هل يتم فعليًا تنفيذ فرع التعليمات البرمجية المصاب بالثغرة الامنية في بيئة المؤسسة؟ يجب إجراء تحليل لإمكانية الوصول للثغرات الأمنية المكتشفة. ولا يتم تشغيل الكثير من أجزاء التعليمات البرمجية المعيبة أبدًا ضمن التنفيذ المحدد للمؤسسة، مما يجعل استغلال الثغرة الأمنية أمرًا مستحيلاً. ويمكن لبعض حلول SCA إجراء هذا التحليل. وتسمح هذه العملية نفسها بتقييم سيناريو بديل: ماذا يحدث إذا تم إزالة الإجراءات أو المكونات المصابة بالثغرات الأمنية من المشروع تمامًا؟ في بعض الأحيان، يتبين أن طريقة المعالجة هذه يسيرة بشكل مفاجئ.
• هل يتم استغلال هذا العيب في هجمات واقعية؟ وهل يتوفر نموذج لاختبار الاختراق (PoC)؟ تعد الإجابات على هذه الأسئلة جزءًا من أطر ترتيب الأولويات القياسية مثل EPSS، لكن يجب إجراء التتبع عبر مجموعة أوسع بكثير من مصادر المعلومات.
• هل تم الإبلاغ عن نشاط إجرامي سيبراني في سجل التبعيات هذا، أو في مكونات ذات صلة أو مشابهة؟ تُعد هذه عوامل إضافية لترتيب الأولويات.

يسمح أخذ هذه العوامل في الاعتبار للفريق بتخصيص الموارد بشكل فعال ومعالجة العيوب الأكثر خطورة أولاً.

الشفافية هي المعيار الجديد

ستستمر معايير الأمان للبرمجيات مفتوحة المصدر في الارتفاع. وستواجه الشركات التي تطور التطبيقات – حتى تلك المخصصة للاستخدام الداخلي – ضغوطًا تنظيمية تفرض وجود أمن سيبراني موثق وقابل للتحقق داخل أنظمتها. ووفقًا لتقديرات خبراء Sonatype، فإن 90% من الشركات عالميًا تخضع بالفعل لواحد أو أكثر من المتطلبات التي تلزمها بتقديم أدلة على موثوقية البرمجيات التي تستخدمها؛ وبناءً عليه، يرى الخبراء أن الشفافية هي “المعيار الجديد وأساس التعامل في أمان سلاسل توريد البرمجيات”.

من خلال التحكم في استخدام المكونات والتطبيقات مفتوحة المصدر، وإثراء معلومات التهديدات، والمراقبة الصارمة لأنظمة التطوير القائمة على الذكاء الاصطناعي، تستطيع المؤسسات تقديم الابتكارات التي يتطلع إليها قطاع الأعمال، مع الوفاء في الوقت ذاته بالمعايير الصارمة التي تضعها الجهات التنظيمية والعملاء على حد سواء.