هجمات سلسلة التوريد في الذكاء الاصطناعي: ما تكشفه الحوادث الأخيرة عن أمن بنية الذكاء الاصطناعي

في 24 مارس 2026، كان باحث في FutureSearch يقوم بمهمة روتينية. كانت المهمة تثبيت حزمة بايثون لمشروع. في غضون دقائق، بدأت محطة العمل تتصرف بشكل غير طبيعي. 

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

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

ما حدث: هجوم متعدد المراحل على سلسلة التوريد

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

الخطوة 1: في 19 مارس، اخترقت TeamPCP برنامج Trivy، وهو ماسح ضوئي أمني مفتوح المصدر يستخدم على نطاق واسع ومدمج في مسارات CI/CD للعديد من المشاريع.

الخطوة 2: باستخدام نقطة الوصول هذه، حصلوا على بيانات اعتماد النشر الخاصة بـ PyPI لمشرف مكتبة وكيل LLM شهيرة يتم تنزيلها حوالي 3.4 مليون مرة يوميًا.

الخطوة 3: في 24 مارس، قاموا بتحميل نسختين خبيثتين من الحزمة إلى PyPI. كانت النسخ المخترقة نشطة لمدة ثلاث ساعات تقريبًا قبل أن يقوم PyPI بعزلها.

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

داخل الحمولة: ثلاث مراحل للاختراق

نفذت الحزمة الخبيثة حمولة متطورة من ثلاث مراحل وثقها باحثو الأمن في Snyk بالتفصيل.

المرحلة الأولى — جمع المعلومات. حمولة الهجوم جمعت بصمت كل ما استطاعت العثور عليه: مفاتيح SSH الخاصة، وبيانات اعتماد الوصول لـ AWS و GCP، وكيانات خدمة Azure، وإعدادات Kubernetes، وملفات .env، وبيانات اعتماد Git، وكلمات مرور قواعد البيانات، وسجل الأوامر، وأسرار CI/CD، وعبارات استعادة محافظ العملات المشفرة.

المرحلة الثانية — التشفير والتسريب. تم تشفير البيانات التي تم جمعها ونقلها إلى خادم يتحكم فيه المهاجم. تم إنشاء ملفات مؤقتة (session.key, payload.enc, tpcp.tar.gz) في دليل الملفات المؤقتة بالنظام خلال هذه العملية.

المرحلة الثالثة — الاستمرارية والحركة الجانبية. حمولة الهجوم قامت بتثبيت سكربت بايثون خلفي متنكر في هيئة خدمة systemd تُسمى "System Telemetry Service". هذا السكربت المستمر كان يستعلم عنوان URL يتحكم فيه المهاجم كل خمس دقائق بحثًا عن أوامر جديدة — وكان قادرًا على الانتشار عبر مجموعة Kubernetes بأكملها عن طريق نشر وحدات (pods) ذات امتيازات إلى كل عقدة في kube-system.

ما جعل هذا خطيرًا بشكل خاص هو آلية التسليم: ملف .pth. تُنفذ ملفات تهيئة مسار بايثون تلقائيًا كلما بدأت أي عملية بايثون — بما في ذلك pip نفسه، وخطوات بناء CI/CD، ومُشغلات الاختبار. لم يكن عليك تشغيل تطبيقك. كل ما كان عليك فعله هو تثبيت الحزمة، وقد تم تشغيل حمولة الهجوم.

لماذا تُعد البنية التحتية للذكاء الاصطناعي هدفًا خاصًا

الحزمة المتأثرة لم تُختر عشوائيًا. أحد أكثر المواقع امتيازًا في مكدس البرمجيات الحديث هو موقع وكلاء نماذج اللغة الكبيرة (LLM) وبوابات الذكاء الاصطناعي. عند تثبيت وإعداد بوابة LLM، فإنك تضعها في موقع وسيط مباشر بين التطبيقات ومقدمي خدمات الذكاء الاصطناعي المستخدمين. لديها وصول إلى مفاتيح API الخاصة بـ OpenAI، وبيانات اعتماد Anthropic، وحسابات خدمة Azure و Google Cloud Platform. لديها وصول إلى متغيرات البيئة، وفي كثير من الحالات، إلى مدير الأسرار. هذا مصمم عن قصد وضروري لتوجيه الطلبات، وفرض حدود المعدل، وتسجيل الاستخدام. هذا هو السلوك المقصود.

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

لماذا لم تكتشف أطر الامتثال ذلك

الحزمة المعنية كانت تحمل شهادات SOC 2 Type 1 و ISO 27001. يستحق هذا الأمر الفحص ليس لانتقاد تلك الأطر — فهي مهمة، والفرق التي تسعى إليها تفعل الشيء الصحيح — ولكن لأنه يوضح فجوة هيكلية.

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

حتى التحقق القياسي من تجزئة pip لم يكن ليكشف هذا الهجوم. تم الإعلان عن ملف .pth الخبيث في النسخة المخترقة بشكل صحيح في ملف RECORD الخاص بالحزمة مع تجزئة مطابقة. اجتازت الحزمة كل فحص سلامة توفره PyPI. لقد كانت حزمة صالحة صودف أنها تم تسليحها.

هذا هو أمن سلسلة التوريد فجوة يحتاج النظام البيئي للذكاء الاصطناعي تحديدًا إلى سدها: السؤال ليس فقط "هل أنظمتنا آمنة؟" بل "هل الأدوات التي نستخدمها لبناء أنظمتنا وتأمينها آمنة؟"

Key Metrics for Evaluating Gateway

Criteria	What should you evaluate ?	Priority	TrueFoundry
Latency	Adds <10ms p95 overhead for time-to-first-token?	Must Have	✅ Supported
Data Residency	Keeps logs within your region (EU/US)?	Depends on use case	✅ Supported
Latency-Based Routing	Automatically reroutes based on real-time latency/failures?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported
Key Rotation & Revocation	Rotate or revoke keys without downtime?	Must Have	✅ Supported

Evaluating an AI Gateway?

A practical guide used by platform & infra teams

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form.

كيف تفكر TrueFoundry في هذه المشكلة

في TrueFoundry، أمان سلسلة التوريد هو شاغل رئيسي في كيفية تصميمنا لمنصة MLOps الخاصة بنا — وليس مجرد فكرة لاحقة.

عندما تنشر الشركات النماذج و بوابات LLM عبر TrueFoundry، نطرح سؤالاً مختلفًا: ليس فقط "هل نقطة النهاية هذه آمنة؟" بل "ما هو نطاق الضرر إذا تم اختراق أي مكون في هذه الحزمة؟"

تحدد بعض المبادئ كيفية بنائنا:

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

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

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

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

ما يجب على فريقك فعله الآن

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

1. تحقق من إصدارات الحزم المثبتة لديك. قم بتشغيل pip show litellm | grep Version. إذا أظهر الإخراج الخاص بك 1.82.7 أو 1.82.8، فاعتبر النظام مخترقًا ولا تقم بالترقية في مكانها ببساطة. قد تكون الحمولة قد تم تشغيلها بالفعل. أعد البناء من حالة نظيفة على جهاز معروف بنظافته.

2. تدقيق ملفات .pth عبر الأجهزة ومُشغّلات التكامل المستمر (CI).

find $(python3 -c "import site; print(' '.join(site.getsitepackages()))") \
  -name "*.pth" -exec grep -l "base64\|subprocess\|exec" {} \;

3. تحقق من وجود آثار الاستمرارية.

ls -la ~/.config/sysmon/sysmon.py 2>/dev/null && echo "BACKDOOR FOUND"
systemctl --user status sysmon.service 2>/dev/null
ls /tmp/tpcp.tar.gz /tmp/session.key /tmp/payload.enc 2>/dev/null

4. قم بتغيير بيانات الاعتماد بشكل مكثف. إذا كان لأي جهاز متأثر وصول إلى بيانات اعتماد السحابة، مفاتيح SSH، مفاتيح API، رموز حساب خدمة Kubernetes، أو كلمات مرور قواعد البيانات، فقم بتغييرها جميعًا الآن. لا تقيّم — غيّر. استهدفت الحمولة بشكل خاص AWS Secrets Manager، وSSM Parameter Store، وأسرار مجموعات Kubernetes عبر جميع مساحات الأسماء.

5. تحقق من Kubernetes بحثًا عن الحاويات الضارة (pods).

kubectl get pods -A | grep "node-setup-"

الحاويات (Pods) المسماة node-setup-{node_name} في مساحة الأسماء kube-system هي مؤشر معروف على الاختراق من هذه الحملة.

6. اتجه نحو سجل حزم خاص. PyPI ليس الخيار الوحيد لحل التبعيات. مرآة حزم خاصة ذات تجزئات مثبتة (pinned hashes) وسير عمل للموافقة تقضي على هذه الفئة الكاملة من ناقلات الهجوم. يمكن لأدوات مثل Artifactory أو AWS CodeArtifact أو Google Artifact Registry أن تعمل كوسطاء.

7. تعامل مع سلسلة توريد CI/CD الخاصة بك كسطح هجوم. لم يكن الاختراق الأولي في حملة TeamPCP للمكتبة المستهدفة — بل كان لماسح الأمان المستخدم في خط أنابيب التكامل المستمر (CI) لتلك المكتبة. البنية التحتية للبناء الخاصة بك، وإجراءات GitHub الخاصة بك، وتكاملات الجهات الخارجية كلها جزء من سطح الهجوم الخاص بك. قم بتدقيقها وفقًا لذلك.

النمط الأوسع: هذا ليس معزولاً

ما يجعل هذه الحالة مثيرة للاهتمام بشكل خاص هو أنها لم تكن هجومًا انتهازيًا. بل إن TeamPCP ينفذ هذه الحملة المجهدة منذ ديسمبر 2025 على الأقل. قبل مهاجمة LiteLLM، اخترق TeamPCP ماسح الأمان Trivy الخاص بـ Aqua (19 مارس)، وإضافات VS Code وإجراءات GitHub الخاصة بـ CheckMarx (23 مارس)، والعديد من حزم NPM التي تحتوي على دودة ذاتية الانتشار.

لاحظ أن زوج مفاتيح RSA المستخدم مطابق لما استخدم في جميع الهجمات الأخرى، وكذلك اسم حزمة tpcp.tar.gz ومستودعات GitHub ذات البادئة tpcp-docs. يشير هذا إلى أن TeamPCP هو فاعل تهديد محترف ينفذ حملته بشكل منهجي.

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

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

مشكلة الثقة التي تحتاج البنية التحتية للذكاء الاصطناعي إلى حلها

لقد بنى النظام البيئي للذكاء الاصطناعي شيئًا استثنائيًا في وقت قصير جدًا. السرعة والانفتاح اللذان جعلا ذلك ممكنًا — ثقافة 'pip install' والمشاركة، والبناء على عمل بعضنا البعض، هي أمور قيمة حقًا وتستحق الحفاظ عليها.

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

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

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

يمكن لصناعة الذكاء الاصطناعي أن تبني بشكل أفضل. بل يجب عليها ذلك.

الأسئلة الشائعة 

ما هو هجوم سلسلة توريد البرمجيات؟

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

كيف يمكن لفرق الذكاء الاصطناعي وتعلم الآلة حماية بنيتها التحتية من هجمات سلسلة التوريد؟

تتطلب حماية بنية الذكاء الاصطناعي وتعلم الآلة من هجمات سلسلة التوريد عدة إجراءات متكاملة. يجب على الفرق استخدام سجل حزم خاص (مثل AWS CodeArtifact، أو Google Artifact Registry، أو Artifactory) مع تجزئات تبعيات مثبتة بدلاً من السحب مباشرة من PyPI العام. يمكن أن يكشف التدقيق المنتظم لملفات .pth في أدلة حزم موقع Python عن الإضافات الضارة مبكرًا. يحد تشغيل بنية الذكاء الاصطناعي — بما في ذلك بوابات LLM ومكونات خدمة النماذج — ضمن شبكة VPC خاصة من قدرة المهاجم على تسريب بيانات الاعتماد إلى خوادم خارجية حتى لو تم اختراق تبعية. يُمكّن الاحتفاظ بقائمة مكونات البرمجيات (SBOM) لمكدس تعلم الآلة الخاص بك من تحديد التعرض بشكل أسرع عند الكشف عن حادث جديد. أخيرًا، يجب التعامل مع مسارات CI/CD نفسها كسطح هجوم: فالأدوات المستخدمة لبناء وتأمين البرمجيات — بما في ذلك الماسحات الأمنية وإجراءات GitHub — يمكن أن تتعرض للاختراق وقد تعرضت بالفعل كجزء من حملات سلسلة التوريد الأوسع.

ما هي العوامل التي يجب على الفرق مراعاتها عند تقييم بوابة LLM الآمنة للتخفيف من مخاطر هجمات سلسلة التوريد؟

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