مكافحة التطرف العنيف (نقاط الضعف والتعرض الشائعة) تعد عمليات الفحص ضرورية لتأمين تطبيقاتك البرمجية. ومع ذلك، مع التعقيد المتزايد لمجموعات البرامج، قد يكون تحديد ومعالجة جميع التهديدات التطرفية الخطيرة أمرًا صعبًا. إحدى أكبر مشكلات عمليات فحص CVE اليوم هي انتشار النتائج الإيجابية الكاذبة، حيث يتم تحديد ثغرة أمنية في حزمة غير مستخدمة في تطبيق الإنتاج.
من المهم أن تتذكر أنه حتى بعد حصولك على قائمة كاملة بجميع حزم البرامج الخاصة بك وقائمة كاملة بجميع التهديدات الشائعة الموجودة في تلك الحزم، فمن المؤكد أنها ليست جميعها ذات صلة بتطبيقك. قد يكون CVE في وظيفة غير مستخدمة في التعليمات البرمجية الخاصة بك، أو في جزء من المكتبة التي لا تتصل بها حتى. قد يكون في تبعية عابرة يتم استدعاؤها فقط بسبب قائمة التبعيات غير المصححة وليست قيد الاستخدام في التعليمات البرمجية الخاصة بك على الإطلاق. حتى بمجرد أن تعرف أن CVE موجود في جزء من المكتبة التي تستخدمها، فلا يضمن أن CVE قابل للاستغلال فعليًا في تطبيقك. تتطلب بعض عمليات استغلال الثغرات شروطًا صارمة حتى تكون قابلة للاستخدام من قبل المتسللين، بما في ذلك الجمع بين 3 أو أكثر من برامج الاستغلال الشائعة بالتسلسل، والمكدس المناسب، والبنية التحتية المناسبة. نظرًا لأنك لا تزال بحاجة إلى إلقاء نظرة فاحصة على كل CVE تحصل عليه من الفحص، يمكنك معرفة مدى أهمية غربلة عدد CVE التي تحصل عليها حتى لا تصاب بإرهاق التنبيه أو إنهاك CVE قبل أن تتمكن من العودة لبناء الميزات التالية لتطبيقك فعليًا.
في هذه المقالة، سأقدم بعض الحلول الممكنة للتخفيف من النتائج الإيجابية الخاطئة في عمليات فحص CVE، بهدف تقليل العدد الإجمالي لـ CVE التي تحتاج إلى التعامل معها. سأبدأ بمناقشة تحديات تحديد الحزم، ثم ننتقل إلى تقديم قاعدة بيانات تقوم بتعيين ملفات الحزم لأسماء الحزم. سأناقش أيضًا مشكلات تحديد النطاق ومسار التعليمات البرمجية التي يمكن أن تسبب نتائج إيجابية كاذبة.
لنبدأ بالنظر في كيفية تحديد مكافحة التطرف العنيف في المقام الأول.
الحزمة الغامضة ومكافحة التطرف العنيف المفقودة
شركة ميتري هي منظمة أمريكية غير ربحية مسؤولة عن برنامج CVE®. البرامج تتمثل المهمة في تحديد وتعريف وفهرسة نقاط الضعف في الأمن السيبراني التي تم الكشف عنها علنًا. الطريقة التي يعمل بها هذا الأمر هي أنه بمجرد العثور على ثغرة أمنية، تقوم بملء نموذج، وإذا كان من الممكن تأكيد الاكتشاف، يتم إعطاء معرف CVE جديد للثغرة الأمنية وإضافته إلى قاعدة بيانات CVE العامة.
بالنظر إلى الطريقة التي يتم بها إدراج CVEs، فإن أحد التحديات الأساسية في عمليات فحص CVE هو تحديد الحزم والمكتبات بشكل صحيح. عندما يتعرف شخص ما على ثغرة أمنية في حزمة أو مكتبة، فإنه يقوم بإدراجها مع اسم الحزمة والإصدار الذي يعرفه. بالطبع، لا تستخدم جميع الأدوات نفس اصطلاحات التسمية، وأسماء الحزم ليس لها معيار عالمي موجود. إن "مشكلة التسمية"، كما أصبحت معروفة، خطيرة بدرجة كافية لدرجة أن العديد من المنتديات ومجموعات التفكير كانت تحاول إيجاد حل أرضية مشتركة لفترة طويلة. على سبيل المثال، هنا الحل المقترح من OWASP للمشكلة من حيث صلتها بإنشاء SBOMS. في كثير من الأحيان، تعتمد أدوات الفحص على المصادر التي يتم تغذيتها، مثل العناصر المبنية أو المجمعة، لأسماء الحزم التي تقدمها في نتيجة الفحص ولا تكون هذه المصادر موثوقة دائمًا. على سبيل المثال، قد تجعل الأغلفة والتعديلات من الصعب تحديد الحزمة الفعلية. بالإضافة إلى ذلك، قد لا تترك بعض ملفات الحزمة أي أثر لحزمة التثبيت الخاصة بها، مثل أوامر Docker COPY.
لمعالجة هذه القضايا، نحن، في الكاتب الأمن، اقترح إنشاء قاعدة بيانات لتطبيقك تقوم بتعيين ملفات الحزمة لأسماء الحزمة. حتى لو كان اسم الحزمة مختلفًا، وإذا كانت نفس الحزمة، فستكون الملفات وتجزئة الملف متطابقة. من خلال القيام بذلك، يمكنك تخطي المشكلات المتعلقة بالمغلفات والتعديلات وتحديد الحزمة الفعلية التي تحتاج إلى المعالجة. يمكن لهذا النهج توفير الوقت والجهد في عملية معالجة مكافحة التطرف العنيف. منذ منصة الكاتب يقوم بالفعل بتحديد الملفات المرتبطة بكل حزمة مضمنة في صورتك النهائية، وإنشاء قاعدة البيانات هذه هو الخطوة المنطقية التالية. نعتزم ألا يعتمد فحص CVE الخاص بنا على الاسم والإصدار المدرج بواسطة CVE، ولكن على الملفات الفعلية التي تتضمنها الحزمة.
هل انتي امي؟
عند التعامل مع البنية النهائية التي تمثل صورة Docker، فمن الشائع هذه الأيام عدم البدء من الصفر. إن وجود نقطة بداية قوية، مثل صورة أساسية ثابتة، يسمح للمطورين بالتركيز على جزء البناء الذي يمثل تطبيقهم بدلاً من البدء في تخطيط البيئة التي يجب تشغيلها عليها. أحد التحديات في استخدام صور Docker هو فهم مصدرها وتبعياتها، خاصة عندما يتعلق الأمر بالصورة الأصلية (بصرف النظر عن الصورة الأساسية) التي تم بناء الصورة النهائية فوقها.
الصورة الأصلية هي مفهوم فكرنا فيه لشرح أقرب "قريب حي" لصورة Docker. يتم إنشاء الصور في طبقات مميزة، لذا، لنفترض أنني أستخدم صورة أساسية معروفة، مثل Alpine أو Debian أو Ubuntu، وقمت ببناء طبقة التطبيق الخاصة بي فوقها مباشرةً. في هذه الحالة، أقرب "والدي" سيكون تلك الصورة الأساسية. ولكن ماذا لو كانت الشركة التي أعمل بها لديها نقطة بداية مختلفة، نقطة تتضمن صورة أساسية وبضع طبقات إضافية فوق تلك الخاصة بأدوات الأمان الإلزامية لجميع صور الشركة؟ في هذه الحالة، ستكون صورتي الأصلية هي قالب الشركة هذا وسأكون قادرًا أيضًا على تحديد الصورة الأساسية التي تم بناء هذا القالب عليها.
تعد الصورة الأصلية جزءًا مهمًا من سلسلة توريد البرامج الخاصة بك، لأنها توفر الأساس للتطبيق وتبعياته. في الأصل، لا تتضمن صور Docker الكثير من المعلومات حول أصل صورها الأصلية أو الأساسية، مما يجعل من الصعب التحقق من سلامتها وفهم نقاط ضعفها والتحقق من ترخيصها.
ولمعالجة هذه المشكلة، طور Scribe أداة وخدمة مفتوحة المصدر تسمى صورة الوالدين لاكتشاف أقرب أصل تم مسحه ضوئيًا لصورة Docker. يمكن استخدام هذه الأداة لتحديد الصورة الأصلية لصورة Docker، والتي تعد عامل تمكين رئيسي لتقليل المخاطر:
أولاً، من خلال تحديد الصورة الأساسية، يمكن التحقق من سلامتها والتأكد من عدم العبث بها أو المساس بها. وهذا أمر مهم للحفاظ على أمن واستقرار التطبيق.
ثانيًا، من خلال فهم الثغرات الأمنية التي تنشأ من الصورة الأصلية وتلك التي تنشأ من طبقة التطبيق نفسها، يمكن للمرء تحديد أولويات الثغرات الأمنية وإدارتها بشكل أكثر فعالية. وهذا يعني أن التهديدات الشائعة المرتبطة بصورتك الأساسية أو صورتك الأم تكون أقل إلحاحًا (وليست مسؤوليتك دائمًا للمعالجة) عند مقارنتها بالمخاطر الشائعة في طبقة التطبيق.
بالإضافة إلى ذلك، من خلال تحديد الصورة الأصلية، يمكن للمرء التحقق من ترخيصها وضمان الامتثال للمتطلبات القانونية والداخلية.
تشتمل أداة ParentImage مفتوحة المصدر على قاعدة بيانات قابلة للتحديث لعمليات فحص صور Docker. يمكنك تفرعها واستخدامها داخليًا بالكامل ولكننا نأمل أن يقوم الأشخاص بمسح صور Docker الخاصة بهم وإرسال تلك المعلومات إلينا ليتم تضمينها في قاعدة البيانات. كلما زاد عدد عمليات مسح الصور التي تتضمنها قاعدة البيانات، زاد عدد "الآباء" الذين ستتمكن الأداة من التعرف عليهم. حاليًا، تحتوي قاعدة البيانات المضمنة على قائمة كاملة بجميع الصور الأساسية المثبتة كدليل على المفهوم. باعتبارها أداة مفتوحة المصدر، لا تكلفك تجربتها شيئًا، لذا إذا كنت تستخدم صور Docker، فأنا أشجعك على اعتبار هذه الأداة علاجًا محتملاً لسبب واحد من أسباب التهديدات الخطيرة غير ذات الصلة.
هل يجب أن أقوم بالمسح أم يجب أن أتخطى؟
التحدي الآخر الذي يواجه عمليات فحص CVE هو تحديد نطاق المشكلات. يشير تحديد النطاق إلى موقع الملفات والحزم التي تم فحصها - ما الذي يجب تضمينه في الفحص وما يمكن تجاهله بأمان. في بعض الأحيان، يتم العثور على CVE في حزمة غير مستخدمة فعليًا في إصدار الإنتاج من التطبيق. على سبيل المثال، قد يتم تثبيت حزمة نتيجة لاعتماد غير مباشر على بعض أطر الاختبار. ولمعالجة هذه المشكلة، تحتاج الماسحات الضوئية إلى تقييم نطاق ملفات التطبيق وتحديد التبعيات غير المباشرة المستخدمة.
تحتوي المكونات الإضافية لـ OWASP (مشروع أمان التطبيقات العالمية المفتوحة) على بعض الأمثلة الجيدة للأدوات التي يمكن أن تساعد في تحديد نطاق المشكلات. فحص التبعية OWASP، على سبيل المثال، يمكنه تحليل تبعيات التطبيق وتحديد التهديدات الخطيرة في سياق الرسم البياني لتبعية التطبيق. ومن خلال القيام بذلك، يمكنه تحديد التهديدات الشائعة المستخدمة في تطبيق الإنتاج وأيها غير مستخدمة.
مهما كان العدد، لا تزال بحاجة إلى معالجة التحديات والتطرف العنيف
في غياب بعض الأدوات الأخرى التي يمكنها إخبارك بالمكان الذي يكون فيه تطبيقك عرضة للاختراقات المحتملة والأبواب الخلفية وغيرها من المشكلات المماثلة، لا يزال فحص CVE خيارًا أساسيًا جدًا لمعالجة المشكلات المحتملة. تكمن المشكلة في أنه حتى تتحقق مما إذا كان أحد التهديدات الخطيرة المقدمة لك في الفحص يمثل مشكلة فعلية، فإنه يمثل تهديدًا يمكن استخدامه ضدك من قبل المنظمين والأطراف الثالثة والمستخدمين على حدٍ سواء.
باسم الأمن والشفافية، يتعين عليك مراجعة كل مشكلة محتملة وإثبات أنها إما ليست مشكلة، أو غير ذات صلة بتطبيقك، أو أنها مشكلة محتملة وتعمل على تصحيحها. حقيقة أن الكثير من هذه التهديدات الخطيرة تأتي إلى تطبيقك من حزم خارجية، وعادة ما تكون مفتوحة المصدر، تعني أنه حتى لو حددتها على أنها استغلال محتمل، فمن المحتمل أنك ستظل بحاجة إلى مساعدة مشرفي الحزم لتصحيحها.
مع كل هذا العمل المرتبط بكل CVE، فلا عجب أنك تفضل الحصول على أقل عدد ممكن في فحص CVE التالي. قد يساعد استخدام بعض الاقتراحات الموضحة في هذه المقالة في جعل المهمة الضخمة المتمثلة في معالجة نقاط الضعف لديك أكثر قابلية للإدارة.
إذا كان لديك أدوات أخرى مفتوحة المصدر أو مجانية للتعامل مع المشكلة، فنحن نود أن نسمع عنها. أخبرنا عن ذلك في التعليقات وشارك مع المجتمع كيف تتعامل مع جبل نقاط الضعف لديك.
يتم تقديم هذا المحتوى إليك بواسطة Scribe Security، وهي شركة رائدة في مجال توفير حلول أمان سلسلة توريد البرامج الشاملة - حيث توفر أحدث الأمان لعناصر التعليمات البرمجية وعمليات تطوير التعليمات البرمجية وتسليمها عبر سلاسل توريد البرامج. تعرف على المزيد.
الوظائف ذات الصلة
