translated security article

Author: aseel-aaa

_articles/ar/security-best-practices-for-your-project.md

@@ -2,22 +2,23 @@
 lang: ar
 untranslated: true
 title: أفضل ممارسات الأمان لمشروعك
-description: عزز مستقبل مشروعك من خلال بناء الثقة من خلال الممارسات الأمان الأساسية — من MFA و مسح الكود الى الادارة الأمنة للتبعيات  وإعداد تقارير الثغرات الأمنية الخاصة.
+description: عزز مستقبل مشروعك من خلال بناء الثقة من خلال الممارسات الأمان الأساسية — من MFA و مسح الكود الى الادارة الأمنة للتبعيات  وإعداد تقارير الثغرات الأمنية الخاصة
 class: security-best-practices
 order: -1
 image: /assets/images/cards/security-best-practices.png
 ---
 
 <div dir="rtl" markdown="1">
+
 بغض النظر عن الأخطاء والميزات الجديدة، فإن طول عمر المشروع لا يتوقف فقط على فائدته ولكن أيضًا على الثقة التي يكتسبها من مستخدميه.من الضروري جدا  اتخاذ تدابير أمنية قوية للحفاظ على هذه الثقة حية. فيما يلي بعض الإجراءات المهمة التي يمكنك اتخاذها لتحسين أمان مشروعك بشكل كبير.
 
 ## تأكد من أن جميع المساهمين أصحاب الامتيازات قد قاموا بتمكين المصادقة متعددة العوامل (MFA)
 
-### .ممثل  خبيث يتمكن من انتحال شخصية مساهم ذو امتيازات في مشروعك، سوف يتسبب في أضرار كارثية>>
+### ممثل  خبيث يتمكن من انتحال شخصية مساهم ذو امتيازات في مشروعك، سوف يتسبب في أضرار كارثية.
 
 بمجرد حصوله على حق الوصول المميز، يمكن لهذا الفاعل تعديل الكود الخاص بك لجعله يقوم بإجراءات غير مرغوب فيها (على سبيل المثال، تعدين العملة المشفرة),أو يمكنه نشر البرامج الضارة على البنية التحتية لمستخدميك،أو يمكنه الوصول إلى ملفات الكود علىGithub  لاستخراج الملكية الفكرية والبيانات الحساسة، بما في ذلك مفاتيح الوصول إلى خدمات أخرى. 
 
-MFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب. عندما تفعل يجب أن تسجل الدخول باسم مستخدمك وكلمة المرور بالاضافة الى شكل أخر من المصادقة أنت فقط تعرفه أو تستطيع الوصول اليه.
+MFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب. عندما تفعل يجب أن تسجل الدخول باسم مستخدمك وكلمة المرور بالاضافة الى شكل أخر من المصادقة أنت فقط تعرفه أو تستطيع الوصول إليه.
 
 ## قم بتأمين الكود الخاص بك كجزء من سير عمل التطوير الخاص بك
 
@@ -33,48 +34,43 @@ MFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب.
 
 * اختر واحدا يتكامل بسهولة مع الأدوات التي تستخدمها بالفعل, ومع عمليتك الحالية. على  سبيل المثال , من ألأفضل أن تكون التنبيهات متاحة كجزء من عملية وأداة مراحعة كودك الحالي بدلا من الانتقال الى أداة أحرى لرؤيتها.
 * احذر من الإيجابيات الكاذبة! أنت لا تريد أن تبطئك الأداة دون سبب!
-* تحقق من الميزات: بعض الأدوات قوية جدًا ويمكنها أن تتبع التلوث (taint tracking).
-* مثل : Github Codeql ,بعضها يقترح اصلاحات مقترحة من الAi,بعضها يجعل كتابة استعلامات مخصصة (custom queries) مثل : SemGrep.  
+* تحقّق من المزايا: بعض الأدوات قوية جدًا ويمكنها تنفيذ taint tracking (مثل GitHub CodeQL)، وبعضها يقترح AI-generated fix suggestions، وأخرى تسهّل كتابة custom queries (مثل SemGrep).
 
 ## لا تشارك أسرارك
 
-### بيانات حساسة مثل API keys,tokens, passwords قد تذهب بالخطأ في بعض الأحيان الى Github repository.
+### بيانات حساسة مثل API keys,tokens, passwords قد تذهب بالخطأ في بعض الأحيان إلى Github repository.
 
-تخيل هذا السيناريو : أنت المسؤول عن مشروع مفتوح المصدر مشهور مع مساهمين مطورين من جميع أنحاء العالم .
-في يوم ما, يضع مساهم بدون معرفة مفاتيح الApi لخدمة من خارج المشروع(third party service) في Github repository.بعد بضعة أيام شخص يجد هذه المفاتيح ويستخدمها للوصول للخدمة بدون اذن. يتم اختراق الخدمة، ويواجه مساهمو مشروعك فترة توقف، وتتضرر سمعة مشروعك.بصفتك المسؤول عن المشروع أنت الأن أمام مهام مرهقة لاسترجاع المفاتيح المخترقة,التحقق من الأفعال السيئة والضارة الذي قد يكون ارتكبها هذا المهاجم بهذه المفاتيح, تنبيه المستخدمين المتأثرين والقيام ببعض الاصلاحات.
+تخيّل هذا السيناريو: أنت الـ maintainer لمشروع مفتوح المصدر مشهور يشارك فيه مطورون من جميع أنحاء العالم، وفي أحد الأيام يقوم مساهم عن غير قصد بعمل commit يحتوي على بعض مفاتيح الـ API الخاصة بخدمة خارجية، وبعد أيام يجد أحدهم هذه المفاتيح ويستخدمها للوصول إلى الخدمة دون إذن، فتتعرض الخدمة للاختراق، ويواجه مستخدمو مشروعك فترة توقف، وتتضرر سمعة مشروعك، والآن بصفتك الـ maintainer عليك التعامل مع مهام مرهقة مثل إلغاء المفاتيح المخترقة، والتحقيق في الأفعال الضارة التي قد نفذها المهاجم باستخدامها، وإبلاغ المستخدمين المتأثرين، وتنفيذ الإصلاحات اللازمة.
 
-لمنع حوادث كهذه,حلول "secret scanning" موجودة لتساعد للكشف المبكر لأسرار كهذه في كودك. بعض الأدات ك Github Secret Scanning و  Trufflehog تتستطيع أن تمنعك من وضع هذه الأشياء على remote branches في المقام الأول, وبعض الأدوات ستزيل هذه الأسرار بشكل تلقائي لك.
+لمنع حوادث كهذه، حلول "secret scanning" موجودة لتساعد للكشف المبكر لأسرار كهذه في كودك. بعض الأدات ك Github Secret Scanning و  Trufflehog تتستطيع أن تمنعك من وضع هذه الأشياء على remote branches في المقام الأول, وبعض الأدوات ستزيل هذه الأسرار بشكل تلقائي لك.
 
-## تحقق وحدث الDependencies 
+## تحقّق من التبعيات الخاصة بك وقم بتحديثها
 
 ### Dependencies في مشروعك ممكن أن تحتوي على ثغرات قد تخترقه. القيام بتحديث الDependencies يدويا باليد ستكون مهمة مستهلكة للوقت.
 
 تخيل هذا: مشروع مبني على أساس قوي لمكتبة مستخدمة على نطاق واسع , لاحقا المكتبة تواجه مشكلة أمنية كبيرة.لكن الناس الذين بنوا المشروع باستخدامها لا يعرفون عن هذه المشكلة. تُترك بيانات المستخدم الحساسة مكشوفة عندما يستغل المهاجم هذا الضعف، فينقض عليها للاستيلاء عليها. هذا ليس مثالا نظريا انما ما حدث تماما في  في 2017.لقد فشلوا في تحديث Apache Struts dependeny الخاص بهم بعد اشعارهم عن وجود ثغرة في الخادم.لقد تم استغلال هذه الثغرة، وأثرت عملية الاختراق الشهيرة لشركة Equifax على بيانات 144 مليون مستخدم.  
 
 لمنع سيناريوهات كهذه, أدوات تحليل تكوين البرمجيات (SCA) مثل  Dependabot,Renvate تتحقق بشكل تلقائي من Dependencies الخاصة بك لأكثر الثغرات انتشارا في قواعد البيانات العامة مثل NVD,the Github Advisory Database ثم تنشأ pull requests لتحديثهم لأخر نسخ. مواكبة أخر التحديثات لل Dependencies الخاصة بمشروعك تحميه وتمنعه من المخاطر المحتملة.
 
-## تجنب تغيرات غير مرغوبة باستخدام protected branches
+## تجنّب التغيّرات غير المرغوبة باستخدام الفروع المحمية
 
-### يمكن أن يؤدي الوصول الغير  المقيد لmain branch الى تغييرات عرضية التي قد تنتج ثغرات أمنية وتعطل استقرار مشروعك
+### يمكن أن يؤدي الوصول غير المقيد لmain branch إلى تغييرات عرضية التي قد تنتج ثغرات أمنية وتعطل استقرار مشروعك
 
  مساهم جديد يحصل على حق التعديل على main branch وعرضا يقوم برفع تعديلات جديدة لم تختبر بعد. ثم يتم الكشف عن خلل أمني خطير بسبب التغييرات الأخيرة. لمنع مشاكل كهذه, قواعد حماية ال branch تضمن عدم رفع أو دمج تغييرات للmain branches دون الخضوع أولاً للمراجعات واجتياز فحوصات الحالة المحددة.أنت أكثر أمانًا وأفضل مع تطبيق هذا الإجراء الإضافي، مما يضمن جودة عالية في كل مرة.
 
 ## إنشاء آلية استقبال للإبلاغ عن نقاط الضعف
 
 ### من الجيد أن تتيح لمستخدميك الإبلاغ عن الأخطاء بسهولة، لكن السؤال الأهم هو: عندما يكون لهذا الخطأ تأثير أمني، كيف يمكنهم الإبلاغ عنه بأمان دون أن يجعلوك هدفًا محتملاً للمتسللين الخبيثين؟
 
-
-تخيّل هذا الموقف: باحث أمني يكتشف ثغرة في مشروعك، لكنه لا يجد طريقة واضحة أو آمنة للإبلاغ عنها. في غياب عملية مخصصة لذلك، قد يقوم بإنشاء issue أو مناقشة الأمر علنًا على وسائل التواصل الاجتماعي. حتى لو كانت نواياه حسنة وقدّم إصلاحًا للمشكلة، فإن قيامه بذلك من خلال عمل pull request سيجعل الآخرين يرون الثغرة قبل أن يتم دمج الإصلاح!
-هذا الكشف العلني سيعرّض الثغرة للمهاجمين قبل أن تتاح لك فرصة معالجتها، مما قد يؤدي إلى استغلال من نوع "صفر يوم" (zero-day exploit) يستهدف مشروعك ومستخدميه.
+تخيّل هذا: يكتشف باحث أمني ثغرة في مشروعك لكنه لا يجد طريقة واضحة أو آمنة للإبلاغ عنها، وبدون وجود عملية محددة، قد ينشئ issue عام أو يناقشها علنًا على وسائل التواصل الاجتماعي. حتى لو كانت نيته حسنة وقدّم إصلاحًا، إذا فعل ذلك من خلال public pull request، سيراه الآخرون قبل دمجه! هذا الكشف العلني سيعرّض الثغرة للمهاجمين قبل أن تتمكن من معالجتها، مما قد يؤدي إلى zero-day exploit يهاجم مشروعك ومستخدميه.
 
 ### سياسة الأمان
 
 لتجنب ذلك، قم بنشر سياسة أمان. تُعرّف سياسة الأمان في ملف `SECURITY.md`، وتوضح الخطوات اللازمة للإبلاغ عن المخاوف الأمنية، وتُنشئ عملية واضحة للكشف المنظم، وتحدد مسؤوليات فريق المشروع في معالجة القضايا المُبلّغ عنها. يمكن أن تكون سياسة الأمان بسيطة مثل: "يرجى عدم نشر التفاصيل في issue أو public pull request، أرسلوا لنا بريدًا إلكترونيًا خاصًا على[email protected]"، لكنها يمكن أن تتضمن أيضًا تفاصيل أخرى مثل متى يمكنهم توقع الحصول على رد منكم. أي شيء يمكن أن يُسهم في تعزيز فعالية وكفاءة عملية الكشف.
 
-### الإبلاغ الخاص عن الثغرات الأمنية
+### الإبلاغ عن الثغرات بشكل خاص
 
-في بعض المنصّات، يمكنك تبسيط وتعزيز عملية إدارة الثغرات الأمنية لديك من مرحلة الاستقبال إلى مرحلة النشر باستخدام القضايا الخاصة.في GitLab، يمكن القيام بذلك عبر Private Issues. أما فيGitHub، فيُطلق على ذلك اسم الإبلاغ الخاص عن الثغرات الأمنية Private Vulnerability Reporting PVR.تُتيح ميزة PVR للمسؤولين عن المشاريع استقبال تقارير الثغرات ومعالجتها بالكامل ضمن منصة GitHub.يقوم GitHub تلقائيًا بإنشاء نسخة خاصة(Private Fork) لكتابة الإصلاحات، بالإضافة إلى إصدار مسودة إشعار أمني (Security Advisory Draft).تبقى جميع هذه الإجراءات سرّية بالكامل حتى تقرر أنت الإفصاح عن المشكلة وإصدار الإصلاحات.
-وفي المرحلة الأخيرة، يتم نشر الإشعارات الأمنية (Security Advisories) لإبلاغ المستخدمين وحمايتهم من خلال أداة تحليل مكونات البرمجيات (SCA Tool).
+على بعض المنصات، يمكنك تبسيط وتعزيز عملية إدارة الثغرات الأمنية لديك، من الاستلام إلى النشر، باستخدام private issues. على GitLab يمكن فعل ذلك باستخدام private issues، أما على GitHub فهذه العملية تُسمى private vulnerability reporting (PVR). تتيح PVR للـ maintainers استقبال ومعالجة تقارير الثغرات كلها ضمن منصة GitHub، حيث يقوم GitHub تلقائيًا بإنشاء private fork لكتابة الإصلاحات، وdraft security advisory. كل هذا يبقى سريًا حتى تقرر الكشف عن الثغرات وإصدار الإصلاحات. لإغلاق الحلقة، سيتم نشر security advisories لإبلاغ وحماية جميع مستخدميك عبر أداة SCA الخاصة بهم.
 
 ## الخلاصة: خطوات قليلة منك، لكنها تُحدث فرقًا كبيرًا لمستخدميك.
 
@@ -87,5 +83,6 @@ MFA توفر طبقة اضافية من الأمان ضد سؤقة الحساب.
 تم كتابة هذا الدليل بواسطة [@nanzggits](https://github.com/nanzggits) & [@xcorail](https://github.com/xcorail) بمشاركة مساهمي من:
 
 [@JLLeitschuh](https://github.com/JLLeitschuh)
-[@intrigus-lgtm](https://github.com/intrigus-lgtm) + أخرون .
+[@intrigus-lgtm](https://github.com/intrigus-lgtm) + آخرون 
+
 </div>