تنبيه Dependabot الذي تم تجاهله ليس حكماً على المعالجة

الخلاصة

• يعرّف GitHub التجاهل كحالة تنبيه لها سبب، ويمكن إعادة فتح تنبيه متجاهل لم يُصلح.
• اكتشاف الرسم البياني وسبب التجاهل ودليل المعالجة التشغيلية سجلات مختلفة.
• لا يصح وصف التنبيه بأنه عولج من دون وصل تلك السجلات بأدلة مستقلة.

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

الحد ظاهر في التوثيق نفسه: يمكن إعادة فتح التنبيه المتجاهل غير المُصلح. لذلك لا يكون التجاهل عديم الفائدة؛ فقد يحفظ حكماً قابلاً للمراجعة. إلا أن fix_started لا يثبت إنجاز العمل، وnot_used قد يصف مساراً محدداً فقط، وtolerable_risk لا يوضح تلقائياً من يملك سلطة قبول أي خطر متبقٍ وعلى أي خدمة.

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

يقترح Daniel Kade إيصالاً من ستة أجزاء: التنبيه ونطاقه؛ سبب التجاهل وسلطة صاحبه؛ حالة المصدر والحل؛ التغيير المراجع؛ قطعة البناء والاختبار؛ ومشاهدة محددة للنشر. يمكن حماية المعرفات الحساسة، لكن لا يجوز أن تحل تسمية الحالة محل الروابط بين الأدلة.

المصادر

1. GitHub Docs — Viewing and updating Dependabot alerts
2. GitHub Docs — How the dependency graph recognizes dependencies
3. GitHub Docs — Vulnerable dependency detection
4. GitHub Docs — REST API endpoints for Dependabot alerts