---
title: الإبلاغ الأمني
layout: about
---

# الإبلاغ الأمني

لمزيد من التفاصيل حول سياسات الأمان، راجع [هذه الصفحة](https://github.com/nodejs/node/security/policy).

## الإبلاغ عن ثغرة أمنية في Node.js

أبلغ عن الثغرات الأمنية في Node.js عبر [HackerOne](https://hackerone.com/nodejs).

> **ملاحظة:** إرسال بلاغ عبر HackerOne يتطلب حدًا أدنى من
> [Signal](https://docs.hackerone.com/en/articles/8369891-signal-impact) score قدره **1.0**.
> إذا كانت درجة Signal لديك أقل من هذا الحد، فتواصل بدلًا من ذلك مباشرة مع مشرفي إصدارات الأمان في Node.js
> عبر [OpenJS Foundation Slack](https://slack-invite.openjsf.org/).

عادةً يتم تأكيد استلام البلاغ خلال 5 أيام، وستتلقى ردًا أكثر تفصيلًا خلال 10 أيام
يوضح الخطوات التالية في التعامل مع ما أرسلته. قد تمتد هذه المدة عندما يكون متطوعو فرز البلاغات (triage)
في إجازة، خاصة في نهاية العام.

بعد الرد الأولي على البلاغ، سيحرص فريق الأمان على إبقائك على اطلاع بالتقدم نحو الإصلاح
والإعلان الكامل، وقد يطلب منك معلومات إضافية أو توضيحات حول المشكلة التي أبلغت عنها.

### برنامَج مكافآت الثغرات الأمنية في Node.js

يشارك مشروع Node.js في برنامج مكافآت الثغرات (bug bounty program) رسمي مخصص للباحثين الأمنيين والإفصاح العام المسؤول.
تتم إدارة البرنامج عبر منصة HackerOne. راجع [https://hackerone.com/nodejs](https://hackerone.com/nodejs)
لمزيد من التفاصيل.

## الإبلاغ عن bug في module من جهة خارجية

يجب الإبلاغ عن الثغرات الأمنية في 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) الموضحة أعلاه
  لضمان التعامل مع الإفصاح بطريقة متسقة.

## تلقي تحديثات الأمان

سيتم توزيع إشعارات الأمان عبر الطرق التالية:

- [Google Group](https://groups.google.com/group/nodejs-sec)
- [مدونة Node.js](/blog)

## التعليقات على هذه السياسة

إذا كانت لديك اقتراحات لتحسين هذه العملية، فيرجى زيارة مستودع
[nodejs/security-wg](https://github.com/nodejs/security-wg).

## أفضل ممارسات OpenSSF

<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' }} />
</a>

تعد شارة [Best Practices](https://github.com/coreinfrastructure/best-practices-badge) من Open Source Security Foundation (OpenSSF)
طريقة تتيح لمشاريع Free/Libre and Open Source Software (FLOSS) إظهار أنها تتبع أفضل الممارسات.
يمكن للمشاريع أن تمنح نفسها هذا التصديق طوعًا من خلال توضيح كيفية اتباعها لكل ممارسة.
ويستطيع مستخدمو الشارة تقييم مشاريع FLOSS التي تتبع أفضل الممارسات بسرعة، مما يزيد احتمال إنتاجها
لبرمجيات آمنة وذات جودة أعلى.
