أمن سلسلة التوريد بالذكاء الاصطناعي بعد ميركور

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

هذا هو السبب في أن الحادثة غيرت المحادثة. إذا كنت لا تزال تعرّف أمن الذكاء الاصطناعي على أنه الحقن الفوري واختراق الحماية وإساءة استخدام الأدوات وتصفية المخرجات، فأنت تنظر إلى طبقة تطبيق النموذج بينما تحدث معركة أكثر أهمية داخل طبقة إنتاج النموذج. أخبرت شركة Mercor موقع TechCrunch أنها كانت واحدة من آلاف الشركات التي تأثرت بالاختراق الأوسع نطاقًا لـ LiteLLLM. القصة ليست مجرد تسميم حزمة بايثون. القصة هي أن اختراق الحزمة وصل إلى شركة تشارك في إنشاء وتقييم البيانات التي تساعد مختبرات فرونتير على تحسين سلوك النموذج. (تك كرانش)

الدرس غير المريح بسيط. تحاول العديد من فرق الذكاء الاصطناعي الدفاع عن الشيء الذي يلمسه المستخدمون بينما لا تدافع عن السلسلة التي تجعل الشيء ذا قيمة في المقام الأول. تتعامل مادة مخاطر GenAI الحالية الخاصة بـ OWASP مع مخاطر سلسلة التوريد على أنها أوسع من المكتبات وحدها، وتمتد إلى بيانات التدريب والنماذج ومنصات النشر. تقوم الإرشادات الحكومية الصادرة عن وكالة الأمن القومي والوكالات الشريكة بنفس الخطوة من زاوية مختلفة، حيث تدعو إلى المراجعات الموثوقة، والمصدر، والبنية التحتية الموثوقة كممارسات أساسية لأمن بيانات الذكاء الاصطناعي. تجعل قضية ميركور هذه التوجيهات المجردة تبدو ملموسة. (مشروع OWASP Gen AI Security Project)

كشف Mercor وLiteLLLM نموذج التهديد الخاطئ

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

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

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

تستحق قصة الإسناد أيضًا التحفظ. ذكر موقع WIRED أن الجهات الفاعلة التي تستخدم اسم Lapsus$ تبنت اختراق Mercor، لكن الباحثين الذين تمت مقابلتهم هناك قالوا إن رابط LiteLLLLM يجعل من المرجح أن يكون TeamPCP أو جهة فاعلة ذات صلة. وقد ربطت شركة Mercor، في بيانها لـ TechCrunch، بين حادثها وهجوم سلسلة التوريد LiteLLLLM وقالت إنها واحدة من العديد من المؤسسات المتضررة. هذه هي الحالة الصادقة للسجل: كانت الادعاءات العامة صاخبة، لكن الخيط التقني الأقوى يقود إلى اختراق LiteLLLLM وحملة TeamPCP الأوسع نطاقًا. (WIRED)

ما الذي غيرته تسوية LiteLLLLM بالفعل

لا تعتبر LiteLLLLM مثيرة للاهتمام هنا لأنها "شيء خاص بالذكاء الاصطناعي". إنه مثير للاهتمام لأنه يقع بالقرب من الوصول المركز. يصفه تنبيه هيئة الخدمات الصحية الوطنية في إنجلترا بأنه بوابة واجهة برمجة تطبيقات مستخدمة على نطاق واسع تتيح للمطورين الوصول إلى مئات النماذج اللغوية الكبيرة. يشير تنبيه GitHub الخاص بالحادث إلى أن الإصدارات من 1.82.7 إلى 1.82.8 على أنها متأثرة ويقول إن أي شخص قام بتثبيتها وتشغيلها يجب أن يفترض أن بيانات الاعتماد في تلك البيئة قد تكون مكشوفة. هذا هو المعنى الأمني للحدث: لقد أصاب الاختراق مكونًا غالبًا ما يعيش بجوار مفاتيح الموفر وبيانات الاعتماد السحابية والسجلات ومنطق التوجيه. (هيئة الخدمات الصحية الوطنية بإنجلترا الرقمية)

التفاصيل الفنية جديرة بالفهم لأنها تفسر سبب اتساع نطاق الانفجار أكثر من الإصدار السيئ العادي. تُظهر مشكلات LiteLLLLM في GitHub تحولًا ذا مغزى بين الإنذار العام الأول والجدول الزمني الرسمي اللاحق. ركزت المشكلة الأولى على ليتلم==1.82.8 وخبيث litellm_init.pth الذي سيتم تنفيذه عند بدء تشغيل أي مترجم بايثون بدون استيراد ليتلم مطلوب. وسّع الإصدار الرسمي الذي صدر لاحقًا المجموعة المتأثرة لتشمل 1.82.7 و1.82.8، قائلًا إن الإصدار 1.82.7 يتضمن منطقًا خبيثًا في proxy_server.py وتم تشغيله على استيراد litellm.proxyبينما أضافت 1.82.8 1.82.8 .pth خطاف بدء التشغيل، وبالتالي اتسعت حالة الزناد. هذا التقدم هو تذكير بأن الإبلاغ المبكر عن الحوادث قد يكون ناقصًا حتى عندما يكون سليمًا من الناحية الفنية. (جيثب)

يضيف استشاري GitHub الذي تمت مراجعته حقيقتين أخريين مهمتين من الناحية التشغيلية. أولاً، تقول أن الإصدارات الخبيثة تم تحميلها إلى PyPI بعد انكشاف رمز واجهة برمجة التطبيقات من تبعية Trivy المستغلة. ثانيًا، لا يسرد أي إصدارات مصحّحة في البيانات الوصفية الاستشارية، على الرغم من أن LiteLLLLM قالت لاحقًا إنها أصدرت الإصدار الآمن v1.83.0 من خلال خط أنابيب CI/CD المعاد بناؤه. إن عدم التطابق هذا مفيد. غالبًا ما تتحرك استجابة سلسلة التوريد من خلال منشورات الحوادث، ومشكلات GitHub الطارئة، وتنظيف السجل قبل أن تلحق البيانات الوصفية الاستشارية المنظمة بالكامل. فالمدافع الناضج يقرأ الثلاثة معًا، وليس فقط موجزًا واحدًا. (جيثب)

يقول تحديث الحادثة الخاص بـ LiteLLLLM أن الإصدارات المتأثرة قد أزيلت من PyPI وأن المشروع أصدر لاحقًا الإصدار v1.83.0 الآمن من خلال خط أنابيب CI/CD v2 جديد مع بيئات معزولة، وبوابات أمنية أقوى، وفصل أكثر أمانًا للإصدار. يشير مجلس المدينة للمتابعة إلى ثلاثة عوامل ساهمت في الفشل الأصلي: بيئة CircleCI المشتركة، وبيانات اعتماد الإصدار الثابتة في متغيرات البيئة، وتبعية Trivy غير المثبتة في مكون الفحص الأمني. هذه ليست أخطاء الذكاء الاصطناعي الأصلية. إنها أخطاء في سلسلة التوريد في مكدس الذكاء الاصطناعي. هذا هو بالضبط سبب أهمية هذه الحالة التي تتجاوز LiteLLLLM نفسها. (لايت لالم)

وقد لخصت إرشادات NHS النتيجة العملية بوضوح غير عادي. يمكن لحزم LiteLLLLM المخترقة أن تستخرج الأسرار وتؤسس الثبات وتنفذ على كل استدعاء لبايثون في البيئة المتأثرة. وهذا يعني أن الحواسيب المحمولة المحلية، ومشغلات CI سريعة الزوال، وصناديق الاختبار، والبيئات المشتركة الشبيهة بالحصون، وبوابات الذكاء الاصطناعي المركزية تنتمي جميعها إلى نطاق الاستجابة. إذا كنت تفكر فقط من منظور "هل استورد الإنتاج الحزمة"، فأنت متأخر بالفعل. (هيئة الخدمات الصحية الوطنية بإنجلترا الرقمية)

لماذا يختلف أمن سلسلة التوريد بالذكاء الاصطناعي عن نظافة العبوات العادية

عادةً ما يبدأ التفكير التقليدي في سلسلة توريد البرمجيات بشجرة تبعية وينتهي بإصدار مصحح. هذا مفيد، لكنه ليس كافياً لأنظمة الذكاء الاصطناعي. يصف مشروع أمان GenAI التابع لمنظمة OWASP صراحةً مخاطر سلسلة التوريد الخاصة بالذكاء الاصطناعي على أنها تشمل سلامة بيانات التدريب والنماذج ومنصات النشر، وليس فقط تبعيات التعليمات البرمجية العادية. وقد أوضحت الصياغة الأقدم لمشروع OWASP LLM 10 الأقدم نفس النقطة بشكل أبسط: يمكن للمكونات أو الخدمات أو مجموعات البيانات المخترقة أن تقوض سلامة النظام وتتسبب في اختراق البيانات أو فشل النظام. أما في أنظمة الذكاء الاصطناعي، فإن حدود "ما يُعتبر سلسلة توريد البرمجيات" أوسع لأن البيانات والعمليات البشرية تشكل سلوك النظام نفسه. (مشروع OWASP Gen AI Security Project)

تعكس إرشادات الحكومة والمعايير الآن هذه الحدود الأوسع نطاقاً. يؤكد إعلان أمن بيانات الذكاء الاصطناعي لعام 2025 الصادر عن وكالة الأمن القومي على التوقيعات الرقمية للمراجعات الموثوقة، ومصدر البيانات، والبنية التحتية الموثوقة عبر دورة حياة الذكاء الاصطناعي. كما تدعو إرشادات أمن بيانات الذكاء الاصطناعي المشتركة صراحةً إلى سلسلة توريد البيانات أثناء التخطيط وأعمال التحقق من صحة البيانات. وتذهب إرشادات تطوير الذكاء الاصطناعي الآمن الصادرة عن المركز الوطني للأمن السيبراني إلى أبعد من ذلك من الناحية الهيكلية، حيث تقسم أمن الذكاء الاصطناعي إلى تصميم آمن، وتطوير آمن، ونشر آمن، وتشغيل وصيانة آمنة، وتقول إن الأمن يجب أن يُعامل كمتطلب أساسي طوال دورة حياة النظام. يملأ SSDF الخاص ب NIST جانب البرمجيات من خلال تحديد مجموعة أساسية من ممارسات التطوير الآمن عالية المستوى التي يمكن دمجها في دورات حياة البرمجيات الحالية. (وكالة الأمن القومي)

ضع هذه المستندات معًا وسيظهر نموذج أكثر دقة لسلسلة توريد الذكاء الاصطناعي. وهو يتضمن خمسة مسارات متشابكة على الأقل. هناك مسار الكود الذي يتضمن المكتبات وصور الحاويات والإجراءات وأدوات الإنشاء والسجلات. هناك مسار البيانات، والذي يتضمن بيانات ما قبل التدريب، والمجموعات التي تم ضبطها بدقة، ومهام التقييم، والمطالبات، والنماذج، ومصادر المعرفة المسترجعة. وهناك مسار التحكم، والذي يتضمن البوابات، وإدارة المفاتيح، ومنطق التوجيه، وجسور الأدوات، وإنفاذ السياسة. وهناك المسار البشري، والذي يتضمن المتعاقدين والمشرحين والمراجعين وموظفي العمليات ومشرفي البائعين. وهناك مسار النشر، والذي يتضمن CI/CD، وتوقيع القطع الأثرية، وتحميل السجل، وتثبيت الإصدار. حالة ميركور مهمة لأنها تلامس أكثر من مسار من هذه المسارات في آن واحد. (WIRED)

وهذا هو السبب أيضًا في أن العديد من برامج أمن الذكاء الاصطناعي تبدو غير مكتملة بشكل غريب. فهي تنفق بشكل كبير على حالات إساءة استخدام النماذج والتطبيقات مثل الحقن الفوري غير المباشر وإساءة استخدام الأدوات، ولكن أقل بكثير على ما إذا كان بإمكان بائعي التدريب تسريب هياكل المهام الحساسة، أو ما إذا كانت تبعيات البوابات يمكن أن تحصد بيانات الاعتماد، أو ما إذا كانت مسارات الإصدار تثبت مصدر القطع الأثرية، أو ما إذا كانت بوابات المتعاقدين تكشف عن البيانات الوصفية للمشروع عبر العملاء. هذه كلها أجزاء من نفس نظام الثقة. النموذج الذي يواجه المستخدم هو الميل الأخير فقط. (مشروع OWASP Gen AI Security Project)

يجلس بائعو بيانات التدريب على الذكاء الاصطناعي على مسار جوهرة التاج

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

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

هذا هو أحد الأماكن التي يختلف فيها أمان الذكاء الاصطناعي عن أمان SaaS العادي من الناحية العملية. قد يحتفظ بائع المكاتب الخلفية النموذجي بالفواتير أو سجلات الموظفين أو القياس عن بعد للمنتج. يمكن أن يحتفظ بائع بيانات التدريب بآثار خارطة طريق القدرات المستقبلية للمؤسسة النموذجية. قد تظل النماذج آمنة. وقد لا تزال بيانات المستخدم غير ملموسة. ولكن يمكن أن تظل عملية التصنيع مكشوفة جزئياً. إن برامج الأمن التي تقيس النجاح فقط من حيث الكشف عن سجلات العملاء تفتقد إلى هذه الفئة. (WIRED)

الجدول أدناه عبارة عن تجميع لتقارير ميركور، ومواد حادثة LiteLLLLM، وتأطير سلسلة التوريد الخاصة ب OWASP، وإرشادات دورة حياة الذكاء الاصطناعي. تم تصميمه كخريطة عمل للمدافعين، وليس كتمرين تصنيف. (WIRED)

طبقة سلسلة التوريد بالذكاء الاصطناعي	ما يخزنه أو يتحكم فيه	ما أظهرته الحوادث الأخيرة	لماذا يفتقد المسح العادي	ما يجب التحقق من صحته باستمرار
سجلات الحزمة والمكتبات	القطع الأثرية القابلة للتنفيذ المثبتة من قبل المطورين و CI	أظهر LiteLLLLLM إمكانية تشغيل الإصدارات الخبيثة قبل أن يبدأ منطق التطبيق العادي	لا تثبت عمليات التحقق من SBOMs والتحقق من الإصدارات وحدها الثقة في القطع الأثرية	مصدر السجلات، والموجزات الاستشارية، وفحص العجلات، وصيد مسار التثبيت
إجراءات CI وأدوات الأمان	الإنشاء والمسح والإصدار والوصول السري	تريفي و ت-ج-إجراءات أظهر مكون سير عمل واحد مخترق يمكن أن يكشف الأسرار على نطاق واسع	تثق الفرق في العلامات والروبوتات و"أدوات الأمان" افتراضيًا	تثبيت SHA، وعزل الوظائف، والرموز المميزة الأقل امتيازاً، ومراجعة النطاق السري
بوابات الذكاء الاصطناعي	مفاتيح الموفر، والتوجيه، وضوابط التكلفة، والسجلات، وسياق المستأجر	ركز LiteLLLLM على الأسرار التي يريدها المهاجمون بالضبط	غالبًا ما تبدو برامج البوابات مثل السباكة وليس جوهرة التاج	اختبارات التعرّض الرئيسية، واختبارات حدود السجل، والعزل متعدد المستأجرين، ومراجعة الخروج
بائعو بيانات التدريب	المهام والنماذج والتقييمات والتقييمات والبيانات الوصفية لمشروع العميل	أظهر ميركور أن بيانات التصنيع النموذجية يمكن أن تؤدي إلى تداعيات على مستوى الأعمال التجارية	غالبًا ما يتم تحديد نطاق هذه الأسطح على أنها عمليات البائع، وليس أمن المنتج	عزل المشروع، واختبار تعرض البيانات الوصفية، وفصل الوصول، والتعامل مع الأدلة
بوابات المتعاقدين والمراجعين	تنفيذ المهام البشرية، وتعليمات المشروع، وتخصيص العمل	يمكن أن يترك مشروع الذكاء الاصطناعي المتوقف مؤقتًا أثرًا واضحًا لمن كان يعمل على ماذا	لا يجوز لفرق الأمن التعامل مع منصات العمل كأهداف اختبار هجومية	اختبارات الرؤية عبر المشاريع، ومراجعة الوصول المستند إلى الأدوار، والتحقق من التخزين المشترك
خطوط أنابيب الإصدار	هوية الناشر، وتحميل القطع الأثرية، والثقة في الإصدار	أظهر LiteLLLLM و Trivy أن سجل الريبو يمكن أن يختلف عما يتم شحنه	غالبًا ما تتحقق الفرق من المصدر أكثر من النشر	النشر الموثوق به، والتصديقات، وتطبيق سياسة القطع الأثرية، ومراجعة الإصدار القابل للتكرار
ضوابط دورة حياة بيانات الذكاء الاصطناعي	الإثبات، والمراجعات الموثوق بها، وجودة بيانات TEVVV	تشدد التوجيهات المشتركة لأمن بيانات الذكاء الاصطناعي على سلسلة توريد البيانات ومصدرها	نادراً ما تقوم أدوات AppSec بنمذجة نسب البيانات بشكل جيد	عمليات التحقق من التوقيع، وتدقيق النسب، ومراقبة الانجراف، ومراجعة تغيير الوصول

يبدأ الفريق الأحمر المستمر للذكاء الاصطناعي من حيث تتوقف الماسحات الضوئية للحزم

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

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

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

التحول الذهني المفيد هو من "اختبر نموذجي" إلى "اختبر نظام تصنيع النماذج الخاص بي". الحقن الفوري والاستخدام غير الآمن للأدوات لا يزالان مهمين. تبقيهم OWASP بالقرب من القمة لسبب ما. لكن ميركور يوضح أنه يمكنك أن تخسر أرضية استراتيجية قبل أن يصل المهاجم إلى حدود موجه النموذج الخاص بك. إذا تم اختراق بائع التقييم، أو تبعية البوابة، أو إجراء CI، أو مسار النشر، فيجب أن يكون الفريق الأحمر قد وضع حواف الثقة هذه في النطاق بالفعل. (OWASP)

أنشئ خريطة سلسلة التوريد بالذكاء الاصطناعي قبل أن تكتب قاعدة كشف أخرى

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

ابدأ بحافة التبعية. ما هي مديري الحزم والسجلات والإجراءات ومصادر الحاويات والماسحات الضوئية التي تشارك في بيئات الإنشاء ووقت التشغيل. بالنسبة لكل منها، لاحظ ما إذا كانت المؤسسة تثق بالعلامات أو الملخصات أو الشهادات أو سجل المستودعات، وما إذا كانت عمليات التثبيت تحدث فقط في CI أو أيضًا على أجهزة الكمبيوتر المحمولة وأجهزة الكمبيوتر المحمولة وأجهزة الكمبيوتر المحمولة والمعاقل المشتركة وصناديق البحث المخصصة. إن تصريح Mercor لموقع TechCrunch بأنها كانت واحدة من آلاف المتضررين من حادثة LiteLLLLM هو تذكير بأن الإيذاء في المصب يبدأ غالبًا كاستهلاك عادي للتبعية. (تك كرانش)

ثم قم بتعيين حافة التحكم. أين توجد بيانات اعتماد موفر النموذج. أين توجد نُهج التوجيه. ما هي البوابات أو الوكلاء الذين يحتفظون بمفاتيح الموفرين المتعددين أو قواعد الميزانية أو سجلات التدقيق. كان حادث LiteLLLLM مهمًا لأن حزمة البوابة غالبًا ما تقع حيث يلتقي كل من الموفرين والسحابة والسجلات وتكامل الأدوات. يخبر استشاري GitHub صراحةً أي شخص قام بتثبيت الإصدارات الخبيثة وتشغيلها أن يفترض أن بيانات الاعتماد المتاحة مكشوفة. يجب أن يؤدي ذلك على الفور إلى رفع أي مكون شبيه بالبوابة إلى منطقة الجواهر التاجية أثناء تحديد النطاق. (جيثب)

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

أخيرًا، قم بتعيين حافة النشر. ما هي الهويات المسموح لها بنشر الحزم أو الصور أو النماذج أو المطالبات أو تعريفات سير العمل أو تكوين البوابة. هل هذه الهويات قصيرة الأجل أم طويلة الأجل. هل يمكن دفع القطع الأثرية للإصدار خارج مسار CI/CD المرئي. تشير المشكلة الرسمية لـ LiteLLLLM إلى أن الإصدارين 1.82.7 و1.82.8 الخبيثين تم تحميلهما مباشرةً إلى PyPI ولم يكونا أبدًا جزءًا من تدفق إصدار GitHub الرسمي. هذا هو بالضبط نوع الفجوة التي يجب أن تجعل خريطة سلسلة التوريد من المستحيل تجاهلها. (جيثب)

اصطياد نصف قطر انفجار LiteLLLLM في الريبوس والبيئات والقطع الأثرية

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

مثال الصدفة أدناه متحفظ عن قصد. فهو لا يقوم بحذف أي شيء أو تعديل البيئة. إنه يبحث عن مراجع الإصدارات الخطرة والمشبوهة .pth القطع الأثرية، وبعض المؤشرات الواضحة التي تهم لأن الحادثة تضمنت التنفيذ التلقائي من .pth الملف وحصاد بيانات الاعتماد عند بدء تشغيل Python. الأساس المنطقي للتحقق من .pth الملفات على أساس الإبلاغ عن حوادث LiteLLLLM نفسها. (جيثب)

#!/usr/bin/ENV bash
تعيين -euo pipefail

echo "== ابحث عن دبابيس LiteLLLLM الضعيفة =="
grep -RRInE 'litellm(====>>=||~~=||||=) ؟ 1\.82\.(7||8)\b' . \
  --إدراج='متطلبات*.txt' \' \
  --إدراج='pyproject.toml' \
  --إدراج='poetry.lock' \
  --إدراج ='Pipfile.lock' \
  --إدراج='uv.lock' 2> \Dev/null ||صحيح

صدى
صدى "== ابحث عن الحزم المثبتة في مواقع بايثون الشائعة =="
ابحث عن "${HOME}" \usr/local /opt -نوع D \( \( -اسم "حزم الموقع" -o -اسم "حزم التوزيع" \) 2>/dev/null || بينما تقرأ -r pkgdir؛ قم
  إذا كان ls "${pkgdir}"/Litellm-* 1>/dev/null 2>&1؛ ثم
    صدى "[+] وجدت LiteLLLLM تحت ${pkgdir}"
    ls -1 "${pkgdir}"/Litellm-* || صحيح
  fi
تم التنفيذ

صدى
صدى "== ابحث عن ملفات .pth المشبوهة =="
ابحث عن "${HOME}" /usr/local /opt -نوع f -اسم "*.pth" 2> /dev/null | بينما قراءة -r f؛ قم
  إذا كان grep -Eq 'subprocess\.popen |base64\.b64decdecode|exec\' "$f" 2>/dev/null؛ ثم
    صدى "[!] مرشح مشبوه .pth: $f"
    sed -n '1,5p' "$f"
  fi
تم

صدى
echo "== ابحث في سجل الصدفة وملفات الريبو عن الإصدارات السيئة المعروفة =="
grep -ReP -RINE 'pip(3)؟ تثبيت .*litellm(====>>=~=||||=)؟ 1\.82\.(7|8)\b' "${HOME}" 2>/dev/null |||صحيح

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

استيراد sys
استيراد ملف مضغوط
من Pathlib استيراد مسار من Pathlib

def inspect_wheel(path: str) -> لا شيء:
    عجلة = مسار(مسار)
    إذا لم تكن العجلة موجودة():
        رفع FileNotFoundError(عجلة)

    مع zipfile.ZipFile(wheel) ك zf:
        الأسماء = zf.namelist()
        pth_files = [n ل n في الأسماء إذا كان n.endswith(".pth")]
        طباعة(f"عجلة: {اسم العجلة}")
        طباعة(f"ملفات PTH: {pth_files أو 'لا شيء'}")

        بالنسبة إلى p في pth_files:
            البيانات = zf.read.read(p).decode("utf-8"، أخطاء="استبدال")
            طباعة(f"\n--- {p} ---")
            طباعة(بيانات[:500])

        Record_files = [n ل n في الأسماء إذا كان n.endswith("RECORD")]
        للسجل في Record_files
            record_data = zf.read.read(record).decode("utf-8", أخطاء="استبدال")
            مشبوه = [
                سطر للسطر في record_data.splitlines()
                إذا كان ".pth" في السطر أو "proxy_server.py" في السطر
            ]
            إذا كان المشتبه به
                طباعة(f"\n--- إدخالات السجل المشبوهة من {سجل} ---")
                للسطر في المشبوه
                    طباعة(سطر)

إذا __name__ = = "__main____":
    إذا كان len(sys.argv) != 2:
        طباعة ("الاستخدام: python inspect_wheel.py /path/to/package.whl")
        sys.exit(1)
    inspect_wheel(sys.argv[1])

فشل الاستجابة الشائع في هذه المرحلة هو البحث في مضيفي الإنتاج فقط. لا تفعل ذلك. تنص إرشادات GitHub على أن أي شخص قام بتثبيت الحزمة وتشغيلها يجب أن يفترض تعرض بيانات الاعتماد. تصف كل من مشكلات LiteLLLLM وإرشادات NHS السلوكيات المهمة على أجهزة الكمبيوتر المحمولة للمطورين ومضيفي CI بقدر ما هي مهمة على الخدمات طويلة العمر. بالنسبة لهذه الفئة من الحوادث، غالبًا ما تعيش أصولك من الدرجة الأولى حيث يقوم المهندسون بالاختبار والنشر، وليس حيث يتصل المستخدمون النهائيون. (جيثب)

إثبات أن مسار الإصدار الخاص بك جدير بالثقة

إن الدرس الأكثر ديمومة من LiteLLLLM و Trivy هو أن مراجعة المصدر والثقة في القطع الأثرية ليستا نفس التحكم.

يقول الإصدار الرسمي لـ LiteLLLLM أن إصدارات PyPI الخبيثة لم تصل إلى إصدارات GitHub CI/CD الرسمية للمشروع، وأن إصدارات GitHub وصلت إلى v1.82.6.dev1. وصلت القطعة الأثرية إلى المستخدمين على أي حال. وبعبارة أخرى، تباين تاريخ المستودع وواقع السجل. هذا هو بالضبط نوع الفشل الذي يميل المدافعون إلى التقليل من شأنه لأن الفرق مدربة ثقافياً على مراجعة الالتزامات وطلبات السحب والعلامات أكثر من مراجعة تحميلات الحزمة أو حالة السجل أو هوية الناشر. (جيثب)

توفر وثائق PyPI الخاصة اتجاهًا واضحًا لإصلاح جزء من هذه المشكلة. تقول أن رموز واجهة برمجة التطبيقات العادية طويلة الأجل ويمكن إساءة استخدامها حتى يتم إبطالها يدوياً في حال سرقت، بينما يتجنب النشر الموثوق ذلك من خلال سك رموز رمزية تنتهي صلاحيتها تلقائياً. تضيف وثائق التصديق الخاصة بـ PyPI تفاصيل مهمة أخرى: يتم دعم التصديقات حاليًا لهويات مثل GitHub Actions و GitLab CI/CD و Google Cloud. هذا يعني أن المشرفين على Python لديهم الآن مسار واقعي بشكل متزايد لجعل الثقة في النشر أكثر قابلية للتحقق آليًا بدلاً من تركها على نظام شرف الأسرار طويلة العمر. (مستندات PyPI)

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

يجب أن يعكس سير العمل المقوى للبنية التحتية للذكاء الاصطناعي عالية الثقة هذه الحقائق مباشرةً. إجراءات التثبيت. تقييد أذونات الرمز المميز. استخدام OIDC للوصول إلى السحابة بدلاً من تخزين بيانات الاعتماد السحابية طويلة الأمد. احتفظ بالبناء والمسح والتوقيع والنشر في مناطق ثقة منفصلة حيثما أمكن. تعامل مع "أدوات الأمان" على أنها تبعيات تتطلب نفس الشكوك مثل أي كود خارجي آخر. يعدّ تقرير LiteLLLLM بعد الوفاة حول بيئات CI المشتركة وبيانات الاعتماد الثابتة بمثابة علامة تحذير على مساحة التصميم بأكملها. (مستندات GitHub)

مثال الحد الأدنى من إجراءات GitHub يبدو كالتالي:

الاسم: إصدار-بيثون-حزمة-بيثون

على:
  دفع:
    العلامات:
      - "v*"

الأذونات:
  المحتويات: قراءة
  رمز التعريف: كتابة

وظائف:
  بناء:
    يعمل على: ubuntu-latest
    الخطوات:
      - الاسم: مصدر الخروج
        uses: actions/checkout@8ade135a41bc03ea155e62e844d188df1ea18608

      - الاسم: إعداد بايثون
        uses: actions/setup-python@42375524f3c5b80b6e5d5f6f8f6d6f0e3dcf7d7d
        مع:
          إصدار بايثون: "3.12"

      - الاسم: تثبيت أدوات الإنشاء
        تشغيل: |
          python -m pip install -upgrade pip
          نقطة تثبيت بناء الأنابيب

      - الاسم: بناء سديست وعجلة
        تشغيل: python -m build

      - الاسم: النشر إلى PyPI باستخدام النشر الموثوق به
        uses: pypa/gh-action-pypi-publish@c9e8d7b0e6a0c3d30b3d6a1c23cf0b9b95b4c5a6

أن YAML ليس حلاً سحرياً. لن يخلصك من كل تبعية مخترقة أو كل مشكلة من جانب السجل. لكنه يعالج ثلاث نقاط ضعف ملموسة كشفتها الحوادث الأخيرة: الثقة في المراجع القابلة للتغيير، والرموز المميزة المفرطة، والاعتماد المفرط على أسرار النشر طويلة الأمد. (مستندات GitHub)

تثبت حالة Trivy أن أدوات الأمان جزء من سطح الهجوم الخاص بك

لا تزال الكثير من الفرق تصنف ذهنيًا الأدوات الأمنية على أنها "بنية تحتية وقائية"، مما يدفعها إلى منحها امتيازات مفرطة وتقليل التدقيق. يجب أن تنهي تسوية تريفي هذه العادة.

يقول تحديث أكوا للحادثة أن المهاجم دفع بالقوة 76 من أصل 77 تريف-أكشن العلامات وجميع إعداد-تريبي واستخدم حساب خدمة مخترق لنشر ثنائية Trivy الخبيثة. وتشير أكوا صراحةً إلى أن المهاجم استخدم علامات الإصدار الحالية بحيث تستمر خطوط الأنابيب التي تعتمد بالفعل على تلك العلامات في تنفيذ التعليمات البرمجية المتغيرة دون إشارة واضحة. وتصف مدونة الرد من مايكروسوفت الحملة نفسها بأنها هجوم على سلسلة التوريد التي تركز على CI/CD، والتي استخدمت ماسحًا أمنيًا موثوقًا به كسلاح، ثم توسعت لاحقًا لتشمل KICS وLiteLLLM. (أكوا)

تعتبر مناقشة GitHub من أكوا أكثر فائدة من الناحية التشغيلية. فهي توفّر نوافذ التعرّض، وتحدد المراجع التي كانت آمنة، وتقول إن على الفرق التي تستخدم الإصدارات المخترقة أن تتعامل مع أسرار خط الأنابيب على أنها مخترقة وأن تقوم بتدويرها على الفور. كما يشير أيضًا إلى أن المراجع المثبتة في SHA كانت خارج المجموعة المتأثرة لمكونات إجراءات GitHub. وهذا مثال نادر لدرس في سلسلة التوريد يظهر في إرشادات الاستجابة نفسها. عندما يخبرك البائع أن المرجع غير القابل للتغيير هو المسار الآمن، لا تترجم ذلك إلى "أفضل الممارسات عندما يكون ذلك مناسبًا". تعامل معه على أنه تصميم تم اختباره في الحوادث. (جيثب)

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

إرشادات واستشارات مكافحة التطرف العنيف ذات الصلة التي تشرح النمط

تصبح قصة Mercor وLiteLLLLM أسهل في التفكير المنطقي عندما تضعها بجانب بعض حالات سلسلة التوريد الأخرى.

الأول ليس مكافح فيروسات CVE على الإطلاق، ولكنه يتصرف مثلها من الناحية التشغيلية: قام GitHub بمراجعة الإصدار GHSA-5mg7-485q-xm76 من GitHub ل LiteLLLM. وهو يشير إلى الإصدارات من 1.82.7 إلى 1.82.8 على أنها متأثرة، ويصنّف الخطورة على أنها حرجة، ويقول إنه لا يوجد أي مكافحة لمشكلة مكافحة التطرف العنيف معروفة في الاستشارة. والدرس المفيد هو أن المدافعين عن سلسلة التوريد لا يمكنهم الاقتصار على موجزات CVE. فغالبًا ما تحمل إرشادات GitHub، ومشكلات المشاريع، ومدونات الحوادث، ومحتوى الماسحات الضوئية في نهاية المطاف، أقرب إشارة قابلة للتنفيذ لأحداث الحزمة الخبيثة. (جيثب)

والثاني هو CVE-2025-30066، CVE-2025-30066، و TJ-إجراءات/تغيير-ملفات اختراق. وتصفها NVD بأنها حالة تم فيها إدخال شيفرة برمجية خبيثة عن طريق نقل علامات موثوقة إلى التزام خبيث، مما يسمح للمهاجمين باكتشاف الأسرار من خلال سجلات سير العمل. تصنّفها قاعدة بيانات GitHub الاستشارية ضمن الشيفرات البرمجية الخبيثة المضمّنة. الصلة هنا مباشرة: هذه حادثة أخرى لم يحتاج فيها المهاجم إلى اختراق تطبيقك من الباب الأمامي. لقد احتاجوا فقط إلى التلاعب بمكون موثوق به من مكونات CI والسماح لخط الأنابيب الخاص بك بتسليم الباقي. (nvd.nist.gov)

والثالث هو CVE-2024-3094، وهو الباب الخلفي لـ XZ Utils. يشرح وصف NVD أن الشيفرة الخبيثة كانت تعيش في كرات القطران وتعليمات الإنشاء في المنبع بدلاً من مجرد عرض المستودع العادي الذي تتوقع فرق التدقيق فيه. وهذا ما جعل الأمر فجوة ثقة كلاسيكية بين القطع الأثرية والمصدر. سبب انتمائها إلى هذه المناقشة ليس لأن XZ كانت "حزمة ذكاء اصطناعي". إنه ينتمي لأن LiteLLLLM أظهر نفس الدرس الهيكلي في نظام بيئي مختلف. لا يثبت تاريخ المستودع النظيف وجود قطعة أثرية نظيفة تم إصدارها. لا تكفي مراجعة البناء ذات المظهر الآمن إذا كان الشيء الذي يثبته المستخدمون يمكن تغييره أو نشره من خلال مسار آخر. (nvd.nist.gov)

يحوّل الجدول أدناه هذه الحوادث إلى مقارنة عملية.

الحادث	ما تم اختراقه	سبب أهمية ذلك هنا	حالة الاستغلال	ما الذي يجب أن يتعلمه المدافعون
GHSA-5mg7-485q-xm76 لـ GHSA-5mg7-485q-xm76 لـ LiteLLLM	إصدارات PyPI الحقيقية لحزمة بوابة الذكاء الاصطناعي المستخدمة على نطاق واسع	غالبًا ما تركز البنية التحتية للذكاء الاصطناعي على أسرار المزود والسحابة	تثبيت إصدارات الحزمة المتأثرة وتشغيلها	مراقبة الأنظمة البيئية الاستشارية خارج نطاق CVE، وفحص القطع الأثرية، والتناوب حسب تركيز الامتيازات
CVE-2025-30066	إجراء GitHub شائع في GitHub مع علامات منقولة ورمز خبيث	يمكن للثقة في CI/CD أن تكشف الأسرار دون لمس رمز التطبيق	يستخدم سير العمل مراجع الإجراءات المخترقة	تثبيت SHAs الكاملة وتقليل امتيازات سير العمل وسجلات التدقيق ونطاق الرمز المميز
CVE-2024-3094	عناصر الإصدار المنبع ومسار البناء ل XZ	مراجعة المصدر والثقة بالقطعة الأثرية ليستا نفس الرقابة	يقوم مستهلكو المصب ببناء أو تثبيت القطع الأثرية المسمومة	التحقق من مصدر الإصدار، وليس فقط من حالة الإصدار المستنسخ المصدر

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

لماذا لا تكفي عملية الحقن الفوري للذكاء الاصطناعي فقط في الفريق الأحمر

يبقى الحقن الفوري حقيقيًا وخطيرًا. تحافظ OWASP على الحقن الفوري ومعالجة الإخراج بالقرب من القمة لأن المحتوى المعادي يمكن أن يؤثر على سلوك LLM ويهدد الأنظمة النهائية. لا شيء من ذلك يتغير. ما يتغير بعد ميركور هو إدراك أن إساءة استخدام سلوك النموذج هو شريحة واحدة فقط من أمن الذكاء الاصطناعي، وليست دائمًا الشريحة التي تحمل أكثر المخاطر التنظيمية تركيزًا. (OWASP)

يمكن لفريق ما أن يقوم باختبار الحقن الفوري الجميل على مساعد مصقول بينما يغيب عنه حقيقة أن بائع التقييم الخاص به يسرب البيانات الوصفية للمشروع، وأن تبعية بوابة الذكاء الاصطناعي الخاصة به يمكن أن تشغل شيفرة تعسفية عند بدء تشغيل Python، وأن CI الخاص به يستخدم علامات إجراءات قابلة للتغيير، وأن نشر الحزمة الخاصة به لا يزال يعتمد على بيانات اعتماد طويلة العمر تم نسخها إلى بيئة عداء منذ أشهر. هذا ليس نقدًا لاختبار الحقن الفوري. إنه نقد للنطاق. فالنطاق الخاطئ يمكن أن ينتج تقريرًا مختصًا من الناحية الفنية على سطح تهديد خاطئ. (مستندات GitHub)

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

اختبار الجانب البشري وجانب البائعين في سلسلة التوريد الخاصة بالذكاء الاصطناعي

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

السبب واضح ومباشر. المنصات التي تواجه الإنسان تسرب البنية. يمكن لبوابة المتعاقد أن تكشف عن أسماء العملاء أو أسماء المشاريع أو فئات المهام أو تنسيقات المرفقات أو قواعد توجيه المهام أو أنماط الوصول حتى لو لم يحدث تسريب للبيانات الأولية. يمكن أن تكشف واجهة تسجيل العمل عن المشاريع النشطة، والمشاريع المتوقفة مؤقتًا، والفرق التي يتم إعادة توزيعها. يُظهر تقرير WIRED عن عمل ميتا المتوقف مؤقتًا في ميركور وسياق "Chordus" الداخلي مدى الحساسية التي يمكن أن تكمن في إدارة المشروع وحدها. (WIRED)

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

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

ما الذي يجب على المدافعين تغييره في هذا الربع

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

التغيير الثاني معماري. نقل النشر والنشر نحو الهويات التي تنتهي صلاحيتها ويمكن ربطها بسياق سير عمل تم التحقق منه. نموذج النشر الموثوق به الخاص بـ PyPI موجود لسبب ما. إذا كانت حزم Python ذات الصلة بالذكاء الاصطناعي لا تزال تعتمد على رموز النشر طويلة العمر التي تعيش في أسرار CI، فأنت تختار تحكمًا أضعف على الرغم من توفر نمط أقوى. ينطبق المبدأ نفسه على الوصول إلى السحابة من إجراءات GitHub من خلال OIDC. (مستندات PyPI)

التغيير الثالث تشغيلي. فرض مراجع غير قابلة للتغيير لإجراءات الطرف الثالث وسير العمل القابلة لإعادة الاستخدام حيثما أمكن. إن وثائق GitHub صريحة في أن التزامات SHAs كاملة الطول هي الخيار غير القابل للتغيير، وتوضح إرشادات Trivy من Aqua ما يحدث عندما تثق عمليات سير العمل بالعلامات القابلة للتغيير. عندما يكون التثبيت صعبًا من الناحية التشغيلية، قم بتوثيق الاستثناء وتعامل معه على أنه قبول للمخاطر، وليس كضوضاء في الخلفية. (مستندات GitHub)

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

التغيير الخامس تحليلي. تحديد أولويات الأسرار حسب تركيز الامتيازات، وليس حسب مالك الأصل. في حالة اختراق بوابة أو مخبر سري أو مخبر سري فإن السؤال الأهم ليس "أي نظام تأثر أولاً." بل هو "ما هي بيانات الاعتماد في تلك البيئة التي يمكن أن تفتح أوسع وصول ثانوي." إن إرشادات GitHub LiteLLLLM الاستشارية والكتابات التي تم تدوينها في الحادث تجعل هذا النموذج العقلي الصحيح. قم بتدوير المفاتيح التي تفتح القفل الأوسع نطاقاً أولاً. (جيثب)

الأدلة أكثر أهمية من لوحات المعلومات

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

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

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

إن الدرس الحقيقي المستفاد من ميركور يتعلق بأمن التصنيع النموذجي

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

ولهذا السبب فإن عبارة أمن سلسلة التوريد بالذكاء الاصطناعي تستحق أن تؤخذ على محمل الجد الآن. فهي ليست إعادة كتابة عصرية لمصطلح AppSec، بل تصف توسعاً حقيقياً لحدود الثقة حول أنظمة الذكاء الاصطناعي. إن تأطير سلسلة التوريد الخاص بمنظمة OWASP، ونموذج دورة حياة NCSC، وإرشادات أمن البيانات التي تقودها وكالة الأمن القومي الأمريكية للذكاء الاصطناعي، وعمل PyPI الخاص بـ PyPI في مجال الهوية والتصديق، وإرشادات GitHub الخاصة بتثبيت SHA، وتسلسل Mercor-LiteLLLLM-Trivy، كلها تشير إلى نفس الاتجاه. يجب أن يأخذ أمن الذكاء الاصطناعي في الحسبان التعليمات البرمجية والبيانات والبشر وسير العمل ومسارات النشر في نفس الوقت. (مشروع OWASP Gen AI Security Project)

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

مزيد من القراءة

• WIRED, ميتا توقف العمل مؤقتًا مع ميركور بعد اختراق البيانات الذي يعرض أسرار صناعة الذكاء الاصطناعي للخطر (WIRED)
• تك كرانش, شركة Mercor تقول إنها تعرضت لهجوم إلكتروني مرتبط باختراق مشروع LiteLLLLM مفتوح المصدر (تك كرانش)
• قاعدة بيانات استشارات GitHub الاستشارية, GHSA-5mg-5mg7-485q-xm76، تم نشر نسختين من LiteLLLM تحتويان على برمجيات خبيثة لحصاد بيانات الاعتماد (جيثب)
• LiteLLLLM تحديث أمني، حادثة سلسلة التوريد المشتبه فيها (لايت لالم)
• LiteLLLLM تحديثات المدينة الأمنية (لايت لالم)
• الأمن المائي, التحديث والتحقيق الجاري والتحقيق المستمر والمعالجة المستمرة (أكوا)
• مستندات GitHub, مرجع الاستخدام الآمن لإجراءات GitHub (مستندات GitHub)
• مستندات PyPI, الناشرون الموثوقون و الشهادات (مستندات PyPI)
• اللجنة الوطنية للأمن الغذائي العالمي, إرشادات لتطوير نظام ذكاء اصطناعي آمن (المركز الوطني للخدمات الاجتماعية)
• وكالة الأمن القومي إعلان إرشادات أمن بيانات الذكاء الاصطناعي (وكالة الأمن القومي)
• NVD, CVE-2024-3094 (nvd.nist.gov)
• قاعدة بيانات استشارات NVD و GitHub الاستشارية, CVE-2025-30066 (nvd.nist.gov)
• بنليجنت تعرض LiteLLLLLM على PyPI للاختراق، وما الذي غيّره الهجوم وما الذي يجب على المدافعين فعله الآن (بنليجنت)
• بنليجنت مساعد الفريق الأحمر للذكاء الاصطناعي، ما الذي يصمد في المشاركة الحقيقية (بنليجنت)
• بنليجنت كيفية الحصول على تقرير اختبار الذكاء الاصطناعي الخماسي (بنليجنت)
• الصفحة الرئيسية لـ Penligent (بنليجنت)