كيفية اختيار الحلول مفتوحة المصدر لمؤسستك

وفقًا لتقرير حالة المصدر المفتوح لعام 2025، تستخدم 96% من الشركات التي شملها الاستطلاع تطبيقات مفتوحة المصدر. ويعود السبب في هذه الجاذبية إلى التنوع الكبير في الخيارات، وخيارات التخصيص، وعدم وجود رسوم للترخيص. ومع ذلك، يواجه أكثر من نصف الشركات التي شملها الاستطلاع تحديات كبيرة في الصيانة المستمرة للتطبيقات مفتوحة المصدر. وتعاني 63% منها صعوبة في الحفاظ على تحديث الحلول وتطبيق التصحيحات الأمنية. وتشكل مشكلات الأمن الإلكتروني والامتثال للمعايير التنظيمية ووجود تطبيقات مفتوحة المصدر بلغت نهاية عمرها الافتراضي (EoL) – لم تعد تحظى بالدعم – تحديات بارزة. إذن، كيف يمكنك تقليل احتمالية حدوث هذه المشكلات، وما الذي يجب أن تبحث عنه عند اختيار برامج مفتوحة المصدر (OSS) لتطبيقها؟

التحديثات والتصحيحات

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

يمكن للأدوات القياسية مثل Git Insights، بالإضافة إلى الخدمات التكميلية مثل Is it maintained? وRepology وLibraries.io أن تساعد في الإجابة على هذه الأسئلة. ويعرض Libraries.io على الفور التبعيات القديمة التي يستخدمها الإصدار الحالي.

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

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

سيساعدك كل هذا على فهم حجم الجهد المطلوب لصيانة المنتج. وستحتاج إلى تخصيص موارد داخلية للدعم. ولا يكفي مجرد تحديد المسؤوليات؛ وسيتطلب الأمر تخصيص ساعات عمل لهذه المهام وما يرتبط بها.

الثغرات الأمنية

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

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

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

التبعيات وسلسلة التوريد

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

لتقييم ذلك، ستحتاج إلى SBOM (قائمة مكونات البرامج) أو أدوات SCA (تحليل تكوين البرامج). ويمكن للحلول مفتوحة المصدر المتاحة مثل OWASP Dependency-Check أو Syft إنشاء شجرة تبعيات المشروع، لكن هذه الأدوات مصممة عادةً للمشاريع قيد التشغيل بالفعل، والمنشورة في مستودعاتك الخاصة أو صور الحاويات. لذلك، يُفضل إجراء تحليل متعمق للتبعيات على منتج اجتاز بالفعل التقييم الأولي ويُعد منافسًا جادًا للحصول على مكان في بنيتك التحتية.

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

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

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

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

الامتثال للمتطلبات الداخلية والتنظيمية

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

سيتطلب كل برنامج تقريبًا في كل صناعة تدقيق امتثال للترخيص. ويتم توزيع بعض المكونات والتطبيقات مفتوحة المصدر بموجب تراخيص مقيدة، مثل AGPL، التي تضع قيودًا على طريقة توزيع البرنامج واستخدامه. وبفضل تحليل قائمة مكونات البرامج (SBOM) / تحليل تكوين البرامج (SCA)، يمكنك حصر جميع تراخيص برامجك وتبعياتها، ثم التأكد من أن حالة استخدامك لا تنتهك أيًا منها. ويمكن أتمتة هذه العمليات إلى حد كبير باستخدام أدوات متخصصة مثل OSS Review Toolkit، لكن الأتمتة ستتطلب سياسات واضحة وبذل جهد من جانب فريق التطوير لديك.

تكاليف الدعم

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

إذا كانت موارد فريقك الداخلي غير كافية للدعم (بسبب محدودية الموظفين أو الخبرة)، فهناك نوعان على الأقل من الدعم الفني الاحترافي بالاستعانة بمصادر خارجية: شركات مثل Red Hat – التي تتخصص في عمليات التطبيق، وموفرو الاستضافة المُدارة – لتطبيقات محددة (مثل Kube Clusters وMongoDB Atlas وما شابه ذلك).

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

• هل يمتلك فريق الأمن الإلكتروني ماسحات للثغرات الأمنية وأدوات لإدارة المخاطر تتكيف جيدًا مع البرامج مفتوحة المصدر؟
• هل تدعم أدوات تتبع أصول تكنولوجيا المعلومات ومراقبتها مشاريع ومكونات الحلول مفتوحة المصدر؟
• بالنسبة لفرق التطوير الداخلية، هل يتم تضمين عمليات فحص الصور والمستودعات ومصدر التعليمات البرمجية الأخرى في مسار التسليم المستمر / النشر المستمر (CI/CD)؟ وتستطيع حلول الأمان المتخصصة مثل Kaspersky Hybrid Cloud Security أتمتة هذا الجانب.
• هل طورت شركتك سياسة تنظم استخدام البرامج مفتوحة المصدر، وهل هناك فهم واضح لمن يتخذ القرارات ومن المسؤول عن الأمور التشغيلية؟

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