| title | الإبلاغ الأمني |
|---|---|
| layout | about |
لمزيد من التفاصيل حول سياسات الأمان، راجع هذه الصفحة.
أبلغ عن الثغرات الأمنية في Node.js عبر HackerOne.
ملاحظة: إرسال بلاغ عبر HackerOne يتطلب حدًا أدنى من Signal score قدره 1.0. إذا كانت درجة Signal لديك أقل من هذا الحد، فتواصل بدلًا من ذلك مباشرة مع مشرفي إصدارات الأمان في Node.js عبر OpenJS Foundation Slack.
عادةً يتم تأكيد استلام البلاغ خلال 5 أيام، وستتلقى ردًا أكثر تفصيلًا خلال 10 أيام يوضح الخطوات التالية في التعامل مع ما أرسلته. قد تمتد هذه المدة عندما يكون متطوعو فرز البلاغات (triage) في إجازة، خاصة في نهاية العام.
بعد الرد الأولي على البلاغ، سيحرص فريق الأمان على إبقائك على اطلاع بالتقدم نحو الإصلاح والإعلان الكامل، وقد يطلب منك معلومات إضافية أو توضيحات حول المشكلة التي أبلغت عنها.
يشارك مشروع Node.js في برنامج مكافآت الثغرات (bug bounty program) رسمي مخصص للباحثين الأمنيين والإفصاح العام المسؤول. تتم إدارة البرنامج عبر منصة HackerOne. راجع https://hackerone.com/nodejs لمزيد من التفاصيل.
يجب الإبلاغ عن الثغرات الأمنية في third party modules إلى المسؤولين عن صيانتها (maintainers).
هذه هي سياسة الإفصاح الأمني الخاصة بـ Node.js:
-
يتم استلام البلاغ الأمني وتعيين مسؤول أساسي للتعامل معه. ينسق هذا الشخص عملية الإصلاح والإصدار. يتم التحقق من المشكلة على جميع إصدارات Node.js المدعومة. بعد تأكيدها، يتم تحديد قائمة بكل الإصدارات المتأثرة. تتم مراجعة الكود للبحث عن أي مشاكل مشابهة محتملة. ثم تُجهز الإصلاحات لكل الإصدارات المدعومة. لا تُرسل هذه الإصلاحات إلى المستودع العام (public repository) مباشرة، بل تبقى محليًا إلى حين الإعلان.
-
يتم اختيار تاريخ حظر نشر (embargo) مقترح لهذه الثغرة، ويتم طلب CVE (Common Vulnerabilities and Exposures (CVE®)) لها.
-
في تاريخ حظر النشر (embargo)، تُرسل نسخة من الإعلان إلى القائمة البريدية الأمنية (security mailing list) الخاصة بـ Node.js. تُدفع التغييرات إلى المستودع العام (public repository)، ويتم نشر builds جديدة على nodejs.org. خلال 6 ساعات من إشعار القائمة البريدية (mailing list)، تُنشر نسخة من التنبيه الأمني (advisory) على مدونة Node.js.
-
عادةً يتم تحديد تاريخ حظر النشر (embargo) بعد 72 ساعة من وقت إصدار CVE. لكن قد يختلف ذلك حسب خطورة bug أو صعوبة تطبيق الإصلاح.
-
قد تستغرق هذه العملية بعض الوقت، خاصة عندما نحتاج إلى التنسيق مع المسؤولين عن صيانة مشاريع أخرى (maintainers). سنحاول التعامل مع bug بأسرع ما يمكن، لكن يجب علينا اتباع عملية الإصدار (release process) الموضحة أعلاه لضمان التعامل مع الإفصاح بطريقة متسقة.
سيتم توزيع إشعارات الأمان عبر الطرق التالية:
إذا كانت لديك اقتراحات لتحسين هذه العملية، فيرجى زيارة مستودع nodejs/security-wg.
<a href="https://bestpractices.coreinfrastructure.org/projects/29" style={{ display: 'inline-flex' }}>
<img alt="شارة OpenSSF" src="https://bestpractices.coreinfrastructure.org/projects/29/badge" style={{ display: 'inline' }} />
تعد شارة Best Practices من Open Source Security Foundation (OpenSSF) طريقة تتيح لمشاريع Free/Libre and Open Source Software (FLOSS) إظهار أنها تتبع أفضل الممارسات. يمكن للمشاريع أن تمنح نفسها هذا التصديق طوعًا من خلال توضيح كيفية اتباعها لكل ممارسة. ويستطيع مستخدمو الشارة تقييم مشاريع FLOSS التي تتبع أفضل الممارسات بسرعة، مما يزيد احتمال إنتاجها لبرمجيات آمنة وذات جودة أعلى.