|
| 1 | +--- |
| 2 | +title: الإبلاغ الأمني |
| 3 | +layout: about |
| 4 | +--- |
| 5 | + |
| 6 | +# الإبلاغ الأمني |
| 7 | + |
| 8 | +لمزيد من التفاصيل حول سياسات الأمان، راجع [هذه الصفحة](https://github.com/nodejs/node/security/policy). |
| 9 | + |
| 10 | +## الإبلاغ عن ثغرة أمنية في Node.js |
| 11 | + |
| 12 | +أبلغ عن الثغرات الأمنية في Node.js عبر [HackerOne](https://hackerone.com/nodejs). |
| 13 | + |
| 14 | +> **ملاحظة:** إرسال بلاغ عبر HackerOne يتطلب حدًا أدنى من |
| 15 | +> [Signal](https://docs.hackerone.com/en/articles/8369891-signal-impact) score قدره **1.0**. |
| 16 | +> إذا كانت درجة Signal لديك أقل من هذا الحد، فتواصل بدلًا من ذلك مباشرة مع مشرفي إصدارات الأمان في Node.js |
| 17 | +> عبر [OpenJS Foundation Slack](https://slack-invite.openjsf.org/). |
| 18 | +
|
| 19 | +عادةً يتم تأكيد استلام البلاغ خلال 5 أيام، وستتلقى ردًا أكثر تفصيلًا خلال 10 أيام |
| 20 | +يوضح الخطوات التالية في التعامل مع ما أرسلته. قد تمتد هذه المدة عندما يكون متطوعو فرز البلاغات (triage) |
| 21 | +في إجازة، خاصة في نهاية العام. |
| 22 | + |
| 23 | +بعد الرد الأولي على البلاغ، سيحرص فريق الأمان على إبقائك على اطلاع بالتقدم نحو الإصلاح |
| 24 | +والإعلان الكامل، وقد يطلب منك معلومات إضافية أو توضيحات حول المشكلة التي أبلغت عنها. |
| 25 | + |
| 26 | +### برنامَج مكافآت الثغرات الأمنية في Node.js |
| 27 | + |
| 28 | +يشارك مشروع Node.js في برنامج مكافآت الثغرات (bug bounty program) رسمي مخصص للباحثين الأمنيين والإفصاح العام المسؤول. |
| 29 | +تتم إدارة البرنامج عبر منصة HackerOne. راجع [https://hackerone.com/nodejs](https://hackerone.com/nodejs) |
| 30 | +لمزيد من التفاصيل. |
| 31 | + |
| 32 | +## الإبلاغ عن bug في module من جهة خارجية |
| 33 | + |
| 34 | +يجب الإبلاغ عن الثغرات الأمنية في third party modules إلى المسؤولين عن صيانتها (maintainers). |
| 35 | + |
| 36 | +## سياسة الإفصاح |
| 37 | + |
| 38 | +هذه هي سياسة الإفصاح الأمني الخاصة بـ Node.js: |
| 39 | + |
| 40 | +- يتم استلام البلاغ الأمني وتعيين مسؤول أساسي للتعامل معه. ينسق هذا الشخص عملية الإصلاح والإصدار. |
| 41 | + يتم التحقق من المشكلة على جميع إصدارات Node.js المدعومة. بعد تأكيدها، يتم تحديد قائمة بكل الإصدارات المتأثرة. |
| 42 | + تتم مراجعة الكود للبحث عن أي مشاكل مشابهة محتملة. ثم تُجهز الإصلاحات لكل الإصدارات المدعومة. |
| 43 | + لا تُرسل هذه الإصلاحات إلى المستودع العام (public repository) مباشرة، بل تبقى محليًا إلى حين الإعلان. |
| 44 | + |
| 45 | +- يتم اختيار تاريخ حظر نشر (embargo) مقترح لهذه الثغرة، ويتم طلب CVE |
| 46 | + (Common Vulnerabilities and Exposures (CVE®)) لها. |
| 47 | + |
| 48 | +- في تاريخ حظر النشر (embargo)، تُرسل نسخة من الإعلان إلى القائمة البريدية الأمنية (security mailing list) الخاصة بـ Node.js. |
| 49 | + تُدفع التغييرات إلى المستودع العام (public repository)، ويتم نشر builds جديدة على nodejs.org. |
| 50 | + خلال 6 ساعات من إشعار القائمة البريدية (mailing list)، تُنشر نسخة من التنبيه الأمني (advisory) على مدونة Node.js. |
| 51 | + |
| 52 | +- عادةً يتم تحديد تاريخ حظر النشر (embargo) بعد 72 ساعة من وقت إصدار CVE. لكن قد يختلف ذلك حسب خطورة bug |
| 53 | + أو صعوبة تطبيق الإصلاح. |
| 54 | + |
| 55 | +- قد تستغرق هذه العملية بعض الوقت، خاصة عندما نحتاج إلى التنسيق مع المسؤولين عن صيانة مشاريع أخرى (maintainers). |
| 56 | + سنحاول التعامل مع bug بأسرع ما يمكن، لكن يجب علينا اتباع عملية الإصدار (release process) الموضحة أعلاه |
| 57 | + لضمان التعامل مع الإفصاح بطريقة متسقة. |
| 58 | + |
| 59 | +## تلقي تحديثات الأمان |
| 60 | + |
| 61 | +سيتم توزيع إشعارات الأمان عبر الطرق التالية: |
| 62 | + |
| 63 | +- [Google Group](https://groups.google.com/group/nodejs-sec) |
| 64 | +- [مدونة Node.js](/blog) |
| 65 | + |
| 66 | +## التعليقات على هذه السياسة |
| 67 | + |
| 68 | +إذا كانت لديك اقتراحات لتحسين هذه العملية، فيرجى زيارة مستودع |
| 69 | +[nodejs/security-wg](https://github.com/nodejs/security-wg). |
| 70 | + |
| 71 | +## أفضل ممارسات OpenSSF |
| 72 | + |
| 73 | +<a href="https://bestpractices.coreinfrastructure.org/projects/29" style={{ display: 'inline-flex' }}> |
| 74 | + |
| 75 | + |
| 76 | + |
| 77 | + <img alt="شارة OpenSSF" src="https://bestpractices.coreinfrastructure.org/projects/29/badge" style={{ display: 'inline' }} /> |
| 78 | +</a> |
| 79 | + |
| 80 | +تعد شارة [Best Practices](https://github.com/coreinfrastructure/best-practices-badge) من Open Source Security Foundation (OpenSSF) |
| 81 | +طريقة تتيح لمشاريع Free/Libre and Open Source Software (FLOSS) إظهار أنها تتبع أفضل الممارسات. |
| 82 | +يمكن للمشاريع أن تمنح نفسها هذا التصديق طوعًا من خلال توضيح كيفية اتباعها لكل ممارسة. |
| 83 | +ويستطيع مستخدمو الشارة تقييم مشاريع FLOSS التي تتبع أفضل الممارسات بسرعة، مما يزيد احتمال إنتاجها |
| 84 | +لبرمجيات آمنة وذات جودة أعلى. |
0 commit comments