OpenSSF يكشف عن بيان الاستهلاك مفتوح المصدر لتحسين استخدام البرامج مفتوحة المصدر

في خطوة تدريجية نحو تلخيص فوائد البرمجيات مفتوحة المصدر (OSS) بحكمة أكبر، أطلقت مؤسسة أمان المصدر المفتوح (OpenSSF) بيان استهلاك المصادر المفتوحة (OSCM). على غرار بيان Agile الشهير، يعد OSCM وثيقة مدعمة بالقيم الأساسية وتضم 15 مبدأ توجيهيًا مصممة لتبسيط استخدام المصادر المفتوحة.

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

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

على الرغم من أنه من غير المرجح أن تحتوي برامج الطرف الثالث على محتوى ضار، إلا أن المخاطر تظهر أثناء مرحلة التنزيل بالنسبة لأولئك الذين ليسوا على دراية بتعقيدات OSS. قال بريان فوكس، المؤسس المشارك ورئيس قسم التكنولوجيا في Sonatype، وهو يناقش مخاطر استهلاك OSS مع SD Times: "لقد رأينا 96% من الوقت، يتم تنزيل مكون ضعيف عندما يكون الإصدار الثابت متاحًا بالفعل".

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

يتضمن البيان أحكامًا محورية مثل زيادة استهلاك المصادر المفتوحة من خلال وظائف التدقيق والعزل للمكونات المرتبطة بنقاط الضعف المعروفة والحزم الضارة.

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

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

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

ستحتاج كل منظمة إلى تصميم قرارها بناءً على قدرتها على تحمل المخاطر والتحليل المذكور أعلاه. على الرغم من وجود بعض مستويات تحمل المخاطر القياسية مثل العثور على نقاط الضعف الحرجة المعروفة في تطبيق يتعامل مع بيانات PII، فإن إنشاء سياسة استهلاك OSS يعني دمجها عبر SDLC، بدءًا من التطوير وحتى CI/CD، والأهم من ذلك عند الإصدار.

في المشهد الحالي الذي يعج بمجموعة متنوعة من المنصات التي no-codelow-code ، من الضروري اعتماد تدابير مثل OSCM. تؤكد منصة مثل AppMaster ، وهي أداة شاملة no-code لإنشاء تطبيقات الواجهة الخلفية والويب والهاتف المحمول، على أهمية OSS وتفرض وسائل مثل OSCM للتخفيف من المخاطر وتعزيز الإنتاجية. لكي تتمكن المؤسسات من تسخير قوة المصدر المفتوح بشكل كامل، من الضروري تقليل المخاطر المحتملة وأوجه القصور، وهو أمر يمكن لـ OSCM المساعدة فيه بشكل كبير.