Hugging Face و ModelAudit: كشفت الأبحاث حدود الحماية المدمجة لنماذج التعلم الآلي

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

كيفية تنظيم الاختبار

في التجربة الأولى، لم يأخذ المؤلف كل Hugging Face، بل مجموعة فرعية من المستودعات ذات صيغ تخزين النماذج الأكثر خطورة. تضمنت المجموعة فقط النماذج المفتوحة التي كانت تحتوي على ملفات مثل `.pkl` و`.pickle` و`.dill` و`.pt` و`.pth` و`.ckpt` و`.bin` و`.joblib` و`.npy` و`.npz`. بالإضافة إلى ذلك، تم استبعاد المستودعات الكبيرة جداً والنماذج الشهيرة جداً: تم تحديد الحجم الإجمالي بـ 1 جيجابايت، وعدد التنزيلات شهرياً بـ 10 آلاف. الفكرة بسيطة: إذا كنت تبحث عن مشاكل حقيقية، فمن المنطقي أن تبدأ بالنظر إلى حيث تكون احتمالية التسلسل الخطير أعلى.

• في المجموعة الأولى، تم فحص 246 نموذجاً
• وجد ModelAudit 271 تنبيهاً حرجاً
• تم تفعيل تنبيه حرج واحد على الأقل بواسطة 34 نموذجاً
• للمقارنة، تم فحص المستودعات نفسها، وليس نقاط تفتيش فردية بداخلها

لكن من البداية أصبح من الواضح أن العدد الكبير من النتائج لا يساوي جودة الكشف. اتضح أن النموذج الذي كان "الأغنى" في الكشفيات كان Ultralytics/YOLO11: حصل على 728 تحذيراً، منها 35 حرجاً. على الورق، يبدو هذا بمثابة إشارة قوية على التسويس، لكن التحليل اليدوي أظهر صورة أكثر عادية. كان جزء كبير من الأعلام الحرجة مرتبطاً بعناصر Python قياسية يمكن العثور عليها أيضاً في النماذج الشرعية. بعبارة أخرى، لاحظ الماسح بشكل صحيح الأنماط المحتملة الخطيرة، لكنه فسرها كثيراً جداً على أنها دليل مباشر على هجوم.

حيث تُحدث القواعد ضوضاء

أظهر تحليل YOLO11 بوضوح نقطة الضعف في التحليل الثابت. جاءت بعض الكشفيات من `pickle_check` بسبب `__builtin__.getattr`، وأتت البعض الآخر من `pytorch_zip_check` بسبب `__builtin__.set` والمؤشرات المماثلة. المشكلة هي أن `getattr` يمكن بالفعل أن يُستخدم في سلاسل ضارة لتجاوز القواعد البدائية، لكنها أيضاً دالة Python عادية تظهر في الكود الطبيعي. مع `set` الحالة أكثر إيضاحاً حتى: يعتبر ماسح ModelAudit الداخلي واحد أن هذا الاستيراد مقبول، بينما قد يوسم آخر كامل مساحة الأسماء `builtin` على أنها مريبة. هذا هو السبب في أن المؤلف يؤكد بشكل خاص: الكثافة العالية حتى من التنبيهات الحرجة هي سبب للفرز اليدوي، وليس حكماً على النموذج.

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

"لم أتخيلها هكذا عندما بدأنا"

المقارنة مع Hugging Face

في التجربة الثانية، غيّر المؤلف التركيز وجمّع قائمة بالنماذج التي كان مؤلفو المستودعات قد وسموها بالفعل بأنها ضارة أو exploit أو ace أو deserialization أو poc. بعد تصفية إضافية من خلال LLM، تم تشغيل هذه المجموعة عبر ModelAudit ومقارنة النتائج مع الحالات المدمجة في Hugging Face. أظهرت المقارنة الأساسية اتفاقاً قوياً إلى حد ما: اعتُبرت 154 مستودعاً خطيرة من كلا الجانبين، و49 اعتُبرت آمنة. مع ذلك، كانت هناك 14 حالة رأى فيها ModelAudit مشكلة بينما لم يُظهر Hugging Face شيئاً مريباً.

الفارق الأهم هنا هو أن بعض الإشارات المفيدة من ModelAudit موجودة ليس فقط على مستويات التحذير والحرج. تقدم المقالة مثالاً على `jossefharush/gpt2-rs`، حيث كان التنبيه على مستوى INFO يحتوي على علامات نشاط الشبكة وارتباط إلى Pastebin. أظهر التحقق الإضافي أن هذا الارتباط يحتوي على باب خلفي يرسل نتائج تنفيذ الأوامر على جهاز الضحية إلى المهاجم. أي أن الرسالة "المعلوماتية" في هذه الحالة بالذات اتضح أنها ذات أهمية جوهرية أكبر من العديد من الأعلام الحرجة الصاخبة من التجربة الأولى.

قام المؤلف أيضاً بتحليل منفصل للاختلافات المعاكسة، عندما كان Hugging Face يُنبه عن الخطر لكن ModelAudit كان يترك النموذج يمر. في البداية، حدثت هذه الفشل في الإصدار 0.2.24، لكن بعد التحديثات إلى 0.2.28، ثم إلى 0.2.31، اختفت هذه الحالات. بدا الوضع النهائي هكذا: تم التقاط جميع المستودعات التي اعتبرها Hugging Face في النهاية خطيرة بواسطة ModelAudit أيضاً، وعلاوة على ذلك كان لدى الماسح الخارجي 17 مستودعاً إضافياً يحتوي على إشارات خطيرة لم تكن موجودة في التنبيهات المدمجة لـ HF.

ماذا يعني هذا

لا ماسح واحد يحل مشكلة أمان النماذج الخاصة بـ ML، حتى لو بدا الأكثر نضجاً في فئته. تُظهر المقالة عن Hugging Face و ModelAudit فكرة أكثر فائدة: لا تأتي النتائج الجيدة من الرهان على أداة "الأفضل" الواحدة، بل من مزيج من الفحوصات المتعددة والتحديثات المنتظمة للقواعد والتحليل اليدوي الإلزامي لأكثر الكشفيات صخباً.