سياسة الإفصاح عن الثغرات

لمحة سريعة

توضّح هذه الصفحة سياسة الإفصاح المنسّق عن الثغرات في ⁨NextPDF.⁩ وتبيّن كيفية التواصل مع المشرفين عبر قناة خاصة، والجدول الزمني المتوقع للاستجابة، وآلية عمل فترات الحظر.

حدود النطاق. تمثّل سياسة الإفصاح التزامًا إجرائيًا، وليست ضمانًا لجدول زمني أو نتيجة. الأهداف المذكورة أدناه هي التزامات يبذلها المشرفون بحسن نية تجاهك بصفتك مُبلِّغًا؛ فهي تصف العملية التي يتّبعها المشروع، ولا تُعد وعدًا تعاقديًا بأن أي بلاغ بعينه سيُؤكَّد استلامه، أو سيُفرز، أو سيُصلح، أو سيُفصح عنه بحلول تاريخ معيّن. يُتفاوض على توقيت الإفصاح المنسّق ولا يُضمن من جانب واحد.

التثبيت

لا ينطبق. لا تحتاج إلى تثبيت أي شيء للإبلاغ عن ثغرة. تُنشر واجهة الاتصال القابلة للقراءة آليًا في /.well-known/security.txt (طلب التعليقات (⁨RFC⁩) 9116)، ويُعد ملف SECURITY.md في المستودع السياسة المرجعية القابلة للقراءة البشرية.

نظرة مفاهيمية عامة

تطبّق هذه السياسة الإفصاح المنسّق عن الثغرات وفق ما يحدّده ⁨ISO/IEC 29147⁩ وعملية المعالجة الموضّحة في ⁨ISO/IEC 30111⁩ (iso_iec_30111#x9.x43.p2): الاستلام عبر قناة خاصة، والفرز وتقييم الخطورة، والمعالجة خلال فترة الحظر، والإفصاح العلني المنسّق. إذا أثّرت ثغرة في عدة جهات مورّدة، تنسّق الأطراف المتأثرة توقيت النشرة الأمنية بدلًا من تحديده من جانب واحد (iso_iec_29147#x3.x110.p13).

وتتوافق العملية أيضًا مع التزامات الجهة المصنّعة المتعلقة بمعالجة الثغرات الواردة في قانون المرونة السيبرانية (⁨CRA⁩) للاتحاد الأوروبي (⁨EU⁩) (eu_cra#x1.p191) وممارسة “الاستجابة للثغرات” في إطار تطوير البرمجيات الآمن (⁨SSDF⁩) التابع للمعهد الوطني للمعايير والتقنية (⁨NIST⁩) (nist_sp_800_218#x15). ويصف كل منهما هذه الواجبات بوصفها واجبات إجرائية قابلة للتكرار، وليست ضمانًا لأن أي نتيجة فردية مكفولة.

واجهة ⁨API⁩

لا ينطبق. الإفصاح عملية، لا واجهة برمجة تطبيقات (⁨API⁩). واجهة الاكتشاف القابلة للقراءة آليًا هي ملف security.txt وفق ⁨RFC 9116⁩؛ وتقرأ الأدوات حقلَي Contact: وExpires: فيه. لا تكرّر هذه الصفحة من محتويات ذلك الملف إلا القنوات المذكورة أدناه.

عيّنة برمجية — البدء السريع

لا ينطبق. لا توجد شيفرة لتشغيلها عند الإبلاغ عن ثغرة. استخدم قناة خاصة:

نشرات ⁨GitHub⁩ الأمنية (المفضّلة — مشفّرة أثناء التخزين، مع سجل تدقيق): افتح مسودة نشرة أمنية في تبويب ⁨GitHub Security⁩ الخاص بالمشروع.
البريد الإلكتروني: [email protected] مع إضافة [SECURITY] إلى الموضوع. إذا احتجت إلى تشفير من الطرف إلى الطرف ولم يكن مفتاح ⁨OpenPGP⁩ منشورًا بعد في security.txt، فاستخدم قناة نشرة ⁨GitHub⁩ الأمنية بدلًا من ذلك.

لا تُبلّغ عبر المشكلات العامة أو القوائم البريدية العامة أو وسائل التواصل الاجتماعي أو المحادثات. الإفصاح العلني قبل توفّر إصلاح يعرّض المستخدمين على الإصدارات غير المُرقَّعة للخطر.

عيّنة برمجية — بيئة الإنتاج

لا ينطبق.

الحالات الحدّية والمزالق

الأهداف التزامات، وليست اتفاقيات مستوى خدمة (⁨SLAs⁩). يبيّن الجدول الزمني أدناه ما يسعى المشروع إلى تحقيقه. قد تستغرق المشكلة المعقّدة والمتعددة المكوّنات، أو تلك التي تتطلب تنسيقًا مع جهات أعلى في السلسلة، وقتًا أطول؛ ويبقي المشروع المُبلِّغ على اطّلاع.
مدة الحظر قابلة للتفاوض، مع وجود حدٍّ أقصى. يمتد الحظر الافتراضي من الفرز إلى إصدار الإصلاح. إذا كنت بحاجة إلى مدة أطول، فاطلبها صراحةً عند فتح النشرة الأمنية. بعد بلوغ الحدّ الأقصى، سينشر المشروع النشرة الأمنية سواء توفّر إصلاح أم لا، تماشيًا مع أعراف الإفصاح المنسّق في القطاع. يحمي هذا المستخدمين من حجب النشرة الأمنية إلى أجل غير مسمّى.
الخطورة تحكم الجدول الزمني. تُعالَج المشكلة الحرجة المُستغَلّة فعليًا وفق جدول زمني مضغوط؛ بخلاف اقتراح التحصين منخفض الخطورة. تُقيَّم الخطورة أثناء الفرز ويمكن مراجعتها.
تخصيص معرّف الثغرات والتعرّضات الشائعة (⁨CVE⁩) جزء من الفرز. يطلب المشرف معرّف ⁨CVE⁩ من خلال تسجيل المشروع كجهة ترقيم ⁨CVE⁩ (⁨CNA⁩) عبر نشرات ⁨GitHub⁩ الأمنية كجزء من خطوة الفرز؛ ولا يحتاج المُبلِّغ إلى طلب معرّف منفصل.

الأداء

لا ينطبق.

ملاحظات أمنية

أهداف الجدول الزمني للاستجابة هي التزامات تجاه المُبلِّغين، وتشكّل المرجع الأساسي لمعالجة الثغرات في المشروع. وهي أهداف، وليست ضمانات:

المرحلة	الهدف
تأكيد الاستلام	خلال 1–2 يوم عمل
الفرز الأولي + تقييم الخطورة	خلال ~5 أيام عمل / 7 أيام تقويمية
تطوير الرقعة + مراجعة خاصة	عادةً 14 يوم عمل؛ و30–90 يومًا لثغرات ⁨CVE⁩ المعقّدة المؤكَّدة بحسب الخطورة
تخصيص معرّف ⁨CVE⁩ (في حال القبول)	بالتزامن مع الرقعة، عبر قناة ⁨CNA⁩ في ⁨GitHub⁩
الإفصاح العلني المنسّق	عند إصدار الرقعة، في تاريخ يُحدَّد بالاشتراك مع المُبلِّغ
الحظر (من الفرز إلى الإصدار)	الافتراضي ~90 يومًا، يُختصر في حال الاستغلال الفعلي، وقابل للتمديد بناءً على طلب صريح حتى حدٍّ أقصى ثابت

يمكن للمراجعين التحقق من قواعد هذه العملية:

القناة الخاصة أولًا. لا تُقبل أي قناة عامة لتلقي البلاغات. القناتان الوحيدتان المقبولتان هما نشرة ⁨GitHub⁩ الأمنية والبريد الإلكتروني الأمني.
منسّق، لا أحادي الجانب. يُتفاوض على توقيت الإفصاح مع المُبلِّغ وأي جهات مورّدة متأثرة بالاشتراك (iso_iec_29147#x3.x110.p13).
حظر محدود المدة. للحظر مدة افتراضية وحدٌّ أقصى صارم؛ ولا يحجب المشروع نشرة أمنية إلى أجل غير مسمّى.
الإسناد عند الطلب. يُنسب الفضل إلى الباحثين بعد رفع الحظر، ما لم يطلبوا عدم الكشف عن هويتهم.

تصف هذه العبارات العملية التي يلتزم المشروع باتّباعها. وهي لا تضمن أن أي بلاغ بعينه سيؤدي إلى إصلاح، أو معرّف ⁨CVE⁩، أو إفصاح بحلول تاريخ معيّن.

المطابقة

هذه الصفحة ليست ملفًا للمطابقة. تتوافق السياسة مع ⁨ISO/IEC 29147⁩ و⁨ISO/IEC 30111⁩ والواجبات الإجرائية لكلٍّ من ⁨CRA⁩ و⁨SSDF⁩ المذكورة أعلاه؛ وقد استُخدمت عبارة “متوافقة مع” قصدًا. لا يدّعي المشروع الحصول على شهادة وفق أيٍّ من هذه الأطر. فهذه الأطر تحدّد عملية سليمة؛ وتوثّق هذه الصفحة التزام المشروع بتشغيل عملية من هذا النوع.

انظر أيضًا

مركز الثقة
نموذج التهديدات للمحرّك
نموذج أمان التوقيع والتشفير
ملف SECURITY.md في المستودع و/.well-known/security.txt (⁨RFC 9116⁩)