سلسلة التوريد
تعتمد الملايين من مسارات تطوير البرامج المؤتمتة على أدوات أمنية – مثل Trivy وCheckmarx AST – المدمجة في عملية الإنشاء. ومن المفارقة أن هذه الحلول الموثوقة تحديدًا هي التي أصبحت مؤخرًا نقطة الانطلاق لواحد من أكبر وأخطر هجمات سلسلة التوريد في التاريخ الحديث. ونناقش في هذا المقال كيفية تدقيق سير العمل المؤتمت وتأمين البنية التحتية السحابية للمؤسسات.
المخطط الزمني للهجوم والعواقب المعروفة
في 19 مارس، نُفذ هجوم سلسلة توريد ناجح وموجه عبر أداة Trivy، وهي أداة مفتوحة المصدر لفحص الثغرات تُستخدم على نطاق واسع في مسارات التكامل المستمر / النشر المستمر (CI/CD). وقد تمكن المهاجمون – وهم مجموعة تُعرف باسم TeamPCP – من حقن برامج ضارة داخل سير عمل GitHub Actions الرسمي وصور Docker المرتبطة بحل Trivy. ونتيجة لذلك، أدت كل عملية فحص آلي للمسارات إلى تفعيل برامج ضارة سرقت مفاتيح SSH، ورموز الوصول السحابي، ومحافظ العملات المشفرة، وغيرها من البيانات القيمة من الأنظمة المخترقة. ونظرًا لخطورة الحادث، خُصص له المعرف CVE-2026-33634، مع درجة خطورة CVSS4B بلغت 9.4، وهي درجة قريبة من الحد الأقصى.
في وقت لاحق من اليوم نفسه، اكتشف فريق Trivy الهجوم وأزال الملفات الخبيثة من قنوات التوزيع، مما أدى إلى إيقاف هذه المرحلة من الهجوم. ومع ذلك، كان المهاجمون قد تمكنوا بالفعل من الوصول إلى بيئات العمل الخاصة بالكثير من مستخدمي Trivy.
في 23 مارس، كُشف حادث مماثل في أداة أمنية أخرى للتطبيقات: وهي إحدى إجراءات GitHub (GitHub Action) الخاصة بـ Checkmarx KICS، بالإضافة إلى Checkmarx AST. وبعد مرور ثلاث ساعات، أُزيلت التعليمات البرمجية الخبيثة من هناك أيضًا. وتمكنت كذلك مجموعة TeamPCP من اختراق ملحقات OpenVSX التي تدعمها Checkmarx، وتحديدًا cx-dev-assist 1.7.0 وast-results. وتتضارب التقارير حول التوقيت الذي تم فيه حل هذا الجزء من الحادث.
في 24 مارس، تعرض مشروع شهير يستخدم فحص التعليمات البرمجية عبر Trivy للهجوم – وهو بوابة الذكاء الاصطناعي LiteLLM، وهي مكتبة عالمية للوصول إلى مزودي نماذج اللغة الكبيرة (LLM) المختلفين. وتم اختراق الإصدارين 1.82.7 و1.82.8 اللذين رُفعا إلى مستودع PyPI. وظلت هذه الإصدارات متاحة للجمهور لمدة خمس ساعات تقريبًا.
لكن حقيقة أن الهجوم استمر لبضع ساعات فقط ليست سببًا للتغاضي عنه. ونظرًا لشعبية المشاريع المتضررة، كان من الممكن تنفيذ التعليمات البرمجية الضارة آلافًا من المرات – بما في ذلك داخل البنية التحتية لشركات كبرى جدًا.
أتاح ذلك للمهاجمين نشر أبواب خلفية دائمة في مجموعات Kubernetes، فضلًا عن إطلاق فيروس CanisterWorm ذاتي التكاثر عبر منظومة npm الخاصة بلغة JavaScript.
تتمتع التعليمات البرمجية الخاصة المهاجمين بقدرات تدميرية تؤدي إلى محو مجموعات Kubernetes وجميع عقدها تمامًا في حال اكتشافها إما التوقيت الزمني لمدينة طهران، أو اللغة الفارسية بصفتها لغة أساسية في النظام المخترق. وفي مناطق أخرى، تكتفي البرامج الضارة بسرقة البيانات باستخدام فيروس CanisterWorm.
وفقًا للخبراء، يُعتبر أكثر من 20000 مستودع برامج عرضة للخطر المحتمل. ويدعي المهاجمون أنهم سرقوا مئات الجيجابايت من البيانات وأكثر من نصف مليون حساب.
كيف تعرض Trivy للهجوم
لاختراق Trivy، استخدم المهاجمون بيانات اعتماد سُرقت في حادث سابق. ويبدو أن اختراق Trivy السابق، الذي وقع في أواخر فبراير، لم يتم احتواؤه كليًا، حيث عادت مجموعة TeamPCP نفسها لشن هجوم جديد. ويرجح مطورو Trivy في شركة Aqua Security أنه نظرًا لإلغاء بيانات الاعتماد تدريجيًّا عقب الحادث السابق، تمكن المهاجمون من إنشاء رموز وصول جديدة لأنفسهم قبل إلغاء الرموز القديمة المخترقة.
نتيجة لذلك، تمكنت مجموعة TeamPCP من اختراق إجراءات GitHub المستخدمة في مسارات التكامل المستمر / النشر المستمر (CI/CD). وباستخدام بيانات اعتماد تمنح صلاحيات كتابة العلامات، أعاد المهاجمون كتابة 76 علامة إصدار من أصل 77 في مستودع aquasecurity/trivy-action قسريًا، بالإضافة إلى جميع العلامات السبع في aquasecurity/setup-trivy، مما أدى إلى إعادة توجيه الإصدارات الموثوقة الحالية إلى إيداعات ضارة. وتشبه هذه الطريقة التكتيكات التي رُصدت في حملة Shai-Hulud 2.0. ونتيجة لهذا، بدأت تدفقات العمل عبر المسار بالكامل في تنفيذ التعليمات البرمجية الخاصة بالمهاجمين، في حين لم تظهر البيانات الوصفية للإصدار أي تغييرات مرئية.
في الوقت ذاته، نشر المهاجمون ملفًا ثنائيًا مصابًا من أداة Trivy (الإصدار v0.69.4) عبر قنوات التوزيع الرسمية، بما في ذلك إصدارات GitHub وسجلات الحاويات.
اختراق LiteLL
قد يتسبب اختراق أداة LiteLLM الشهيرة – المخصصة للوصول إلى نماذج اللغات – فذ حد ذاته في موجة كبرى من الهجمات عبر سلسلة المشاريع التي تستخدم الأداة. ووقع الهجوم في 24 مارس 2026، عندما نشرت مجموعة TeamPCP نسخًا ضارة من المكتبة (1.82.7 و1.82.8) على مستودع PyPI مباشرةً. وفي الفترة ما بين الساعة 10:39 والساعة 16:00 (بالتوقيت العالمي المنسق)، احتوت هذه الحزم المخترقة على برامج ضارة لسرقة بيانات الاعتماد. وزُرعت داخل ملف proxy_server.py، كما تضمن الإصدار 1.82.8 ملف litellm_init ضارًا أيضًا. وتم تسريب البيانات المسروقة إلى خادم يدعى models.litellm[.]cloud.
لم يتأثر العملاء الذين يستخدمون LiteLLM Cloud أو صورة Docker الرسمية لنموذج LiteLLM Proxy، وذلك بفضل سياسة التثبيت الصارم للإصدارات، وفي المقابل، تعرض المطورون والمشاريع التابعة التي قامت بتثبيت إصدارات غير محددة عبر pip خلال النافذة الزمنية المذكورة للاختراق.
في غضون ثلاث ساعات، أُزيلت الحزم الخبيثة من مستودع PyPI، كما علّق فريق LiteLLM الإصدارات الجديدة، وقام بتغيير بيانات الاعتماد، وبدأ عملية استجابة خارجية للحادث. وتُنصح الفرق التي تستخدم LiteLLM في مشاريعها بالتحقق الفوري من مؤشر الاختراق litellm_init.pth، وتغيير جميع الأسرار البرمجية التي يُحتمل تسريبها دوريًا.
خصائص البرنامج الضار TeamPCP Cloud Stealer
أضاف المهاجمون منطقًا جديدًا إلى إجراءات GitHub والملف القابل للتنفيذ لحل Trivy مع الحفاظ على الوظائف الأصلية للأداة. وبدت نتائج فحص الثغرات الأمنية عبر Trivy طبيعية، لكن في الوقت نفسه كان يجري البحث عن بيانات قيمة واستخراجها. وكانت التعليمات البرمجية الضارة تنفذ ما يلي:
- إجراء عمليات الاستطلاع (جمع بيانات الشبكة ومتغيرات البيئة)؛
- البحث عن الرموز وبيانات الاعتماد للوصول إلى البيئات السحابية AWS وGCP؛
- فحص الذاكرة (/proc/*/mem) لاستخراج الأسرار المخزنة في ذاكرة عمليتي Runner.Worker وRunner.Listener؛
- استخراج أسرار Kubernetes من المسار (/run/secrets/kubernetes.io/serviceaccount)؛
- جمع البيانات الخاصة بالاتصال بخوادم قواعد البيانات (MySQL وPostgreSQL وMongoDB وRedis وVault)؛
- جمع أي مفاتيح لواجهة برمجة التطبيقات أو أسرار برمجية أخرى من ملفات البيئة وملفات تكوين التكامل المستمر / النشر المستمر (مثل .env و.json و.yml)؛
- البحث عن روابط الويب الخاصة بقنوات Slack وDiscord؛
- البحث عن البيانات المتعلقة بمحافظ العملات المشفرة (المتغيرات المرتبطة بسلسلة كتل Solana، بالإضافة إلى بيانات rpcuser وrpcpassword).
جرت عملية تشفير البيانات المجموعة ورفعها إلى خادم يحمل اسمًا مشابهًا لاسم مطوري Trivy وهي (scan.aquasecurtiy[.]org). وكآلية دعم احتياطية، وفر المهاجمون طريقة لرفع البيانات إلى مستودع يحمل الاسم docs-tpcp.
استخدم الهجوم على CheckMarx وLiteLLM تكتيكًا مماثلاً عبر نطاقات (Domains) أخرى تعتمد على التمويه الإملائي (Typosquatting)، وهي: models.litellm[.]cloud وcheckmarx[.]zone.
يمكنك العثور على تحليل تقني مفصل للبرامج الضارة، إلى جانب مؤشرات الاختراق، في مقال خبيرنا على مدونة Securelist.
إستراتيجيات الاستجابة والدفاع ضد الثغرة CVE-2026-33634
لم تعد عمليات التحقق المستندة إلى التوقيعات الرقمية وفحص التبعات في المستودعات العامة كافية، حيث حُقنت التعليمات البرمجية الضارة مباشرة في إجراءات موثوقة وموقعة رقميًا، وتمكنت من التهرب من الاكتشاف حتى طُبقت الرقابة السلوكية. وأصبحت مسارات التكامل المستمر/ النشر المستمر(CI/CD) هي المحيط الأمني الجديد.
إجراءات فورية. تأكد أن جميع مسارات العمل تستخدم إصدارات آمنة (ملف Trivy القابل للتنفيذ 0.69.3، وtrivy-action 0.35.0، وsetup-trivy 0.2.6).
يجب على مسؤولي مسارات التكامل المستمر / النشر المستمر وفرق الأمان مراجعة تبعاتهم لحلول Checkmarx (مثل kics-github-action وast-github-action) وTrivy (مثل setup-trivy وtrivy-action) على الفور. وإذا كانت مسارات العمل تشير إلى علامة إصدار بدلًا من تجزئة SHA محددة، فراجع سجلات تنفيذ مسارات العمل بعناية طوال فترة هجوم سلاسل التوريد النشط.
يجب عليك أيضًا فحص سجلات الشبكة بحثًا عن أي حركة مرور متجهة إلى النطاقات: scan.aquasecurtiy[.]org وcheckmarx[.]zoneوmodels.litellm[.]cloud. ويشير وجود مثل هذه الحركة إلى أنه تسريب بيانات حساسة بنجاح.
إذا ظهر مستودع باسم docs-tpcp على حساب المؤسسة في GitHub، فقد يشير ذلك أيضًا إلى وقوع خرق ناجح للبيانات.
افحص الأجهزة المضيفة والمجموعات بحثًا عن علامات الاختراق – مثل وجود ملفات ~/.config/sysmon/sysmon.py أو وحدات مشبوهة في بيئة Kubernetes.
امسح ذاكرة التخزين المؤقت وقم بإجراء جرد لوحدات PyPI: افحص بحثًا عن أي وحدات ضارة، وعد إلى إصدارات نظيفة.
في جميع الأحوال، يجب إجراء عملية التقصي الاستباقي عن التهديدات، بافتراض أن الأنظمة قد اختُرقت بنجاح وأن المهاجمين قد تغلغلوا سريعًا داخل الأنظمة المتضررة.
يُوصى باستعادة البيئات المتضررة من نسخ احتياطية جرى التحقق منها.
تثبيت التبعات وإدارة كلمات السر. تأكد من تثبيت إصدارات التبعات بدقة باستخدام البصمات التشفيرية في جميع المسارات وملفات Docker. وننصح بالانتقال من الرموز طويلة الأمد إلى بيانات اعتماد قصيرة الأجل عبر استخدام أدوات إدارة كلمات السر، وتفعيل تكامل OIDC حيثما كان مدعومًا. قلل من حقن كلمات السر في بيئة التشغيل قدر الإمكان – ولا تفعل ذلك إلا عند الضرورة القصوى. كما يجب التأكد من عدم تخزين كلمات السر على القرص الصلب أو في ملفات مؤقتة، وعدم إعادة استخدامها عبر عمليات مختلفة.
قم بتغيير جميع بيانات الاعتماد التي يُحتمل اختراقها – بما في ذلك مفاتيح واجهة برمجة التطبيقات ومتغيرات البيئة ومفاتيح SSH، ورموز حساب الخدمة في Kubernetes، وأي كلمات سر أخرى.
تدابير أمان أخرى. لا تسمح إلا بإجراءات GitHub الواردة في القائمة المعتمدة من قبل المؤسسة؛ واحظر العمليات الجديدة وغير الموثوقة. وقم بتكوين GITHUB_TOKEN ومفاتيح الوصول الأخرى وفقًا لمبدأ الحد الأدنى من الامتياز. ولا تمنح أذونات الكتابة إلا عند الضرورة القصوى.
لتعزيز أمان إجراءات GitHub، تتوفر العديد من الأدوات مفتوحة المصدر:
- zizmor – أداة للتحليل الساكن واكتشاف أخطاء التكوين في إجراءات GitHub؛
- gato وGato-X — نسختان من أداة تساعد في تحديد مسارات العمل الضعيفة بنيويًا؛
- allstar — تطبيق GitHub، طوّرته مؤسسة OpenSSF، لتكوين وفرض السياسات الأمنية في مؤسسات ومستودعات GitHub؛
إذا كنت ترغب في معرفة المزيد عن هجمات سلاسل التوريد، فنحن ندعوك للاطلاع على تقريرنا التحليلي بعنوان: تفاعلات سلاسل التوريد: تأمين النظام البيئي الرقمي العالمي في عصر الترابط. ويستند هذا التقرير إلى رؤى استخلصها خبراء تقنيًا، ويكشف عن مدى تكرار واجهة المؤسسات لمخاطر سلاسل التوريد والعلاقات الموثوقة، وأماكن وجود فجوات الحماية، والإستراتيجيات التي يجب اتباعها لتعزيز المرونة ضد هذا النوع من التهديدات.
