26,400 مفتاح ذكاء اصطناعي وسحابة مكشوفة على Gitee: لماذا لا يكفي حذف المفتاح من الملف؟
كشف باحث 26,400 مفتاح سحابة وذكاء اصطناعي صالحاً في مستودعات Gitee العامة. نشرح لماذا لا يكفي الحذف وكيف تحمي مفاتيحك اليوم بخطوات عملية.

كشف باحث مستقل أن 26,400 مفتاح وصول لخدمات سحابية وذكاء اصطناعي كانت لا تزال تعمل، وهي مدفونة في مستودعات عامة على منصة Gitee الصينية. الخبر لا يخصّ الصين وحدها، فالمشكلة التي يكشفها هي نفسها التي تقع فيها فرق كثيرة حول العالم: مفتاح يُدفع إلى مستودع بالخطأ، ثم يُحذف من الملف، لكنه يبقى حيّاً في تاريخ الـcommits. في هذا المقال نشرح ما وُجد، ولماذا لا يكفي الحذف، وما الذي تفعله اليوم لتحمي مفاتيحك.
ما الذي وجده الباحث بالضبط؟

فحص الباحث Ben Zimmermann نحو 7.25 مليون مستودع عام على Gitee، وهي أكبر منصة استضافة أكواد في الصين، واستغرق الفحص شهراً كاملاً. لم يقتصر الفحص على آخر نسخة من الملفات، بل شمل تاريخ الـcommits كاملاً. ثم اختبر كل مفتاح عثر عليه أمام الجهة التي أصدرته، فبقي 26,400 مفتاح صالحاً للاستخدام.
| نوع المفتاح | العدد تقريباً |
|---|---|
| Alibaba Cloud AccessKey | 9,473 |
| YouTube API | 3,805 |
| DeepSeek | 3,170 |
| BigModel من Zhipu | 1,489 |
| OpenAI | 1,348 |
وجاء 12,242 مفتاحاً من commits تعود إلى عام 2025، أي أن كثيراً منها لم يُسحب بعد مرور وقت طويل. ومن بينها مفتاح بصلاحية مدير مؤسسة على منصة ذكاء اصطناعي لشركة.
المفتاح الذي نُشر مرة في مستودع عام يجب أن يُعامَل كمفتاح مكشوف إلى الأبد، حتى لو حذفته بعد دقيقة.
لماذا لا يكفي حذف المفتاح من الملف؟
يحفظ Git كل نسخة سابقة من كل ملف. عندما تحذف سطر المفتاح وتدفع commit جديداً، يبقى المفتاح في الـcommit القديم، ويمكن لأي شخص أو أداة آلية أن تقرأه. وهناك أسباب أخرى تجعل الأمر أسوأ:
- تُنسخ المستودعات العامة (forks) وتُؤرشف، فتبقى نسخ لا تتحكم بها.
- تفحص روبوتات خبيثة المنصات باستمرار، وقد تستغل المفتاح خلال دقائق.
- مفاتيح الذكاء الاصطناعي تعني فواتير مباشرة: من يملك مفتاحك يستهلك رصيدك.
وحتى إعادة كتابة التاريخ بأدوات مثل git filter-repo لا تلغي ما نُسخ سابقاً. الحل الوحيد الموثوق هو إلغاء المفتاح عند مزوّد الخدمة وإصدار بديل.
درس مهم عن أدوات الفحص
أحد أكثر الأجزاء فائدة في التقرير هو مقارنة أداتي فحص الأسرار المفتوحتين: Kingfisher وTruffleHog.
اختلاف كبير في النتائج
- وجدت Kingfisher كل مفاتيح Zhipu البالغة 1,489 مفتاحاً، لأن TruffleHog لا يملك كاشفاً لها.
- وجدت Kingfisher 2,940 مفتاح DeepSeek مقابل 230 فقط لدى TruffleHog.
- اتفقت الأداتان على 1,001 مفتاح فقط، وكل منهما التقطت نحو نصف المجموع.
الخلاصة العملية: لا تعتمد على أداة واحدة. إذا كنت تستخدم مزوّدين محليين أو أقل شهرة، فتأكد أن أداتك تملك كاشفات لهم، أو أضف قواعد مخصصة.
المفتاح الصالح ليس دائماً مفتاحاً خطيراً
يشير التقرير إلى أن بعض المفاتيح، مثل مفاتيح Google العامة، تُعرّف المشروع للحصص والفوترة ولا تمنح بالضرورة صلاحية إدارية. لكن لا يصحّ الاطمئنان لهذا، فالتقييم يتم لكل مفتاح على حدة.
ماذا تفعل اليوم؟ قائمة عمل
- فعّل فحص الأسرار قبل الدفع: استخدم hook من نوع pre-commit مع أداة فحص، ويفضّل تشغيل أداتين مختلفتين في خط CI.
- فعّل حماية الدفع (push protection) في GitHub أو GitLab إن كانت متاحة لمستودعاتك.
- افحص التاريخ الكامل: شغّل أداة الفحص على كل الـcommits وليس على آخر نسخة فقط.
- ألغِ ثم بدّل: إذا وجدت مفتاحاً مكشوفاً، ألغِه عند المزوّد فوراً، ثم أصدر بديلاً، ثم نظّف التاريخ إن لزم.
- قلّل الصلاحيات: أنشئ مفاتيح بأقل صلاحية ممكنة، وبحدّ إنفاق، ولكل بيئة مفتاح مستقل.
- استخدم مدير أسرار: ضع المفاتيح في متغيرات بيئة أو خدمة أسرار، ولا تضعها في الكود أو في ملفات
.envالمرفوعة. - راقب الاستهلاك: فعّل تنبيهات على الفواتير والاستخدام غير المعتاد لدى مزوّدي النماذج.
وكلاء البرمجة يزيدون الخطر
مع انتشار وكلاء البرمجة الذين يكتبون الكود ويدفعونه، تزداد احتمالات أن يُلصق مفتاح في ملف اختبار أو سكربت سريع ثم يُدفع. لذلك أضف قواعد صريحة لوكيلك بعدم كتابة أسرار في الملفات، وراجع كل commit يولّده قبل الدفع. وإن أمكن، امنح الوكيل مفاتيح مؤقتة محدودة بدل مفاتيحك الشخصية.
أسئلة شائعة
هل يكفي أن أجعل المستودع خاصاً بعد اكتشاف التسريب؟
لا. قد يكون المفتاح قد نُسخ أو التُقط بالفعل. اعتبره مكشوفاً وألغِه عند المزوّد.
هل المشكلة خاصة بـGitee؟
لا. الظاهرة نفسها تحدث على GitHub وGitLab وغيرهما. ما فعله الباحث أنه قاس حجمها على منصة واحدة كبيرة.
أي أداة فحص أستخدم؟
استخدم أكثر من أداة، فنتائج هذا التقرير تُظهر أن كل أداة تلتقط نصف ما تلتقطه الأخرى تقريباً. وأضف كاشفات للمزوّدين الذين تعتمد عليهم.
الخلاصة
تُظهر واقعة Gitee أن تسريب المفاتيح ليس حادثاً نادراً، بل نمط واسع ومستمر، وأن الحذف من الملف لا يلغي التسريب. المعالجة الصحيحة تقوم على ثلاث خطوات: امنع الدفع قبل أن يحدث، افحص التاريخ بأكثر من أداة، وألغِ أي مفتاح انكشف فوراً. ابدأ اليوم بمراجعة مستودعاتك، فقد تجد مفتاحاً منسياً يعمل منذ عام.
المصدر: The Hacker News