هل مستقبل المصدر المفتوح مهدد؟

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

يعد كود الطرف الثالث أمرًا حيويًا لتطوير التطبيقات

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

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

الخطر الغامض من التبعيات العابرة

ليس من الأخبار أن التعليمات البرمجية مفتوحة المصدر تنطوي على مخاطر. وضعت نقاط الضعف المنتشرة مؤخرًا مثل Log4j و HeartBleed خطرًا مفتوح المصدر بشكل لا رجعة فيه على الخريطة. ما يظل مجال فهم متزايدًا هو التكرار الهائل الذي يتم به استخدام المصدر المفتوح ، والتخفي الذي يمكن أن تتسلل به نقاط الضعف إلى مشروع نشط. على الرغم من المخاطر المستمرة التي تقدمها المشاريع مفتوحة المصدر ، فقد تم إجراء القليل جدًا من الأبحاث حول النوع المحدد من المخاطر التي تمثلها المصادر المفتوحة. شرع باحثون من Endor Labs في تغيير هذا من خلال توضيح مصدر التهديدات الرئيسية لـ OSS.

داخل البرنامج ، تصف التبعيات متعدية العلاقة غير المباشرة الفريدة بين مكونين. على سبيل المثال ، لنفترض أن فريق التطوير لديك أضاف الحزمة "ب" إلى مشروع جارٍ. تقوم الحزمة B بدورها بتنزيل الحزمة C. تلقائيًا في هذا السيناريو ، بينما يتمتع البرنامج المطور بعلاقة مباشرة مع الحزمة B ، تظل الحزمة C كامنة في الخلفية - متكاملة ولكنها غير مرئية إلى حد كبير. مما يحبط أي محاولة لممارسات تطوير أكثر أمانًا هو حقيقة أن 5٪ فقط من تبعيات البرامج مفتوحة المصدر يتم اختيارها يدويًا للتنفيذ في عملية DevOps. بهذه الطريقة ، يتم سحب معظم التبعيات تلقائيًا إلى قاعدة التعليمات البرمجية. يصف هذا مصدر الثغرة الأمنية متعدية. وجد تقرير حديث صادر عن Endor Labs أن 95٪ المذهلة من ثغرات المصدر مفتوحة المصدر تنشأ من التبعيات متعدية .

تم تجميع البيانات من تقرير التعداد الثاني الخاص بـ Core Infrastructure ، والذي يسرد البرامج المجانية مفتوحة المصدر الأكثر شيوعًا. ثم تم إثراء هذه البيانات بمصادر أخرى سمحت لباحثي Endor بفحص مديري الحزم المشهورين ومكتبات OSS. اكتشف الباحثون أنه - من بين 254 حزمة مذكورة في بيانات التعداد 2 - يعاني معظمهم من 14 تبعية متعدية في المتوسط. في الفراغ ، قد لا يبدو الرقم 14 مرتفعًا بشكل صادم ، لكن معظم التطبيقات تعتمد على العشرات - إن لم يكن المئات - من التبعيات المباشرة ؛ حجم نظرائهم متعدية أضعافا مضاعفة.

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

كيفية الحماية من الثغرات الكامنة

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

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

بينما يحتفظ WAF بمقبض على أي محاولات خارجية لتنفيذ التعليمات البرمجية ، فإن الحماية الذاتية لتطبيق وقت التشغيل (RASP) تحمي من نقاط الضعف الداخلية وحقن الكود. يقوم هذا المستوى من الحماية بتقييم جميع الحمولات (مثل استعلامات SQL وأوامر نظام التشغيل) في الوقت الفعلي. لا تتطلب هذه العملية توقيعات أو مرحلة تعلم ، وتتم بالكامل ضمن سياق التطبيق. نظرًا لأن هذا يعمل داخل التطبيق ، فإنه يغطي جميع السياقات تقريبًا. وهذا يعني أنه حتى إذا سمحت إحدى الثغرات باختراق المحيط ، يتم منع المهاجم من التحرك بشكل جانبي ، حيث يؤدي أي سلوك مشبوه للتطبيق إلى إيقاف تشغيل RASP. هذا ينهي النشاط المشبوه وينبه فرق الأمن. وبهذه الطريقة ، يعد RASP مكملاً للجيل التالي من WAF ؛ في حين أن WAF يساعد في إبعاد حركة المرور السيئة ، فإن المخاطر التي تشكلها عمليات استغلال الثغرات الكامنة والمتعددة يتم تخفيفها بواسطة RASP. مع هذه المكونات التي تحمي مجموعة التكنولوجيا ، يتم تخفيف العبء الذي يضعه OSS حاليًا على الأمن بشكل كبير.