تترك صور الحاويات غير الموقعة سلسلة توريد البرمجيات قائمة على الثقة أكثر من اعتمادها على دليل يمكن التحقق منه. فالصورة قد تبدو وكأنها صادرة عن جهة موثوقة، بينما لا توجد وسيلة تشفيرية تؤكد من أنشأها أو ما إذا كانت قد عُدّلت بعد مغادرتها نظام البناء. وتزداد أهمية هذه المشكلة مع انتقال أوزان النماذج وبيانات التدريب وبيئات الاستدلال وأدوات الوكلاء إلى التوزيع بوصفها مصنوعات OCI.
تدعو المادة، التي نشرتها The New Stack برعاية AWS Marketplace في 14 أغسطس 2026، إلى التعامل مع توقيع الصور باعتباره سلسلة متكاملة تبدأ بإثبات المصدر وتنتهي بمنع تشغيل المصنوعات غير الموثوقة، لا باعتباره خطوة اختيارية تضاف إلى خط أنابيب التسليم.
الفجوات التي تتركها الصور غير الموقعة
يمكن للمهاجمين استغلال مراحل متعددة من خط التسليم. فقد تتنكر صورة خبيثة في هيئة حزمة شرعية، أو تحقن عملية بناء CI/CD مخترقة مصنوعاً معدلاً داخل إصدار الإنتاج، أو تُستخدم بيانات اعتماد مسروقة لانتحال هوية ناشر موثوق. كما أن اختلاف الممارسات بين الفرق، بحيث توقّع بعض الفرق صورها وتتجاوز فرق أخرى هذه الخطوة، يترك فجوات غير واضحة في سلسلة الثقة.
وتتفاقم المخاطر بسبب وراثة الصور الأساسية؛ إذ ترث كل صورة حاوية الوضع الأمني لصورتها الأصلية. لذلك يمكن لصورة أساسية مخترقة أن تنشر أثرها عبر عشرات الخدمات التابعة قبل اكتشاف المشكلة.
لا يجيب فحص الثغرات عن السؤال نفسه. فهو يوضح ما إذا كانت الصورة تحتوي على ثغرات معروفة، لكنه لا يثبت من بناها أو ما إذا كانت قد عُدّلت منذ خروجها من نظام البناء. ولهذا ترى المادة أن الفحص والتوقيع متكاملان: الأول يصف ما يوجد داخل الصورة، والثاني يساعد على تحديد ما إذا كان يمكن الوثوق بها.
لماذا يوسّع الذكاء الاصطناعي نطاق الخطر؟
لا تحمل أوزان النماذج بالضرورة ثغرة يمكن مطابقتها مع قاعدة بيانات CVE. وحتى استخدام صيغ تسلسل أكثر أماناً مثل .safetensors، والتي تزيل مسار تنفيذ الشيفرة، لا يثبت من أنتج الأوزان أو ما إذا كانت الأوزان المقصودة فعلاً.
تستشهد المادة بحادثة اكتشف فيها باحثو JFrog في فبراير 2024 نموذج PyTorch خبيثاً على Hugging Face، فتح اتصالاً عكسياً بمجرد تحميله مستفيداً من دالة __reduce__ في pickle لتنفيذ شيفرة عشوائية عبر torch.load(). وأظهر تحليلهم وجود نحو 100 نموذج على المنصة تحمل حمولات خبيثة حقيقية. لم يظهر تنبيه CVE، لأن السلوك الخبيث كان داخل الأوزان المتسلسلة نفسها.
تشغّل Hugging Face فحص ClamAV وفحصاً لاستيرادات pickle على كل ملف يُرفع إلى المنصة، لكن المادة تشير إلى أن أدوات الفحص القائمة على الأنماط يمكن التحايل عليها. ففي فبراير 2025، وصفت ReversingLabs نموذجَي nullifAI اللذين تجاوزا picklescan باستخدام ضغط 7z بدلاً من ZIP وإفساد تدفق pickle بعد تشغيل الحمولة. أزيل النموذجان خلال 24 ساعة ورقّعت Hugging Face أداة picklescan، لكن المثال يوضح أن اكتشاف التشابه مع نمط خبيث معروف لا يجيب عن سؤال المصدر.
وترى المادة أن أثر العبث بنموذج ذكاء اصطناعي قد يكون أوسع من أثر العبث بصورة تطبيق تقليدية؛ إذ يمكن أن يفسد التنبؤات على نطاق واسع، أو يسمم التوصيات المقدمة إلى ملايين المستخدمين، أو يدفع الوكلاء إلى تنفيذ استدعاءات لواجهات برمجية وأدوات وإنفاق في بيئات الإنتاج.
التوقيع والتحقق والإنفاذ
تقترح المادة ثلاث خطوات مترابطة:
- التوقيع: إنشاء توقيع وقت البناء أو الدفع يربط بصمة الصورة بهوية يمكن التحقق منها، مع حماية المفتاح الخاص وتدويره.
- التحقق: فحص التوقيع عند السحب، وبصورة مهمة قبل السماح بقبول عبء العمل، مقابل سياسة ثقة تحدد الهويات المسموح لها بالتوقيع.
- الإنفاذ: استخدام وحدة تحكم لقبول الحاويات في Kubernetes، مثل Kyverno، لمنع تشغيل أي صورة لم يوقّعها مصدر موثوق. فالتوقيع وحده لا يغير شيئاً إذا لم تفرض المنصة التحقق منه.
وتحذر المادة من أن التوقيع لا يجعل التزوير مستحيلاً. فإذا اختُرقت هوية توقيع موثوقة وسُرقت بيانات اعتمادها وصلاحية التوقيع، يمكن للمهاجم إنتاج صورة خبيثة تحمل توقيعاً صالحاً. لكن التوقيع يضيّق نطاق المشكلة، ويجعل الحدث قابلاً للتدقيق ومرتبطاً بهوية يمكن إبطالها، بدلاً من أن يكون استبدالاً مجهولاً لا يمكن نسبته.
لماذا تُعدّ السجلّات طبقة مناسبة؟
توضح المادة أن معظم الفرق تتحقق من عناوين الصور أكثر مما تتحقق من مصدرها. فالسماح بالصور القادمة من حساب سجل محدد، وربط بيانات الدفع بخط الأنابيب، وحظر الثغرات الحرجة، كلها ضوابط مفيدة، لكنها لا تميز بالضرورة بين صورة سليمة وأخرى خبيثة دخلت بالفعل إلى الحدود الموثوقة. كما أن تثبيت البصمة يضمن الحصول على البايتات المطلوبة، لكنه لا يثبت أن تلك هي البايتات الصحيحة التي ينبغي طلبها.
يمر كل صورة حاوية عبر سجل قبل تشغيلها، والسجل يرى المصنوعات، ويعرف من دفعها، ويطبق سياسات الوصول، ويخزن بياناتها الوصفية. لذلك ترى المادة أن وضع التوقيع في هذه الطبقة قد يجعل العملية متسقة عبر الفرق وخطوط الأنابيب، بدلاً من تحميل كل فريق مسؤولية تركيب أدوات العميل وإدارة المفاتيح والشهادات وجداول التدوير وقوائم الإبطال.
وتذكر المادة أن هذا العبء التشغيلي كان قد يتطلب استخدام أدوات مثل Notation CLI أو Cosign وبناء أتمتة مخصصة، وهي عملية قد تستغرق أسابيع أو أشهراً في مؤسسة تضم آلاف خطوط الأنابيب المختلفة. وفي هذا السياق تقدم Amazon ECR Managed Signing بوصفه نهجاً يهدف إلى جعل التوقيع خاصية مرتبطة بدفع الصورة، لا مشروعاً منفصلاً تتولاه كل مجموعة.
وبحسب الوصف الوارد، تُنشأ إعدادات توقيع على مستوى السجل، مع ما يصل إلى عشر قواعد، تربط كل قاعدة بملف توقيع ومرشحات للمستودعات، بحيث تُوقّع عمليات الدفع المطابقة تلقائياً. وتبقى المراجعة البشرية مهمة للتحقق من تفاصيل الإتاحة والنطاق التشغيلي، إذ ينتهي النص المستخرج أثناء شرح آلية هذه الميزة.