حصل Dependabot على وصول مجهول إلى السجلات على مستوى المؤسسة

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

ما الذي تغيّر

تتيح السجلات الخاصة على مستوى المؤسسة وصف مصدر التبعيات مرة واحدة واستخدامه في مستودعات الشركة كلها. وبات بالإمكان الآن اختيار Anonymous عند إعداد سجل من هذا النوع. وسيتصل Dependabot بهذا السجل دون بيانات اعتماد.

يورد إعلان GitHub مثالًا واحدًا: المرآة الداخلية للحزم. وهذا نمط معتاد. تُقيم الشركة لديها وكيلًا (proxy) أو ذاكرة تخزين مؤقت لـ npm أو Maven أو PyPI أو أي منظومة أخرى. ويُقيَّد الوصول إليه بالشبكة لا بكلمات المرور. فهو مفتوح للمطورين داخل المحيط الشبكي، وغير متاح لمن هم خارجه.

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

لماذا يهم ذلك عمليًا

المكسب الرئيسي هو نظافة الإعدادات. فـ Anonymous يزيل من الإعدادات الأسرار المزيفة، ومعها أسئلة التدقيق: ما هذا الرمز، وأين يُستخدم، ومتى جرى تدويره. وإذا لم يكن هناك رمز، فلا يمكن فقدانه أو نسيان إلغائه.

والميزة الثانية تتعلق بالحجم. فالمستوى التنظيمي موجود لتجنب تكرار السجل نفسه في عشرات المستودعات. وإذا كانت المرآة مفتوحة داخل الشبكة، فإن الإعداد يتم مرة واحدة لجميع المشاريع.

والشرط الأساسي أن يكون السجل قابلًا للوصول من البيئة التي يعمل فيها Dependabot. ولا يتضح من نص الإعلان كيف يتفاعل التحديث مع القيود الشبكية أو مع runners المستضافة ذاتيًا. ومن المستحسن التحقق من ذلك في وثائق GitHub قبل الانتقال.

باختصار، هذه هي المعطيات:

• تاريخ الإعلان: 12 أكتوبر 2026.
• نطاق التطبيق: السجلات الخاصة على مستوى المؤسسة.
• طريقة المصادقة الجديدة: Anonymous.
• السيناريو المستهدف: السجلات التي لا تشترط بيانات اعتماد، مثل المرآة الداخلية للحزم.
• ما لا يتغير: السجلات التي تعتمد على رموز الوصول أو كلمات المرور تواصل العمل كما كانت.

أين تكمن المخاطر

يعني الوصول المجهول أن أي شخص يرى نقطة الوصول (endpoint) يستطيع قراءة الحزم. وتعتمد الحماية كلها على الشبكة. فإذا أصبحت المرآة متاحة من الخارج عن طريق الخطأ، وكانت تضم مكتبات داخلية، فسيؤدي ذلك إلى تسرب الشيفرة المصدرية وأسماء الحزم الداخلية.

وثمة مشكلة أقل وضوحًا. فأسماء الحزم الداخلية الظاهرة دون مصادقة تسهّل هجمات استبدال التبعيات (dependency confusion). لذلك من المعقول إبقاء المرآة المجهولة بوصفها ذاكرة تخزين مؤقت للحزم العامة، لا مستودعًا للحزم المغلقة.

كيف ينبغي أن تتصرف الفرق

ينبغي أولًا مراجعة السجلات الحالية في المؤسسة وتحديد تلك التي وُضعت فيها قيم شكلية بدل الأسرار الحقيقية. فهذه هي المرشحة للانتقال.

ثم التحقق من ثلاثة أمور:

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

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

بالنسبة لمعظم الفرق، هذا تغيير تنظيمي وقائي وليس ميزة جديدة. لكن مثل هذه التعديلات هي بالتحديد ما يقلّص عدد رموز الوصول المنسية في CI وفي الإعدادات.