أحد صفحات التقدم العلمي للنشر
اخترنا لكاستراتيجية رقميةالمرونة

أديروا مخاطر إعادة استخدام البرمجيات

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

عند إنشاء منتجاتها وخدماتها البرمجية الخاصة، فإن إحدى الطرق الرئيسية التي توجه بها مؤسسات تطوير البرمجيات Software development organizations الكفاءةَ هي الاعتماد على مكتبات مكونة من برمجيات قائمة وقابلة لإعادة الاستخدام. يساعد ذلك على تسريع الابتكار الرقمي Digital innovation، لكن المزايا تأتي مع المقايضات: تقبل المؤسسات، من دون علم منها أحيانا، درجة من المخاطر التي قد تؤدي إلى مشكلات خطيرة من حيث الأمن السيبراني.

وسلط الضوء على هذا الخطر في ديسمبر 2021، عندما تبين أن إطار برمجيات مفتوحة المصدر Open-source software framework مستخدمة على نطاق واسع يسمى لوغ فور جاي Log4j يحتوي على ثغرة خطيرة.1“CVE-2021-44228,” Mitre, accessed Dec. 12, 2021, https://cve.mitre.org. واحتلت الأخبار العناوين الرئيسية لأن عدداً لا يحصى من البرمجيات المستخدمة من قبل المؤسسات، والوكالات الحكومية، ومنازل الناس تعتمد على إطار تسجيل الدخول هذا القائم على لغة البرمجة جافا Java. ووجد خبراء الأمن أن استغلال ثغرة لوغ فور شل Log4Shell، كما صارت تعرف، يمكن أن تكون لها عواقب مدمرة على الشركات والأفراد. وتبين أن التعرض إلى هذا الضعف كان واسع النطاق بصورة مذهلة: لقد أصبح هذا الكود مضمناً في أنظمة برمجية على نطاق واسع، مما شكّل ثغرة خطيرة في العديد من الأنظمة الحيوية حول العالم. ويجب أن يكون التعرض إلى لوغ فور جاي بمثابة تنبيه للمديرين التنفيذيين، لفهم إعادة استخدام البرمجيات بشكل أفضل، وكيفية الحد من مخاطر استخدامها في مؤسساتهم.

نشأ إعادة استخدام البرمجيات كتدبير من تدابير الكفاءة في شركات البرمجيات الكبيرة، وكانت في معظمها مشروعات داخلية تتضمن مكونات مملوكة ومبنية داخلياً. وأدى ظهور الإنترنت وانفجار البرمجيات المفتوحة المصدر إلى تحويل الممارسة. أما حالياً، فمعظم البرمجيات مبنية جزئيا على الأقل على وظائف Functionality يجري الحصول عليها من مكونات برمجية خارجية. وفي الأغلب تُنشر هذه المكونات لصالح الجميع في مستودعات مفتوحة مصدر، مثل بايبل PyPI للبايثون Python، وإن بي إم NPM لنود دوت جاي إس Node.js، ومستودع مافن المركزي Maven Central Repository لجافا Java، على سبيل المثال لا الحصر.

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

تقييم إعادة الاستخدام على نطاق واسع
قد يكون من الصعب على قادة الأعمال أن يستوعبوا إلى أي مدى أصبحت إعادة الاستخدام متأصلة في ممارسات تطوير البرمجيات. ولتوضيح مدى انتشار ذلك، تأملوا أن لودش Lodash، وهي واحدة من أكثر حزم جافا سكريبت JavaScript المفتوحة المصدر المتاحة على إن بي إم، جرى تنزيلها أكثر من بليوني مرة عام 2021 (أي أكثر من 40 مليون مرة في الأسبوع في المتوسط) وأن أكثر من 149,000 حزمة أخرى منشورة على إن بي إم تعتمد على عملها. وعام 2021، تم تنزيل تشوك Chalk، وهي حزمة شعبية أخرى، أكثر من 5 بلايين مرة، ويعتمد عليها أكثر من 77,000 حزمة منشورة على إن بي إم.

ويزعم بعض الباحثين أن كتابة البرمجيات كثيرا ما تدور الآن حول كتابة ”كود غراء“ Glue code يربط بين أجزاء من مكونات البرمجيات القائمة أكثر من كتابة مجموعات جديدة تماما من التعليمات أو الخوارزميات.2M. Sojer and J. Henkel, “Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments,” Journal of the Association for Information Systems 11, no. 12 (March 2010): 868-901. ولاحظ مؤلفو دراسة حديثة لهذه الممارسة أن ”صناعة البرمجيات تخضع إلى تحول نموذجي. وخلافاً للحال في الماضي، عندما كانت إعادة استخدام البرمجيات مجرد شذوذ، أصبحت إعادة الاستخدام الآن القاعدة لأي مشروعات مهمة لتطوير البرمجيات“ – هذا شعور يتشاطره الكثيرون.3T. Mikkonen and A. Taivalsaari, “Software Reuse in the Era of Opportunistic Design,” IEEE Software 36, no. 3 (May-June 2019): 105-111.

ولفهم حجم هذه الظاهرة، ضعوا في اعتباركم أن بالنسبة إلى كل مكون برمجي يختار الفريق إعادة استخدامه، هناك احتمال كبير بأن يعتمد هذا المكون نفسه على مكونات برمجيات أخرى لها أوجه ترابط خاصة بها أيضاً. (انظر: إعادة استخدام أوجه ترابط البرمجيات من حيث المبدأ – وفي الممارسة العملية، الصفحة 64). وهذا يعني أنه عندما يستورد المطور مكونا واحدا – ما يعرف بالاعتماد Dependency في هذا السياق – قد يجري إحضار عشرات حالات الاعتماد الأخرى في الوقت نفسه، متضمنة في ذلك المكون الواحد مثل دمى ماتريوشكا Matryoshka الروسية. ونتيجة لهذا قد يعتمد مشروع برمجيات ضخم بشكل غير مباشر على الآلاف من المكونات الأخرى التي أنشأها ويصونها عدد كبير من فرق المطورين، وكل منهم لديه مصالحه وأهدافه وأجنداته الخاصة.

وفي حالة لوغ فور جاي، استجاب مطورو البرمجيات بسرعة للإفصاح عن نقاط الضعف، وأتيحت نسخة جديدة من الإطار للتنزيل في غضون أيام. وهذا دليل على قدرة المجتمع الصغير المفتوح المصدر على التحرك بسرعة عندما تنشأ مشكلات. ومع ذلك، فالمسألة الحقيقية بالنسبة لآلاف عديدة من المؤسسات هي أن معظم الذين استخدموا نسخة ضعيفة من لوغ فور جاي في برمجياتهم أصحبت من مسؤولياتهم الترقية بإصدار مصحح وإدارة حل الحوادث مع عملائهم. وفي حين أن لوغ فور شل لا شك في أنه مثال متطرف لهذه الظاهرة، كثيرا ما تظهر تقارير على اكتشاف مشكلات في الحزم الشعبية، أو مشكلات ناجمة عن استخدام المؤسسات لحزم برمجيات منخفضة الجودة أو قديمة لإنتاج برمجياتها الخاصة.4D. Goodin, “Malicious NPM Packages Are Part of a Malware ‘Barrage’ Hitting Repositories,” Ars Technica, Dec. 8, 2021, https://arstechnica.com; A. Sharma, “Dev Corrupts NPM Libs ‘Colors’ and ‘Faker’ Breaking Thousands of Apps,” Bleeping Computer, Jan. 9, 2022, www.bleepingcomputer.com; and A. Miller, “State of Open Source Security Report 2020,” PDF file (Boston: Snyk, 2020), https://go.snyk.io. وفي بعض الحالات، قد تؤثر هذه المشكلات في ملايين الأجهزة المتصلة التي لا يمكن ترقيتها بسهولة.5T. Seals, “‘Ripple20’ Bugs Impact Hundreds of Millions of Connected Devices,” Threatpost, June 16, 2020, https://threatpost.com.

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

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

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

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

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

راجعوا المكونات المستخدمة بشكل دوري Periodically review components in use. ينبغي إعادة النظر بانتظام في القرارات المتعلقة بإدراج عناصر خارجية في البرمجيات كجزء من الممارسة الجيدة المتمثلة في تسديد الديون التقنية (تُعرَّف بأنها تكلفة القرارات السابقة لاختيار حل مناسب على أفضل الحلول). في الأغلب تُشجَّع فرق البرمجيات على المشاركة في إعادة التجهيز، وهي ممارسة يعاد فيها تنظيم الكود المصدر للحد من الديون التقنية المتراكمة في شكل اختصارات برمجية سابقة وحلول بديلة، وذلك لتحسين إنتاجية المطور في المستقبل وتسهيل صيانة الكود. لسوء الحظ، عادة ما تأخذ عملية إعادة تجهيز الكود في الاعتبار الكود المصدر الداخلي فقط، لأن هذا هو ما يمكن للفرق التحكم فيه وتبدله بسهولة.

وعندما يكتب فريقكم الكود، يرقِّي Upgrade أحيانا المكونات الخارجية. وبمرور الوقت، يمكن أن تصبح رد فعل انعكاسي: إذا كان أحد المكونات قد خدم المؤسسة بشكل جيد لعدة أشهر، يثق الفريق بشكل افتراضي في إمكانية استخدام الإصدار الأخير بأمان، ويستمر في البناء حول هذا المكون، حتى لو كان ذلك يعني ضرورة تنفيذ الحلول البديلة أو الاحتفاظ بها للقيام بذلك. لكن من المؤسف أن هذا من الممكن أن يساهم في زيادة الديون التقنية بمرور الوقت. تتيح إعادة التجهيز فرصة أمام الفرق لإعادة النظر فيما إذا كانت لا تزال تريد الاعتماد على مكون خارجي. ومن المهم أن تظلوا على اطلاع دائم على تطور أحد المكونات وخريطة الطريق، بما في ذلك مراقبته بحثا عن المشكلات ونقاط الضعف المحتملة مع مرور الوقت، لضمان استمرار ملاءمته لاحتياجاتكم. وخلال مبادرات إعادة التجهيز، يمكن أن يساهم النظر الدقيق في المكونات الخارجية في الحد من الديون التقنية وتقليل تضخم البرمجيات الذي يمكن أن يعيق جودة البرمجيات وإنتاجية المطورين.6C. Soto-Valero, N. Harrand, M. Monperrus, et al., “A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem,” Empirical Software Engineering 26, no. 3 (March 2021): 1-44.

تعرفوا على البرمجيات التي تعتمد عليها مؤسستكم Know what software your organization relies on. قد يبدو الأمر مبسطاً، لكن معرفة البرمجيات التي تقوم مؤسستكم بتشغيلها، وخاصة البرمجيات ذات الأهمية التشغيلية الحاسمة، أمر مهم إلى ما هو أبعد من متطلبات عمليات التدقيق في تكنولوجيا المعلومات. أدى اكتشاف لوغ فور شل إلى إغلاق خدمات وكالة العوائد الكندية Canada Revenue Agency؛ في مقاطعة كيبيك وحدها، أغلق أكثر من 4,000 موقع حكومي على شبكة الإنترنت كإجراء وقائي.7H. Solomon, “Canadian Websites Temporarily Shut Down as World Scrambles to Mitigate or Patch Log4Shell Vulnerability,” IT World Canada, Dec. 13, 2021, www .itworldcanada.com. واضطرت الوكالات والمؤسسات إلى وقف الوصول إلى الأنظمة في حين جردت برمجياتها لتقييم ما إذا كانت قد تأثرت بالفعل بضعف تلك الأنظمة. ولوغ فور جاي منتشر إلى حد أن المؤسسات التي لديها تطبيقات جافا قيد التشغيل قد تفترض على الأرجح أن لوغ فور جاي كان يستخدم في مكان ما وقد يتطلب تصحيحات.

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

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

غريغوري فيال Gregory Vial

غريغوري فيال Gregory Vial

أستاذ مساعد لتكنولوجيا المعلومات في إتش إي سي مونتريال HEC Montréal.

المراجع

المراجع
1 “CVE-2021-44228,” Mitre, accessed Dec. 12, 2021, https://cve.mitre.org.
2 M. Sojer and J. Henkel, “Code Reuse in Open Source Software Development: Quantitative Evidence, Drivers, and Impediments,” Journal of the Association for Information Systems 11, no. 12 (March 2010): 868-901.
3 T. Mikkonen and A. Taivalsaari, “Software Reuse in the Era of Opportunistic Design,” IEEE Software 36, no. 3 (May-June 2019): 105-111.
4 D. Goodin, “Malicious NPM Packages Are Part of a Malware ‘Barrage’ Hitting Repositories,” Ars Technica, Dec. 8, 2021, https://arstechnica.com; A. Sharma, “Dev Corrupts NPM Libs ‘Colors’ and ‘Faker’ Breaking Thousands of Apps,” Bleeping Computer, Jan. 9, 2022, www.bleepingcomputer.com; and A. Miller, “State of Open Source Security Report 2020,” PDF file (Boston: Snyk, 2020), https://go.snyk.io.
5 T. Seals, “‘Ripple20’ Bugs Impact Hundreds of Millions of Connected Devices,” Threatpost, June 16, 2020, https://threatpost.com.
6 C. Soto-Valero, N. Harrand, M. Monperrus, et al., “A Comprehensive Study of Bloated Dependencies in the Maven Ecosystem,” Empirical Software Engineering 26, no. 3 (March 2021): 1-44.
7 H. Solomon, “Canadian Websites Temporarily Shut Down as World Scrambles to Mitigate or Patch Log4Shell Vulnerability,” IT World Canada, Dec. 13, 2021, www .itworldcanada.com.
اظهر المزيد

مقالات ذات صلة

زر الذهاب إلى الأعلى