دليل الممارس: الأمان
المقاييس الأولية:
إذا لم تكن قد قرأت بالفعل دليل الممارس: مقدمة - الأشياء التي يجب التفكير فيها عند تفسير المقاييس، يرجى التوقف الآن وقراءة هذا الدليل.
إن الأمن لا يتحدد إلا بقوة أضعف حلقاته. ويمكن العثور على حزم البرامج مفتوحة المصدر في كل البرامج التي نستخدمها تقريبًا (الملخص 2024)، وبالتالي فإن أمن مشاريعنا مفتوحة المصدر قد يكون له آثار واسعة النطاق على المشاريع الأخرى، ومستخدمينا، والنظام البيئي الأوسع.
يمكن أن يكون الأمان عاملاً مهمًا في اختيار مشروع مفتوح المصدر، لكن أمان أي مكون برمجي لا يكون جيدًا إلا بقدر أمان التبعيات الخاصة به (إمتياز 2022). يعد الأمان عاملاً مهمًا في اختيار مكونات مفتوحة المصدر التي يعتمد عليها مشروعك وكذلك التأثير على سبب اختيار الآخرين لاستخدام (أو عدم استخدام) مشروعك مفتوح المصدر. في هذا الاختيار، من المهم ملاحظة أن الحزم الشائعة ليست أكثر أو أقل احتمالية لاتباع ممارسات الأمان الجيدة (إمتياز 2022).
وجد تقرير تحليل المخاطر والأمن مفتوح المصدر لعام 2024 لشركة Synopsys أن 96% من قواعد التعليمات البرمجية التي قاموا بمسحها تحتوي على برامج مفتوحة المصدر، ومن المؤسف أن 84% منها بها ثغرات أمنية (74% منها ذات تصنيف خطورة مرتفع). نظرًا لأن البرامج مفتوحة المصدر موجودة في كل مكان، فإن أمان مشاريع البرامج مفتوحة المصدر يؤثر على صحة واستدامة مشاريعنا، الأمر الذي يمتد عبر النظام البيئي للبرمجيات بالكامل. ومع ذلك، ضع في اعتبارك أن مخاطر الأمان يمكن غالبًا اعتبارها دالة على الاحتمالية جنبًا إلى جنب مع التأثير. الاحتمالية هي إمكانية الاستغلال، والتأثير هو الضرر الذي يمكن أن يحدث نتيجة للاستغلال في سياق نشر البرامج، وبالتالي فإن المخاطر هي شيء يحتاج كل من يتبنى البرامج مفتوحة المصدر إلى تحديده لسياقهم وموقفهم وبيئتهم الخاصة.
نظرًا لأن الأمان موضوع معقد وحاسم، فقد تم تصميم هذا الدليل فقط لـ ابدأ بنفسك في طريقك نحو تحسين أمان مشروعك. ليس دليلا شاملا كل ما تحتاج إلى معرفته حول أمان مشروعات المصدر المفتوح. الهدف من سلسلة دليل الممارس هو مساعدة الأشخاص على تجاوز المرحلة الساحقة التي يشعر بها الكثيرون عندما يواجهون الكثير من المقاييس الجديدة التي تساعدهم في إيجاد بعض الطرق لبدء فهم وتحسين صحة مشاريعهم. بعد البدء في استخدام دليل الممارس هذا، يمكنك معرفة المزيد من الروابط إلى الأدلة الشاملة في قسم القراءة الإضافية أدناه والمرتبطة بهذا الدليل.
الخطوة 1: تحديد الاتجاهات
يعد الأمان موضوعًا معقدًا، ولكن يمكنك البدء بالنظر إلى بعض المقاييس الرئيسية. أولاً، أفضل ممارسات OpenSSF إن المعايير تخلق أساسًا هندسيًا جيدًا يشتمل على ممارسات الأمان الأساسية. ثانيًا، عندما تستخدم التبعيات القديمة، فإن احتمالية تعرضك لمشاكل أمنية تزيد أربع مرات (كوكس وآخرون 2015)، لذا فإن استخدام التبعيات القديمة يزيد من احتمالية تعرضك لمشاكل الأمان. ليبييرز يمكن أن يساعدك المقياس في فهم ما إذا كنت تحافظ على تحديث التبعيات الخاصة بك. ثالثًا، تردد الإصدار يساعدك على قياس ما إذا كانت إصلاحات الأمان والتحديثات الأخرى تصل إلى الإصدار في الوقت المناسب حتى يتمكن المستخدمون من الاستفادة من تحديثات الأمان الخاصة بك.
أفضل ممارسات OpenSSF
تشير مؤسسة الأمن مفتوحة المصدر (OpenSSF) يوفر طرقًا لتقييم مشروعك مفتوح المصدر عبر عدد من الأبعاد المختلفة للحصول على ملخص للمجالات التي يمكن فيها تحسين ممارسات مشروعك. في حين أن ممارسات الأمان تعد مكونًا مهمًا، شارة أفضل ممارسات OpenSSF يتجاوز هذا الدليل الأمان ليقترح مجموعة من أفضل الممارسات لمشروعك. إنه وسيلة جيدة ليس فقط لتقييم ممارسات الأمان الخاصة بك وتحسينها لتلبية معايير الشارة، بل إنه يشير أيضًا إلى المستخدمين بأنك تتبع أفضل ممارسات OpenSSF. المعايير الموجودة في أقسام التقارير والأمان والتحليل هي الأكثر قابلية للتطبيق لفهم وتحسين أمان مشروعك.
مصدر الصورة: https://www.bestpractices.dev/en/projects/63
ليبييرز
تشير ليبييرز يوضح المقياس عمر التبعيات التي تعتمد عليها، مقارنةً بالإصدارات المستقرة الحالية لتلك التبعيات. وقد تم اقتراحه لأول مرة في "قياس نضارة التبعيات في أنظمة البرمجيات" (كوكس وآخرون 2015). بشكل عام، يكون رقم Libyyear الأقل أفضل لأنه يشير إلى أنك تحافظ على تحديث التبعيات لديك.
مصدر الصورة: https://github.com/nasirhjafri/libyear
من خلال مقارنة الإصدار الحالي من التبعية المستخدمة في مشروعك مع أحدث إصدار متاح لكل تبعية، يمكنك فهم أفضل للحالات التي قد تحتاج فيها إلى مزيد من الاجتهاد في تحديث التبعيات. ومع ذلك، فإن التأخير الفني في تحديث التبعيات ينشأ عادةً بسبب التوتر بين استخدام أحدث إصدار وعدم كسر حل يعمل بشكل جيد بالفعل، لذلك في بعض الحالات، قد يختار المطورون عمدًا استخدام إصدار أقدم بدلاً من الإصدار الأحدث بسبب عدم التوافق أو المشكلات الفنية الأخرى (Zerouali et al. 2019).
تردد الإصدار
من الأهمية بمكان إصدار تحديثات الأمان وإصلاحات الأخطاء والميزات الجديدة في الوقت المناسب. وعند النظر إلى وتيرة الإصدارات، من المهم تضمين ليس فقط الإصدارات الكبيرة، بل أيضًا جميع الإصدارات الصغيرة، نظرًا لأن إصلاحات الأمان العاجلة تُصدر عادةً خارج الإصدارات الرئيسية.
![تردد إصدار المشروع مع الإصدارات المتكررة][https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/images/releases.png?raw=true]
ضع في اعتبارك أن تفسير هذا المقياس قد يكون صعبًا لأن الأنواع المختلفة من المشاريع والمواقف المختلفة قد تؤثر على ما إذا كان المشروع يحتاج إلى إيقاع إصدار أكثر أو أقل تواترًا. قد يشير وجود تواتر إصدار ثابت إلى مشروع أكثر استقرارًا أو نضجًا.
الخطوة الأولى: التشخيص
إن المكان المناسب لبدء تشخيص المشكلات المحتملة المتعلقة بممارسات الأمان الخاصة بمشروعك هو البدء في العمل من خلال معايير شارة مشروع OpenSSF. أثناء العمل عليها، من المحتمل أن تبدو مثل هذا المثال:
مصدر الصورة: https://www.bestpractices.dev/en/projects/40
كما ذكرنا سابقًا، يتضمن هذا أفضل ممارسات الأمان، ولكن أيضًا أفضل ممارسات هندسة البرمجيات العامة لتحسين مشروعك بعدة طرق. ستجد تحت كل من هذه الاقتراحات أسئلة تحتاج إلى الإجابة عليها وفقًا للمعايير المطلوبة لتلقي الشارة.
على سبيل المثال، فيما يلي بعض الأسئلة ضمن قسم الأمان:
سواء قررت متابعة الشارة أم لا، المعايير تعد الأدوات المستخدمة، وخاصة في أقسام الأمان والتقارير، طريقة جيدة للتفكير في كيفية فهم وتحسين أمان مشروعك. هناك أيضًا خيارات أخرى لإجراء تقييمات ذاتية للأمان لمشروعاتك، بما في ذلك التقييم الذاتي الذي أجرته CNCF استخدامات لمشاريعهم.
قد تكون الخطوة التالية في التشخيص هي إلقاء نظرة على تقرير Libyars الخاص بك مع التركيز على التبعيات الأكثر قدماً. عندما تستخدم تبعيات قديمة، فإن احتمالية تعرضك لمشاكل أمنية تزيد أربع مرات (Cox et al. 2015)، لذا فإن الحفاظ على التبعيات الخاصة بك محدثة يعد عاملاً مهمًا في تحسين أمان مشروعك. وكما ذكرنا سابقًا، توجد أحيانًا أسباب وجيهة لوجود التبعية خلف الإصدار الحالي: تغييرات جذرية، أو عدم توافق مع برنامجك/التبعيات الأخرى، أو مشكلات فنية أخرى. يتطلب التشخيص في هذه الحالة نظرة مدروسة وشاملة لمعرفة ما إذا كان هناك سبب وجيه لعدم تحديث التبعية.
لتشخيص ما إذا كنت تقوم بإصدار إصدارات في الوقت المناسب، يجب عليك إلقاء نظرة على تصحيحات الأمان التي أنشأتها على مدار العام الماضي. إذا قمت بإصدار إصدار في الوقت الذي قمت فيه بإصدار كل تصحيح أمان، فربما تكون في وضع جيد إلى حد ما. إذا تراكمت تصحيحات الأمان ولم يتم إصدارها في إصدار واحد، فربما يجب عليك إلقاء نظرة على سبب حدوث ذلك ومعرفة ما إذا كان بإمكانك تحسين عملية الإصدار الخاصة بك لإجراء إصدارات أكثر تواترًا عند إصلاح الثغرات الأمنية.
الخطوة 3: جمع بيانات إضافية إذا لزم الأمر
توفر الأمثلة المستخدمة في الخطوتين 1 و2 نقطة بداية يمكن توسيعها باستخدام أدوات ومقاييس إضافية. ستكون الخطوة التالية الجيدة في عملية التشخيص هي أيضًا تشغيل بطاقة قياس أداء OpenSSF، والذي يدخل في تفاصيل كبيرة مع عمليات التحقق التي تساعدك على العثور على المناطق التي قد يكون فيها مشروعك ضعيفًا عبر فئات الكود المصدر والبناء والتبعيات والاختبار وصيانة المشروع.
قد تلاحظ أنه لا يوجد مقياس في هذا الدليل يركز على الوقت اللازم لحل الثغرات الأمنية. إنه أمر مهم للغاية، ولكن قياسه أمر صعب لأنك تحتاج إلى أن تكون قادرًا على فصل مشكلات الأمان عن الأخطاء والمشكلات الأخرى مع ربط التقرير الأولي للثغرة بطلبات التغيير التي تم فيها إجراء الإصلاح. هناك العديد من الطرق للقيام بذلك، ولكن كيفية القيام بذلك تعتمد على الأدوات التي تستخدمها. في حين أنه قد لا يكون أفضل مقياس للبدء، إلا أنه شيء يجب أن تفكر في قياسه كواحدة من خطواتك التالية. توفر المقاييس الإضافية أدناه بداية جيدة لقياس ذلك.
مقاييس إضافية:
- بطاقة قياس أداء OpenSSF (ليس مقياس CHAOSS، بل أداة تجمع العديد من مقاييس الأمان)
- تغيير الطلبات
- مدة دقة الخلل
- مستند SPDX
- تبعيات كود المنبع
الخطوة 4: إجراء التحسينات
أحد أفضل الأماكن للبدء عند تحسين ممارسات الأمان الخاصة بك هو تأمين مستودع التعليمات البرمجية الخاص بك. يتضمن ذلك إدارة الوصول وحماية الفروع وإدارة المساهمات والمزيد. أفضل ممارسات تكوين منصة إدارة الكود المصدر OpenSSF يحتوي الدليل على قائمة من الاقتراحات مع روابط لتطبيقها لكل من GitHub وGitLab.
نقطة بداية جيدة أخرى هي إنشاء مستند سياسة أمان تفصيلي لمشروعك. وعادةً ما يتم العثور على هذا المستند في الأمن.md الملف الموجود في جذر المستودع الخاص بك. الغرض من هذه الوثيقة هو تقديم تعليمات للإبلاغ عن الثغرات الأمنية إلى جانب توثيق كيفية الاستجابة لهذه التقارير، بما في ذلك إدارة الحظرستساعدك هذه الوثيقة على تلبية متطلبات معايير إعداد التقارير في شارة أفضل ممارسات OpenSSF. هناك العديد من الأماكن التي يمكنك العثور فيها على تعليمات مفصلة لإنشاء سياسات الأمان، لذا لن نكرر هذه التفاصيل هنا. على سبيل المثال، دليل نقاط الضعف في OSS الخاص بـ OpenSSF يحتوي على مزيد من التفاصيل حول ما يجب أن يتضمنه هذا الملف بالإضافة إلى القوالب والإرشادات لتنفيذ سياسة الأمان، والتي تتجاوز مجرد إنشاء المستند وتتضمن تفاصيل حول البنية الأساسية والمتطلبات الأخرى لإدارة عملية الأمان.
كما ذكرنا، عندما تستخدم تبعيات قديمة، فمن المرجح أن تواجه مشكلات أمنية أربع مرات أكثر (كوكس وآخرون 2015)، لذا فإن الحفاظ على التبعيات الخاصة بك محدثة يعد عاملاً مهمًا في تحسين أمان مشروعك. تتطلب التبعيات نظرة مدروسة وشاملة لمعرفة ما إذا كان هناك سبب وجيه لعدم تحديث التبعية إلى جانب اختبار الإصدارات الأحدث للتأكد من أنك لا تكسر شيئًا آخر عند تحديث التبعية. في حين أن هناك أسبابًا وجيهة لتجنب تحديث تبعيات معينة، إلا أنه في معظم الحالات، لا يتم تحديث التبعيات لأنه قد يكون من الصعب تتبع موعد تحديثها. أداة مثل ديبيندابوت or تجديد الروبوت يمكن أن يساعد في تحديد بعض التبعيات وتحديثها تلقائيًا.
يمكن أن تساعد الوثائق الجيدة لإصلاحات الأمان في زيادة الوعي بإصلاحات الأمان المتاحة (إمتياز وآخرون 2022)، ومن المهم التأكد من أن هذه الإصلاحات تصل إلى الإصدار في الوقت المناسب. إذا كنت تقوم بإصدار تصحيحات أمان بشكل متكرر ولكنك لا تقوم بإصدارها بسرعة، فيجب عليك على الأرجح النظر في سبب حدوث ذلك ومعرفة ما إذا كان بإمكانك تحسين عملية الإصدار الخاصة بك لإجراء إصدارات أكثر تكرارًا عند إصلاح الثغرات الأمنية. من المهم أيضًا أن تحتوي ملاحظات الإصدار أو الوثائق الأخرى على تفاصيل حول إصلاحات الأمان لتسليط الضوء على أهمية التحديث للأشخاص الذين يستخدمون برنامجك.
كما ذكرنا سابقًا، فإن العمل على معايير شارة أفضل ممارسات OpenSSF يعد طريقة جيدة لإجراء تحسينات أمنية. عرض تفصيلي لصفحة المعايير لجميع المستويات يحتوي على تفسيرات وروابط بتفاصيل أكثر يمكن أن تساعدك على التحسن في كل من هذه المجالات.
الخطوة 5: مراقبة النتائج
نظرًا لأن الأمان موضوع معقد للغاية، فقد يكون من الصعب مراقبته. ومع ذلك، هناك بعض الأشياء التي يمكنك مراقبتها بمرور الوقت لمعرفة ما إذا كانت الإجراءات التي اتخذتها لتحسين الأمان لها تأثير. فيما يلي بعض الاقتراحات لمراقبة تقدمك:
- بطاقة قياس أداء OpenSSF:هل تحسنت درجاتك الإجمالية؟ هل تحسنت درجاتك في بعض المجالات الفردية التي حددتها للتحسين؟
- Libyears: هل تحسن رقم libyyear الخاص بك؟
- الإصدارات: هل تقوم بإصدار إصدار في كل مرة تقوم فيها بإنشاء تصحيح أمان؟
تحذيرات واعتبارات
- نظرًا لأن الأمان موضوع بالغ الأهمية، فقد تم تصميم هذا الدليل فقط لـ ابدأ بنفسك في طريقك نحو تحسين أمان مشروعك. ليس دليلا شاملا كل ما تحتاج إلى معرفته حول أمان مشروعات المصدر المفتوح. يمكنك معرفة المزيد من الروابط الموجودة في قسم القراءة الإضافية أدناه.
- قد تلاحظ أنه لا يوجد مقياس في هذا الدليل يركز على الوقت اللازم لحل الثغرات الأمنية. إنه أمر مهم للغاية، ولكن قياسه أمر صعب، لذا نوصي بتضمين هذا المقياس كواحدة من خطواتك التالية الأولى. راجع الخطوة 3 لمزيد من التفاصيل.
قراءة إضافية
- لدينا فيديو قصير (<4 دقائق) مخصصة لهذا الدليل على قناة CHAOSS على اليوتيوب.
- حلقة من برنامج CHAOSScast حول هذا الدليل.
- موقع OpenSSF يحتوي على مجموعة واسعة من الأدلة التفصيلية والتدريبات والموارد الأخرى.
- تشير إرشادات الأمان الخاصة بـ CNCF تعتبر الوثيقة أقل شمولاً بكثير من أدلة OpenSSF، ولكنها قد تكون أكثر فائدة إذا كنت بدأت للتو في تحسين الأمان لديك.
- دليل نقاط الضعف في OSS الخاص بـ OpenSSF يحتوي على دليل بالإضافة إلى قوالب وكتاب تشغيل يركز على تطوير سياسة الأمان وتنفيذها.
مشاركة الرأي
نود أن نحصل على تعليقات لمعرفة المزيد حول كيفية استخدام الأشخاص لأدلة ممارسي CHAOSS وكيف يمكننا تحسينها بمرور الوقت. يرجى إكمال هذا إستطلاع رأى قصير لتقديم ملاحظاتك.
المساهمين
ساهم الأشخاص التالية أسماؤهم في هذا الدليل:
- داون فوستر
- مات جيرمونبريز
- إميلي فوكس
مراجع حسابات
- كوكس جيه، بويرز إي، فان إيكلين إم، وفيسر جيه (2015، مايو). قياس مدى حداثة التبعية في أنظمة البرمجيات. في المؤتمر الدولي السابع والثلاثون لهندسة البرمجيات IEEE/ACM 2015 (المجلد 2، ص 109-118). معهد مهندسي الكهرباء والإلكترونيات.
- امتياز، ن.، خانوم، أ.، وويليامز، ل. (2022). مفتوح أم متخفي؟ سريع أم بطيء؟ خفيف أم ثقيل؟: التحقيق في إصدارات الأمان الخاصة بالحزم مفتوحة المصدر. معاملات IEEE في هندسة البرمجيات, 49(4)، 1540-1560.
- سينوبسيس (2024). تقرير تحليل المخاطر والأمان في المصادر المفتوحة.
- زروالي، أ.، مينس، ت.، غونزاليس - باراهونا، ج.، ديكان، أ.، كونستانتينو، إي.، وروبلز، ج. (2019). إطار عمل رسمي لقياس التأخر الفني في مستودعات المكونات وتطبيقه على npm. مجلة البرمجيات: التطور والعملية, 31(8) ، e2157.
أدلة ممارس CHAOSS هي وثائق حية مرخصة من معهد ماساتشوستس للتكنولوجيا (MIT)، ونحن نرحب بتعليقاتك ومدخلاتك. يمكنك اقتراح تعديلات على هذا المستند على https://github.com/chaoss/wg-data-science/blob/main/practitioner-guides/security.md