الخلاصة

  • تقترح المراجعة 00 من draft-bruhns-securitytxt-product-security، المنشورة في 10 سبتمبر 2026، الحقلين الاختياريين Product-Security وProduct-Security-Policy ضمن صيغة RFC 9116.
  • يشير الأول إلى عناوين URI لتلقي ثغرات المنتجات مع إمكان تكراره وترتيبه حسب الأفضلية، ويشير الثاني إلى سياسة عبر HTTPS تشرح النطاق والفرز والإفصاح.
  • الوثيقة Internet-Draft فردية، لا وثيقة معتمدة من مجموعة عمل ولا معياراً أقره IETF. ولا يسجل جدول IANA الحالي أياً من الاسمين.
  • فصل صندوق المنتج عن صندوق البنية التحتية يحسن الخطوة الأولى، لكنه لا يربط الطراز أو الإصدار أو البناء المعاد توزيعه بالجهة التي قبلت مسؤوليته.

رقم القضية لا يجيب عن سؤال الملكية

لنفترض أن باحثاً اكتشف خللاً في برنامج ثابت لجهاز يباع باسم معروف. يستضيف نطاق العلامة ملف security.txt، ويقود الملف إلى قناة أمن منتجات تستجيب فوراً. بعد إنشاء القضية يتضح أن الطراز صُنّع بترخيص، وأن الفرع البرمجي القديم يديره شريك إقليمي، وأن المكوّن المصاب قادم من مشروع مستقل.

لم يفشل البريد في هذا السيناريو. الذي لم يُحسم هو نطاق المسؤولية. عنوان الاتصال يحدد مكان البداية، لكنه لا يحدد من يستطيع تعديل الشفرة أو إصدار التصحيح أو تنسيق توقيت الكشف. وقد تكون هذه السلطات موزعة بين جهات عدة.

يبقى اسم المنتج على العلبة مدة أطول من عقود الصيانة. وقد ينتقل خط إنتاج بعد استحواذ، أو يباع تحت أكثر من علامة، أو يخرج إصدار من الدعم فيما يظل مستخدماً. لا يستطيع عنوان ويب واحد أن يلخص هذه التحولات بمجرد تخصيص صندوق وارد.

ما تطلبه المراجعة 00 بدقة

تعرض صفحة Datatracker وثيقة Product Security Fields for security.txt بوصفها Internet-Draft فردية. ولا يظهر في سجلها عند موعد الرصد سوى المراجعة 00 المؤرخة في 10 سبتمبر. نشر المسودة يفتح باب النقاش؛ لا يعني تبني مجموعة عمل أو تأييد IETF أو صدور RFC.

يسمح نص المراجعة بتكرار Product-Security. يحمل كل ظهور عنوان URI للإبلاغ عن ثغرات المنتجات، ويخضع لقيود URI نفسها الخاصة بحقل Contact. ويعبر ترتيب الحقول عن تفضيل الناشر.

أما Product-Security-Policy فيظهر مرة واحدة ويشير إلى مورد HTTPS. ينبغي للسياسة أن تشرح المنتجات المشمولة، وآليات تأكيد الاستلام والفرز، وتوقعات زمن الاستجابة، وقواعد الإفصاح والحظر المؤقت، وإمكان البلاغ المجهول، والضمانات للبحث حسن النية.

هذه القائمة تجعل النطاق جزءاً صريحاً من الحوكمة. لكنها لا تنشئ معرفاً عالمياً للمنتج ولا تختبر تطابق السياسة مع الطراز والإصدار اللذين ذكرهما الباحث. الرابط يخصص مكاناً للشرح ولا يقدم البرهان بذاته.

طلب IANA ليس تسجيلاً منجزاً

تطلب فقرة IANA Considerations في المسودة إضافة الاسمين وفق سياسة Expert Review. لكن سجل حقول security.txt لدى IANA لا يحتويهما عند موعد الرصد. ويضم الحقول القائمة مثل Contact وExpires وCanonical وEncryption وPolicy وPreferred-Languages، إلى جانب امتدادات مسجلة مثل CSAF وBug-Bounty وHiring.

الترتيب المؤسسي مهم. المسودة تصف حالة مطلوبة للسجل مستقبلاً ولا تغير حالته الحالية. يبين RFC 8126 أن Expert Review تعني تقييم الطلب على يد خبراء معينين وفق سياسة السجل. لا يحل تقديم المسودة محل قرارهم.

يمكن إجراء تجارب محلية من دون تعطيل المحللات القديمة. يلزم RFC 9116 المحلل بتجاهل حقول الامتداد التي لا يعرفها. ولهذا تنصح المسودة الجديدة بأن يظل Contact قادراً على استقبال بلاغات المنتجات. يبقى الطريق الاحتياطي مفتوحاً، لكن ذلك لا يثبت أن الامتداد المقترح صار متوافقاً على نطاق واسع.

أصل الويب لا يساوي سجل المنتجات

يربط RFC 9116 النطاق العادي بالموضع الذي استُرجع منه الملف. فالملف المكتشف لنطاق أو عنوان IP ينطبق على ذلك المورد، ولا يمتد تلقائياً إلى النطاقات الأعلى أو الفرعية. ويمكن للمؤسسة أن تنشر معلومات لمنتجاتها وخدماتها، لكن الصيغة لا تنشئ قائمة للطرازات والإصدارات والمشرفين.

لدى الباحث بيانات مختلفة: اسم الحزمة، رقم الطراز، مجال الأرقام التسلسلية، الإصدار، البناء، فرع البرنامج الثابت أو commit. ولدى الناشر أصل ويب وسياسة وقوائم انتظار. يجب حفظ القاعدة التي وصلت الطرفين ببعضهما؛ وإلا فلن يرى المدقق لاحقاً إلا رسالة وصلت إلى نطاق العلامة.

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

سلامة النشر لا تثبت القدرة على الإصلاح

يفرض RFC 9116 حقل Expires لكشف معلومات الاتصال القديمة، ويوفر Canonical لتحديد الموضع المقصود، ويوصي بالتوقيع. فالطرف الذي يعبث بخادم النشر يستطيع تحويل الباحث إلى عنوان يسيطر عليه.

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

ويفصل RFC أيضاً بين اكتشاف القناة والإذن بالاختبار. وجود security.txt أو غيابه لا يمنح الإذن ولا يمنعه. يمكن لسياسة المنتج أن تصف ضمانات البحث حسن النية، لكن نطاق المنتج والفعل والولاية القضائية يُقرأ من النص الفعلي ولا يُستنتج من اسم الحقل.

إيصال يربط القطعة بمن تسلمها

يبدأ الإيصال بمعرفات القطعة التي قدمها الباحث: عائلة المنتج، الطراز، المكوّن أو الحزمة، الإصدار، البناء، فرع البرنامج الثابت وقناة التوزيع بقدر ما هو معلوم. ثم يسجل أصل ملف security.txt وعنوانه canonical، ووقت الاسترجاع، وقيمة Expires، ونتيجة التوقيع، ومدخل Product-Security المختار وموقعه في ترتيب الأفضلية.

ويحفظ كذلك عنوان Product-Security-Policy مع تجزئة المحتوى أو رقم نسخته. على الفريق المستقبل أن يذكر فقرة النطاق التي بررت القبول أو الرفض أو التحويل، والجهة التي أخذت الحيازة، ومعرف القضية أو التسليم الناتج. لا حاجة إلى كشف تفاصيل الثغرة الحساسة كي يبقى القرار قابلاً للمراجعة.

هذا الإيصال اقتراح تحريري من Daniel Kade، وليس مطلباً في المراجعة 00 أو RFC 9116 أو سجل IANA. وهو لا يعيد اختبار ما إذا كانت القناة حية. إيصال القناة يثبت الوصول؛ وإيصال القطعة يثبت قرار المسؤولية الذي تلاه.

المصادر