يحتاج ملف security.txt إلى إيصال يثبت أن قناة الإفصاح تعمل

الخلاصة

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

التحليل

تجدد مؤسسة ملف security.txt عند مراجعة موقعها السنوية. العنوان مكتوب وفق الصيغة، وصفحة السياسة تعمل، وتاريخ الانتهاء بعيد، فتمنح أداة الفحص علامة خضراء. لكن صندوق البريد المشترك فقد أعضاءه أثناء نقل نظام الهوية. الخادم يقبل الرسائل ولا يقرأها أحد.

لا يكشف المثال قصوراً في المعيار، بل يكشف توسيعاً خاطئاً لمعنى الدليل. صُممت RFC 9116 لحل مشكلة الاكتشاف: أين يرسل الباحث بلاغاً عن ثغرة؟ وهي تشترط حقلاً واحداً على الأقل من Contact وحقلاً واحداً فقط من Expires. وفي خدمات الويب يوضع الملف في /.well-known/security.txt ويُقدم عبر HTTPS كنص UTF-8. ويسجل سجل IANA للمعرّفات المعروفة security.txt كلاحقة دائمة تخضع إدارة تغييرها لـ IETF.

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

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

ساعتان وحدود متعددة

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

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

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

الحد الثالث هو السرية. يشير حقل Encryption إلى مكان مفتاح أو بصمته ولا يضع المفتاح نفسه في الملف. وتحمّل RFC الباحث مسؤولية التحقق من أصالة المفتاح. إتاحته للعامة لا تثبت أن فريق المناوبة يملك المفتاح الخاص الحالي أو أن إجراءات فك التشفير انتقلت مع تبدل الموظفين.

الحد الرابع هو الإقرار. رقم قضية ثابت أو رد يمكن مطابقته يحول القبول التقني إلى حيازة مؤسسية. أما الرد الآلي المنفصل فلا يثبت إلا أن قاعدة اشتغلت؛ يجب ربطه بطابور مراقب ومسار لاحق.

والحد الخامس هو المعالجة. من يجري التقييم الأولي؟ من يتعامل مع البلاغ الخارج عن النطاق؟ من ينسق الإصلاح ويبلغ صاحبه بالنتيجة؟ تعرض التوجيهات التشغيلية الملزمة رقم 20-01 الصادرة عن CISA هذه الطبقة للهيئات المدنية الفيدرالية الأميركية المشمولة بها. فهي تطلب إجراءات لتتبع البلاغات حتى الحل، وتنسيق المعالجة، وتقييم الأثر، والتعامل مع ما هو خارج النطاق، والتواصل مع المبلغين، كما تطلب أهدافاً زمنية للإقرار والتقييم الأولي والحل. ليست هذه متطلبات في RFC 9116 ولا قانوناً عالمياً، بل مثال رسمي على تشغيل يبدأ بعد نشر نقطة الدخول.

اختبار لا ينتحل صفة بلاغ حقيقي

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

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

يجب ألا تتضخم دلالة النتيجة. قبول SMTP يثبت وصول الرسالة إلى محطة واحدة، لا قراءتها. صفحة الشكر تثبت استجابة التطبيق، لا حفظ القضية. والرد التلقائي يثبت عمل قاعدة، لا انتباه شخص مسؤول. ما لم يُختبر ينبغي أن يبقى موسوماً بأنه غير مختبر.

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

إبقاء المعيار في مكانه الصحيح

لا يحل الإيصال محل security.txt. يبقى الملف واجهة الاكتشاف العامة، ولكل من Canonical وPolicy وPreferred-Languages وEncryption وظيفة مختلفة في تقليل الغموض. ويمكن للتوقيع الرقمي أن يعزز دليل الأصل والسلامة.

يجيب السجل الإضافي عن سؤال أضيق: متى أكمل المسار المعلن آخر مرة الحد الأدنى من الاكتشاف إلى الحيازة؟ «الملف صالح، البريد مقبول، لا إقرار» نتيجة مفيدة. و«النموذج أنشأ قضية، المسؤول معروف، النائب غير مؤكد» نتيجة مفيدة أخرى. الحالات الجزئية تحدد موضع الإصلاح أفضل من شارة واحدة.

يمكن أن يكون سطر العرض قصيراً: جُلب الملف في 7 سبتمبر؛ ينتهي في 1 مارس؛ قُبل الاختبار؛ وصل الإقرار بعد 14 دقيقة؛ تم تأكيد مالك الطابور؛ لم يُختبر التصعيد. لكل جزء دليله ووقته، ولا يعد أي منها بأن ثغرة مستقبلية ستكون صحيحة أو ذات أولوية سليمة أو محلولة في الموعد.

المصادر

1. RFC 9116 — A File Format to Aid in Security Vulnerability Disclosure
2. سجل IANA للمعرّفات المعروفة
3. التوجيه التشغيلي الملزم 20-01 الصادر عن CISA