برنامج LiteLLM على PyPI يتعرض لهجوم من TeamPCP: نظرة معمقة على حملة البرامج الضارة لسرقة بيانات الاعتماد

الرئيسية » Python » برنامج LiteLLM على PyPI يتعرض لهجوم من TeamPCP: نظرة معمقة على حملة البرامج الضارة لسرقة بيانات الاعتماد

لبضع ساعات في 24 مارس 2026، تحولت حزمة بايثون شائعة الاستخدام إلى أداة قوية لسرقة بيانات الاعتماد. وقد تم تسريب نسختين خبيثتين من LiteLLM، وهي مكتبة تُستخدم على نطاق واسع كـ واجهة موحدة لنماذج اللغة الكبيرة (LLMs)تم تحميلها إلى PyPI، مما أدى لفترة وجيزة إلى تعريض عدد هائل من الأنظمة لهجوم متطور على سلسلة التوريد.

النسخ الخبيثة، 1.82.7 و1.82.8تضمنت الحملة حزمة برمجية خبيثة متعددة المراحل قادرة على سرقة البيانات السرية من أجهزة المطورين، وأنظمة التكامل المستمر/التسليم المستمر، والبنية التحتية السحابية، ومجموعات Kubernetes، ثم نقلها إلى خوادم يتحكم بها المهاجمون. مرتبط بمجموعة التهديد TeamPCPوالتي استمرت لعدة أشهر في شن هجمات على Trivy وأدوات Checkmarx وصور Docker، هجمات على سلسلة توريد npm والآن نظام PyPI البيئي.

ما هو برنامج LiteLLM ولماذا كان هدفًا رئيسيًا؟

LiteLLM هو مكتبة بايثون مفتوحة المصدر وخادم وكيل يعمل هذا كنوع من المحول العالمي لواجهات برمجة تطبيقات إدارة التعلم. فهو يسمح للتطبيقات بالتواصل مع أكثر من مائة نموذج مختلف - من مزودين مثل OpenAI و Anthropic و Google و AWS Bedrock و Vertex AI وغيرهم - من خلال واجهة برمجة تطبيقات واحدة على غرار OpenAI.

وبسبب هذا الدور، أصبح المشروع جزءًا لا يتجزأ من منظومة الذكاء الاصطناعي. وتشير تقارير من العديد من موردي الأمن إلى أن LiteLLM تشهد ما يقارب 3-3.4 مليون عملية تنزيل يوميًا، مع بعض القياسات عن بعد التي تشير إلى وجوده في حوالي 36% من بيئات الحوسبة السحابية التي تمت مراقبتهابالنسبة للمهاجمين، يمثل اختراق حزمة بهذه البصمة فرصة نادرة للوصول إلى تدفق هائل من البيانات الحساسة وبيانات الاعتماد بخطوة واحدة.

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

كما يُبرز هذا الحادث مدى تشابك عملية التطوير الحديثة: فمحطات العمل المحلية، وخطوط أنابيب التكامل المستمر/التسليم المستمر، ومجموعات Kubernetes، وحسابات الحوسبة السحابية، كلها مرتبطة ببعضها البعض عبر أسرار مشتركة وأتمتة. التبعية المتأثرة في ذلك الرسم البياني قد يؤدي ذلك في النهاية إلى كشف بيانات الاعتماد عبر العديد من طبقات بنية المؤسسة، مما يضخم التأثير إلى ما هو أبعد من مضيف واحد.

كيف تم إدخال إصدارات LiteLLM الخبيثة

الانبعاثات المسمومة LiteLLM 1.82.7 و 1.82.8 تم تحميلها على PyPI صباح يوم 24 مارس 2026، حوالي 08: 30 بالتوقيت العالميوظلت متاحة لما يقرب من ساعتين قبل أن يقوم فريق أمن PyPI بعزلها وحظرها بواسطة أنظمة حماية خارجية، وقد تم الإبلاغ عن إزالتها في حوالي الساعة 10:30 صباحًا. 11: 25 بالتوقيت العالمي.

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

وعلى وجه التحديد، لاحظ المحللون أن الملف litellm/proxy/proxy_server.py احتوى على حمولة مضمنة مشفرة بنظام base64 والتي كانت غير موجود في نفس الملف في عملية الالتزام على GitHubتم إدراج حوالي اثني عشر سطرًا بين كتل برمجية سليمة (على سبيل المثال، بالقرب من تعريف REALTIME_REQUEST_SCOPE_TEMPLATE و مبادئ السلوك showwarning (وظيفة). كانت تلك الأسطر الإضافية تقوم بفك تشفير وتنفيذ نص برمجي مخفي بصمت كلما تم استيراد الوحدة.

في الإصدار 1.82.8ثم ذهب المهاجمون إلى أبعد من ذلك بإسقاط .pth ملف اسمه litellm_init.pth في بيئة بايثون. لأن بايثون تعالج كل شيء .pth يتم تشغيل الملفات عند بدء تشغيل المفسر، وهذا يضمن تشغيل الحمولة. في كل استدعاء لـ Python، حتى لو لم يتم استيراد LiteLLM نفسه بواسطة التطبيق.

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

الارتباط بحملة TeamPCP الأوسع

لم يحدث اختراق LiteLLM بمعزل عن غيره. فقد ربطت تحقيقات أجرتها شركات Sonatype وWiz وEndor Labs وغيرها هذا الاختراق بـ حملة مستمرة لسلسلة التوريد تديرها شركة TeamPCP، وهي مجموعة اكتسبت الاهتمام في أواخر عام 2025، ومنذ ذلك الحين استهدفت سلسلة من مشاريع المصادر المفتوحة وأنظمة المطورين البيئية.

في وقت سابق من شهر مارس، ارتبط نفس الممثلين بعملية التلاعب بالباب الخلفي لـ تريفي من شركة أكوا سيكيوريتي ماسح الثغرات الأمنية وإجراءات GitHub ذات الصلة، بالإضافة إلى المتغيرات الخبيثة لأدوات Checkmarx، بما في ذلك KICS، وامتدادات GitHub Actions وOpenVSX. كما شملت الحملة حزم npm وصور Docker Hub وبيئات Kubernetes، مع إعادة استخدام متكررة للبنية التحتية وأنظمة التشفير وعناصر التخزين.

بالرجوع إلى حادثة LiteLLM، كشف القائمون على الصيانة أن رمز نشر PyPI تم تسريب رمز مميز مخزن كمتغير بيئي في مستودع GitHub الخاص بشركة LiteLLM عبر عملية اختراق سير عمل Trivy. ثم أُسيء استخدام هذا الرمز لـ انشر إصدارات PyPI الملوثةمما يُمكّن المهاجمين من تجاوز الحماية الثنائية على حسابات المستخدمين وحقن برامج ضارة دون تغيير شفرة المصدر العامة.

يشير الباحثون أيضًا إلى عمليات إيداع مشبوهة وسير عمل تم إنشاؤها حوالي 23 مارس في مستودعات مرتبطة بـ LiteLLM، بما في ذلك فرع قصير الأجل وسير عمل GitHub Actions يحمل مفتاح RSA عامًا مألوفًا يُستخدم في حمولات TeamPCP الأخرى. تشير بيانات القياس عن بُعد من عمليات تشغيل سير العمل إلى أنه ربما تم الوصول إلى الأسرار المتاحة لمشغلي التكامل المستمر هؤلاء وتسريبها.

أظهرت المجموعة نمطاً ثابتاً في جميع الحوادث: سرقة بيانات الاعتماد في بيئة واحدة، ثم الانتقال إلى النظام البيئي التاليفي هذه الحالة، سمح خطأ في تكوين GitHub Actions الخاص بـ Trivy بسرقة رمز مميز؛ وأدى هذا الرمز إلى إصدارات Trivy الخبيثة وصور Docker؛ والتي بدورها مكنت من اختراق أدوات Checkmarx وفي النهاية حزمة LiteLLM PyPI.

كيف يعمل برنامج LiteLLM الخبيث

تصف تحليلات من عدة موردين ثغرة LiteLLM بأنها... حمولة بايثون متعددة المراحل ومشفرة باستخدام Base64 صُممت لتكون خفية ومرنة وقوية. يتم تنظيم منطقها في ثلاث طبقات تقريبًا، كل منها تتعامل مع مرحلة مختلفة من الهجوم.

في الطبقة الأولى، الكود المُدخل في proxy_server.py أو ال litellm_init.pth ملف يقوم بفك تشفير وتشغيل منسق خفيبدلاً من استخدام وظائف يسهل تمييزها مثل exec()يعتمد البرنامج النصي على استدعاءات العمليات الفرعية ووظائف المكتبة القياسية لتشغيل الحمولة التي تم فك تشفيرها والتقاط مخرجاتها، مما يساعدها على الاندماج في سلوك التطبيق العادي.

بمجرد تشغيل هذا النظام، يقوم بتجميع مخرجات المرحلة اللاحقة، يقوم بتشفير البيانات التي تم جمعها باستخدام AES-256-CBC ثم يقوم بتشفير مفتاح جلسة AES نفسه باستخدام مفتاح RSA عام مُضمّن في الكود. يتم تجميع البيانات المشفرة والمفتاح في أرشيف باسم tpcp.tar.gz، على غرار عمليات فريق PCP الأخرى، ومستعدة لعملية التهريب.

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

• مفاتيح SSH وملفات التكوين (العميل والخادم)
• بيانات اعتماد السحابة بالنسبة لخدمات AWS وGCP وAzure، بما في ذلك الرموز المميزة المشتقة من البيانات الوصفية
• ملفات kubeconfig الخاصة بـ Kubernetesرموز حساب الخدمة وأسرار المجموعة
• ملفات البيئة مثل .env تُستخدم المتغيرات غالبًا لتخزين مفاتيح واجهة برمجة التطبيقات (API).
• تكوين CI/CDالأسرار ورموز الوصول
• Terraform و Helm وغيرها من مكونات البنية التحتية كبرنامج أو مكونات النشر
• سلاسل اتصال قاعدة البيانات وملفات التكوين
• مفاتيح TLS/SSL الخاصة ومواد التوثيق
• محافظ Cryptocurrency والبيانات ذات الصلة

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

توفر الطبقة الثالثة المثابرة والتحكم عن بعديقوم بكتابة نص برمجي بلغة بايثون على القرص (يُشار إليه عادةً باسم sysmon.pyويقوم بتسجيلها كخدمة طويلة الأمد، وغالبًا ما تكون متخفية تحت مسمى "خدمة قياس بيانات النظام". تتصل هذه الخدمة بشكل دوري ببنية المهاجم التحتية، عادةً كل 50 دقيقة، لجلب أوامر أو حمولات إضافية.

لاحظ الباحثون سلوكًا غريبًا هنا: عندما حاولت بعض شركات الأمن الحصول على الحمولة من نقطة التحكم والسيطرة، رد الخادم برابط لنسخة مُعاد تصميمها من أغنية "Bad Apple!!"، على ما يبدو كـ تكتيك تضليل ضد التحليل الآليأما في الأنظمة المصابة، فيمكن لنفس الآلية أن تقدم وظائف جديدة بهدوء بمرور الوقت.

قنوات تسريب البيانات وبنية المهاجمين التحتية

خلال حوادث LiteLLM، لاحظ المحللون وجود اتصال مع نطاقين رئيسيين على الأقل يسيطر عليهما المهاجمون: نماذج سحابة تيل و منطقة تشيك ماركستتوافق هذه مع البنية التحتية المستخدمة في أنشطة TeamPCP السابقة وتؤدي أدوارًا متميزة.

الأرشيف المشفر tpcp.tar.gz عادة تم تحميلها إلى models.litellmcloudمما يسمح للمشغلين باستعادة بيانات الاعتماد المسروقة من آلاف البيئات التابعة. في بعض المتغيرات، مسارات فرعية مختلفة من checkmarxzone (فمثلا، checkmarxzone/raw or .../vsxتُستخدم هذه الأدوات لتسليم البرامج النصية الخاصة بالاستمرارية أو المراحل الإضافية.

أبلغ المدافعون عن مجموعة من المشكلات المتكررة في الأنظمة المخترقة. مؤشرات الاختراق (IoCs) مرتبط ببرنامج LiteLLM الخبيث:

• وجود الأرشيف tpcp.tar.gz في الأدلة المؤقتة أو أدلة العمل
• ملفات مؤقتة مثل /tmp/pglog و /tmp/.pg_state
• برنامج بايثون ومسارات التكوين المتعلقة بـ sysmon.py وملف خدمة مطابق (غالباً ما يكون موجوداً ضمن أدلة تكوين المستخدم أو systemd)
• غير متوقع litellm_init.pth ملفات في حزم موقع بايثون للإصدار 1.82.8
• حركة المرور الصادرة أو عمليات البحث في نظام أسماء النطاقات (DNS) التي تشير إلى نماذج سحابة تيل or منطقة تشيك ماركس

تم تتبع المنطق الخبيث إلى ملفات تتضمن proxy_server.py (LiteLLM 1.82.7 و 1.82.8) و litellm_init.pth (1.82.8). قام موردو الأمن بفهرسة التجزئات ومؤشرات الاختراق الإضافية، ويواصلون تحديث نصائحهم مع ظهور تفاصيل الطب الشرعي الإضافية.

التأثير على بيئات الذكاء الاصطناعي والحوسبة السحابية والتكامل المستمر/التسليم المستمر

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

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

والجدير بالذكر أن البرامج الضارة تؤكد سلوك مدرك لـ Kubernetesفي العديد من التحليلات، تحاول الحمولة الخبيثة نشر وحدات pods ذات امتيازات عالية على جميع العُقد في المجموعة، ثم تستخدم هذه الوحدات للوصول إلى البيانات السرية وكائنات التكوين. وفي عمليات TeamPCP منفصلة ولكنها ذات صلة، لاحظ الباحثون استهداف مجموعات Kubernetes ببرامج نصية تمسح العُقد عندما يبدو أن البيئة موجودة في إيران، بينما تقوم بتثبيت أبواب خلفية (مثل ما يُسمى بـ CanisterWorm) في أماكن أخرى.

ويتضح التركيز على أدوات التكامل المستمر/التسليم المستمر (CI/CD) بشكل مماثل. فمن خلال اختراق Trivy GitHub Actions، وإضافات Checkmarx VS Code وGitHub Actions، والآن LiteLLM، يحصل المهاجمون على نقاط دخول حيث تتمتع الأتمتة بالفعل بامتيازات واسعة عبر المستودعات، ومخرجات البناء، وبيانات اعتماد النشر. هذا النهج يحوّل الأدوات التي كانت موجهة نحو الأمن إلى أدوات تمهيدية لاختراق أوسع.

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

خطوات الكشف والاحتواء والمعالجة

بالنسبة للمؤسسات التي ربما تكون قد سحبت أو نفذت إصدارات LiteLLM 1.82.7 أو 1.82.8 من خلال PyPI، كانت التوجيهات المقدمة من موردي الأمن والقائمين على صيانة PyPI صريحة وواضحة: تعامل مع الأنظمة المتأثرة على أنها مخترقةإن مجرد إلغاء تثبيت الحزمة لا يزيل آليات الثبات أو يتراجع عن أي سرقة بيانات اعتماد قد تكون حدثت بالفعل.

تشمل الإجراءات الفورية الموصى بها ما يلي:

• حدد أي منشآت من LiteLLM 1.82.7 أو 1.82.8 عبر أجهزة المطورين، و CI/CD runners، والحاويات، وبيئات الإنتاج.
• قم بإزالة النسخ الضارة وربط LiteLLM بإصدار جيد معروف (مع الإشارة على نطاق واسع إلى الإصدار 1.82.6 باعتباره آخر إصدار نظيف في وقت إعداد التقرير).
• قم بتدوير جميع بيانات الاعتماد يمكن الوصول إليها من البيئات المتأثرة: مفاتيح SSH، ومفاتيح ورموز موفر الخدمة السحابية، وأسرار Kubernetes، وأسرار CI/CD، وبيانات اعتماد قاعدة البيانات، ومفاتيح TLS وأي محافظ أو أسرار متعلقة بالدفع.
• ابحث عن آثار استمرار البيانات، مثل sysmon.pyتعريفات خدمة systemd المشبوهة، والملفات غير العادية الموجودة ضمن ~/.config أو أدلة مؤقتة مثل /tmp/pglog و /tmp/.pg_state.
• فحص مجموعات Kubernetes بالنسبة للوحدات ذات الامتيازات غير المتوقعة، وخاصة في مساحات الأسماء مثل kube-systemوكذلك بالنسبة لحسابات الخدمة غير العادية أو ربط الأدوار.
• مراقبة الاتصالات الصادرة واستعلامات نظام أسماء النطاقات (DNS) لنطاقات المهاجمين المعروفة مثل models.litellmcloud و checkmarxzone.

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

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

ماذا تقول قضية LiteLLM عن سلاسل توريد برامج الذكاء الاصطناعي؟

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

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

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

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

بالنسبة للمطورين والمنظمات على حد سواء، يمثل حل LiteLLM الوسطي تذكيراً بأن التعامل مع الأسرار، وتأمين التكامل المستمر/التسليم المستمر، وتدوير بيانات الاعتماد تُعدّ هذه العناصر أساسية لأمن سلسلة التوريد. وقد أدى عدم اكتمال عملية تدوير بيانات الاعتماد أو عدم دقتها في الحوادث السابقة إلى ترك ثغرات تمكن فريق TeamPCP من إعادة استخدامها بعد أسابيع، مما يُظهر كيف يمكن لخطأ واحد في الاستجابة للحوادث أن يتسبب في سلسلة من التداعيات عبر الأنظمة البيئية.

بدأت الحملة التي اجتاحت شركة LiteLLM بما بدا وكأنه مشكلة محدودة في سير العمل، ومنذ ذلك الحين امتدت لتشمل GitHub Actions وDocker Hub. حادثة شاي هولود npm، OpenVSX و PyPI. مع وجود أبواب خلفية مخفية في أدوات موثوقة على نطاق واسع وموصلات الذكاء الاصطناعي، وتدفق بيانات الاعتماد المسروقة إلى البنية التحتية للمهاجمين، تؤكد هذه الحلقة مدى سرعة تحول سلسلة توريد البرامج إلى سطح هجوم جذاب وفعال للغاية.