في إعلان مهم للمؤسسات وفِرق الأمن والتوافق، أكّدت GitHub أنها ستبدأ تطبيق "سياسة الاحتفاظ بتنبيهات Dependabot" في 25 أغسطس 2026. بموجب السياسة الجديدة، ستبقى التنبيهات المفتوحة متاحة كالمعتاد، بينما ستظلّ التنبيهات المغلقة متاحة بالكامل لمدة عامين فقط عبر الواجهة البرمجية والواجهة الرسومية؛ وبعد مرور عامين على إغلاقها تُنقل إلى أرشيف يمكن تنزيله بصيغة CSV، ولن تظهر في واجهات GitHub أو عبر REST API. السياسة تنطبق على GitHub.com بما في ذلك GitHub Enterprise Cloud، ولا تنطبق على GitHub Enterprise Server (على الخوادم الذاتية). المصدر الرسمي.
ما الذي يتغيّر بالضبط؟
- قبل 25 أغسطس 2026: يمكنك عرض جميع تنبيهات Dependabot—المفتوحة والمغلقة مهما كان تاريخها—عبر الواجهة وREST API.
- اعتبارًا من 25 أغسطس 2026: أي تنبيه Dependabot مغلق منذ عامين أو أكثر سيتم نقله إلى أرشيف يحتفظ به GitHub مدى حياة الحساب. هذه التنبيهات لن تظهر في الواجهة أو عبر REST API، لكن يمكن تنزيلها بصيغة CSV على مستوى المؤسسة أو المنظمة أو المستودع. المصدر الرسمي.
- التغطية المبدئية: يبدأ التطبيق بتنبّهات Dependabot فقط، مع نية توسيع السياسة لاحقًا لأنواع تنبيهات أمنية أخرى، مع منح إشعار مسبق لا يقل عن 60 يومًا لكل نوع. المصدر الرسمي.
- لا تغيّر في مكان البيانات: إذا كنت تستخدم GitHub Enterprise Cloud مع تقييد موقع البيانات (Data Residency)، فإن الأرشيف يبقى في نفس المنطقة. المصدر الرسمي.
من المتأثر؟
التأثير الأكبر يقع على:
- المؤسسات التي تعتمد على لوحات قياس داخلية أو تكاملات تسحب تنبيهات Dependabot المغلقة منذ أكثر من عامين عبر REST API.
- فرق الامتثال والتدقيق التي تحتاج إلى سجلات تاريخية كاملة لإثباتات الاستجابة للثغرات ضمن أطر مثل ISO 27001 وSOC 2.
- المنظمات التي تدير محافظ ضخمة من المستودعات وتتبنى حوكمة أمن التوريد البرمجي (Supply Chain Security) على نطاق واسع.
لماذا يهمني هذا التغيير؟
تنبيهات Dependabot تشكّل سجلًا تشغيليًا مهمًا لأي برنامج إدارة ثغرات يعتمد على بيانات سلسلة التوريد. نقل التنبيهات القديمة إلى أرشيف CSV يعني أنك بحاجة إلى تعديل خطوط جمع البيانات لديك وعدم افتراض أن كل السجلات التاريخية ستبقى قابلة للاستعلام عبر API.
الخبر الجيد أن GitHub يؤكد الاحتفاظ مدى حياة الحساب بتلك السجلات المؤرشفة وبـنفس مستوى التفاصيل، مع إمكانية تنزيلها عند الحاجة لدعم الالتزامات التنظيمية. لكنّ النقطة الفاصلة هي أن الوصول لن يكون عبر API أو الواجهة، بل من خلال تنزيلات CSV موجهة للمسؤولين ومديري الأمن. المصدر الرسمي.
كيف أستعد قبل 25 أغسطس 2026؟
1) راجع اعتمادك على REST API
إذا كانت تقاريرك أو تكاملاتك تعتمد على استعلامات تشمل تنبيهات مغلقة أقدم من عامين، فستتوقّف هذه الاستعلامات عن إعادة تلك السجلات بعد تاريخ التطبيق. استخدم REST API اليوم لمراجعة نطاق البيانات وتحديد ما سيتأثر لاحقًا. ابدأ بقراءة وثائق "Dependabot alerts" عبر REST API: المصدر الرسمي.
2) خطّة أرشفة واسترداد
- أنشئ إجراءً دوريًا لتوليد أرشيف CSV على مستوى المؤسسة أو المنظمة أو المستودع. خيار التصدير متاح من صفحات Security Overview ويُمكن فلترته حسب الحاجة قبل التصدير. طريقة التصدير الرسمية.
- خزّن الأرشيف في موقع مركزي بنمط WORM إن أمكن (Write Once Read Many) مع سياسات احتفاظ تتماشى مع اشتراطات الامتثال لديك.
- أتمِت التحقق من اكتمال الأرشيف (حجم الملف، عدد السطور، بصمة تجزئة) لتقليل مخاطر فقدان البيانات.
3) حدّث لوحات القياس والتقارير
عدّل لوحاتك كي تجمع بين البيانات الحيّة (التنبيهات المفتوحة والمغلقة خلال آخر عامين عبر API) والبيانات المؤرشفة (CSV). هذا يضمن استمرارية المؤشرات الزمنية الطويلة—مثل متوسط زمن المعالجة التاريخي—من دون انقطاع بعد 25 أغسطس.
4) عيّن الأدوار الصحيحة
التنزيل من الأرشيف يتطلب صلاحيات إدارية أو دور Security Manager على مستوى المؤسسة/المنظمة/المستودع. تأكد من تعيين الأدوار مبكرًا وتوثيق إجراءات الوصول. راجع متطلبات الأذونات في وثائق GitHub عند استدعاء REST API لتنبيهات Dependabot وعمليات التصدير. المصدر الرسمي، المصدر الرسمي.
5) اختبر سيناريو "ما بعد الأرشفة"
قبل 25 أغسطس، شغّل اختبارات على بيئة تجريبية عبر:
- محاكاة استعلامات REST API مع فلتر يقتصر على التنبيهات المغلقة الأقدم من عامين—وتوقّع ألا تكون متاحة بعد التاريخ المحدد.
- توليد ملف CSV من Security Overview بنفس الفلاتر، واستيراده إلى مستودع بياناتك أو أداة BI.
- مقارنة المؤشرات (عدد التنبيهات، الأشد خطورة، الزمن الوسيط للمعالجة) بين المصدرين لضمان استمرارية السلاسل الزمنية.
أسئلة مهمة وإجابات سريعة
هل يشمل التغيير GitHub Enterprise Server (على الخوادم الذاتية)؟
لا. السياسة الحالية لا تنطبق على GHES. التغيير مخصص لـ GitHub.com بما في ذلك GitHub Enterprise Cloud. المصدر الرسمي.
هل ستتأثر التنبيهات المفتوحة؟
لا. تبقى التنبيهات المفتوحة متاحة بالكامل في الواجهة وREST API بغضّ النظر عن العمر. التنبيهات المغلقة منذ أقل من عامين كذلك غير متأثرة. المصدر الرسمي.
كيف أنزّل الأرشيف؟
يمكن للمسؤولين ومديري الأمن تنزيل الأرشيف بصيغة CSV من صفحة Security (على مستوى المؤسسة أو المنظمة أو المستودع) بعد تطبيق السياسة. يدعم GitHub تصدير البيانات من Security Overview مع فلاتر مخصصة. طريقة التصدير الرسمية.
ماذا عن التقارير والتكاملات التي تعتمد على REST API؟
بعد 25 أغسطس 2026، لن تُرجع REST API التنبيهات المغلقة منذ عامين أو أكثر. أوصت GitHub بمراجعة الاستعلامات الحالية والتخطيط لاستخدام الأرشيف القابل للتنزيل بدلاً منها. وثائق REST API، الإعلان الرسمي.
خلاصة تنفيذية: قائمة تحقق سريعة
- حدّد لوحات وتقارير تعتمد على تنبيهات مغلقة قديمة (> عامين) عبر API.
- أضف مهمة دورية لتوليد وتنزيل CSV على مستويات المؤسسة/المنظمة/المستودع.
- حدّث مستودع البيانات وعمليات ETL لاستيعاب ملفات CSV المؤرشفة.
- راجع الأذونات: تأكد من تعيين Security Manager/الأدوار الإدارية المناسبة.
- اختبر الاستمرارية قبل 25 أغسطس 2026 لضمان عدم انقطاع القياسات والتقارير.
بهذه الخطوات، تحافظ على اتساق الرؤية الأمنية لديك وتفي بمتطلبات الامتثال، مع التكيّف مع نموذج الاحتفاظ الجديد الذي تقدمه GitHub لتنبيهات Dependabot.
npm يفعّل فحص الحزم وقت النشر ويلزم «الاستخدام المزدوج» ببيانات وتعزيز 2FA: ما الذي يتغيّر وكيف تستعد؟
جوجل بلاي يفتح باب توزيع «متاجر أندرويد» ويمنحها الوصول إلى كتالوج التطبيقات: ما الذي يتغيّر وكيف تستعد؟
قبل 31 أغسطس 2026: Google Play يشترط استهداف Android 16 (API 36) — ما الذي يتغيّر وكيف تجهّز؟
استغلال نشِط لثغرة CVE-2026-18577 في N‑central: حمِّل Hotfix 2 فوراً وتحقّق من مؤشرات الاختراق