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

تأكد من أن جميع المساهمين أصحاب الامتيازات قد قاموا بتمكين المصادقة متعددة العوامل (MFA)

ممثل خبيث يتمكن من انتحال شخصية مساهم ذو امتيازات في مشروعك، سوف يتسبب في أضرار كارثية.

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

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

قم بتأمين الكود الخاص بك كجزء من سير عمل التطوير الخاص بك

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

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

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

كيف تختار أداة SAST تأكد من التعليمات: بعض الأدوات مجانية للمشاريع مفتوحة المصدر. على سبيل المثال Github CodeQl, SemGrep. تأكد من تغطيتها للغاتك البرمجة.

• اختر واحدا يتكامل بسهولة مع الأدوات التي تستخدمها بالفعل, ومع عمليتك الحالية. على سبيل المثال , من ألأفضل أن تكون التنبيهات متاحة كجزء من عملية وأداة مراحعة كودك الحالي بدلا من الانتقال الى أداة أحرى لرؤيتها.
• احذر من الإيجابيات الكاذبة! أنت لا تريد أن تبطئك الأداة دون سبب!
• تحقّق من المزايا: بعض الأدوات قوية جدًا ويمكنها تنفيذ taint tracking (مثل GitHub CodeQL)، وبعضها يقترح AI-generated fix suggestions، وأخرى تسهّل كتابة custom queries (مثل SemGrep).

لا تشارك أسرارك

بيانات حساسة مثل API keys,tokens, passwords قد تذهب بالخطأ في بعض الأحيان إلى Github repository.

تخيّل هذا السيناريو: أنت الـ maintainer لمشروع مفتوح المصدر مشهور يشارك فيه مطورون من جميع أنحاء العالم، وفي أحد الأيام يقوم مساهم عن غير قصد بعمل commit يحتوي على بعض مفاتيح الـ API الخاصة بخدمة خارجية، وبعد أيام يجد أحدهم هذه المفاتيح ويستخدمها للوصول إلى الخدمة دون إذن، فتتعرض الخدمة للاختراق، ويواجه مستخدمو مشروعك فترة توقف، وتتضرر سمعة مشروعك، والآن بصفتك الـ maintainer عليك التعامل مع مهام مرهقة مثل إلغاء المفاتيح المخترقة، والتحقيق في الأفعال الضارة التي قد نفذها المهاجم باستخدامها، وإبلاغ المستخدمين المتأثرين، وتنفيذ الإصلاحات اللازمة.

لمنع حوادث كهذه، حلول “secret scanning” موجودة لتساعد للكشف المبكر لأسرار كهذه في كودك. بعض الأدات ك Github Secret Scanning و Trufflehog تتستطيع أن تمنعك من وضع هذه الأشياء على remote branches في المقام الأول, وبعض الأدوات ستزيل هذه الأسرار بشكل تلقائي لك.

تحقّق من التبعيات الخاصة بك وقم بتحديثها

Dependencies في مشروعك ممكن أن تحتوي على ثغرات قد تخترقه. القيام بتحديث الDependencies يدويا باليد ستكون مهمة مستهلكة للوقت.

تخيل هذا: مشروع مبني على أساس قوي لمكتبة مستخدمة على نطاق واسع , لاحقا المكتبة تواجه مشكلة أمنية كبيرة.لكن الناس الذين بنوا المشروع باستخدامها لا يعرفون عن هذه المشكلة. تُترك بيانات المستخدم الحساسة مكشوفة عندما يستغل المهاجم هذا الضعف، فينقض عليها للاستيلاء عليها. هذا ليس مثالا نظريا انما ما حدث تماما في في 2017.لقد فشلوا في تحديث Apache Struts dependeny الخاص بهم بعد اشعارهم عن وجود ثغرة في الخادم.لقد تم استغلال هذه الثغرة، وأثرت عملية الاختراق الشهيرة لشركة Equifax على بيانات 144 مليون مستخدم.

لمنع سيناريوهات كهذه, أدوات تحليل تكوين البرمجيات (SCA) مثل Dependabot,Renvate تتحقق بشكل تلقائي من Dependencies الخاصة بك لأكثر الثغرات انتشارا في قواعد البيانات العامة مثل NVD,the Github Advisory Database ثم تنشأ pull requests لتحديثهم لأخر نسخ. مواكبة أخر التحديثات لل Dependencies الخاصة بمشروعك تحميه وتمنعه من المخاطر المحتملة.

تجنّب التغيّرات غير المرغوبة باستخدام الفروع المحمية

يمكن أن يؤدي الوصول غير المقيد لmain branch إلى تغييرات عرضية التي قد تنتج ثغرات أمنية وتعطل استقرار مشروعك

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

إنشاء آلية استقبال للإبلاغ عن نقاط الضعف

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

تخيّل هذا: يكتشف باحث أمني ثغرة في مشروعك لكنه لا يجد طريقة واضحة أو آمنة للإبلاغ عنها، وبدون وجود عملية محددة، قد ينشئ issue عام أو يناقشها علنًا على وسائل التواصل الاجتماعي. حتى لو كانت نيته حسنة وقدّم إصلاحًا، إذا فعل ذلك من خلال public pull request، سيراه الآخرون قبل دمجه! هذا الكشف العلني سيعرّض الثغرة للمهاجمين قبل أن تتمكن من معالجتها، مما قد يؤدي إلى zero-day exploit يهاجم مشروعك ومستخدميه.

سياسة الأمان

لتجنب ذلك، قم بنشر سياسة أمان. تُعرّف سياسة الأمان في ملف SECURITY.md، وتوضح الخطوات اللازمة للإبلاغ عن المخاوف الأمنية، وتُنشئ عملية واضحة للكشف المنظم، وتحدد مسؤوليات فريق المشروع في معالجة القضايا المُبلّغ عنها. يمكن أن تكون سياسة الأمان بسيطة مثل: “يرجى عدم نشر التفاصيل في issue أو public pull request، أرسلوا لنا بريدًا إلكترونيًا خاصًا علىsecurity@example.com”، لكنها يمكن أن تتضمن أيضًا تفاصيل أخرى مثل متى يمكنهم توقع الحصول على رد منكم. أي شيء يمكن أن يُسهم في تعزيز فعالية وكفاءة عملية الكشف.

الإبلاغ عن الثغرات بشكل خاص

على بعض المنصات، يمكنك تبسيط وتعزيز عملية إدارة الثغرات الأمنية لديك، من الاستلام إلى النشر، باستخدام private issues. على GitLab يمكن فعل ذلك باستخدام private issues، أما على GitHub فهذه العملية تُسمى private vulnerability reporting (PVR). تتيح PVR للـ maintainers استقبال ومعالجة تقارير الثغرات كلها ضمن منصة GitHub، حيث يقوم GitHub تلقائيًا بإنشاء private fork لكتابة الإصلاحات، وdraft security advisory. كل هذا يبقى سريًا حتى تقرر الكشف عن الثغرات وإصدار الإصلاحات. لإغلاق الحلقة، سيتم نشر security advisories لإبلاغ وحماية جميع مستخدميك عبر أداة SCA الخاصة بهم.

الخلاصة: خطوات قليلة منك، لكنها تُحدث فرقًا كبيرًا لمستخدميك.

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

المساهمون

جزيل الشكر لجميع المشرفين الذين شاركوا تجاربهم ونصائحهم معنا في إعداد هذا الدليل!

تم كتابة هذا الدليل بواسطة @nanzggits & @xcorail بمشاركة مساهمي من:

@JLLeitschuh @intrigus-lgtm + آخرون

رجوع للأدلة