هجوم TanStack: كيف تحوّلت مصادقة SLSA إلى سلاح ضد سلسلة ثقة CI/CD

الهجوم الذي كسر ضماناً أمنياً

يقوم أمن سلسلة توريد البرمجيات على افتراض أساسي: إذا كانت الحزمة تحمل مصادقة صحيحة، فقد بُنيت من كود مصدري موثوق عبر نظام CI/CD موثوق. كسر هجوم TanStack في مايو 2026 هذا الافتراض.

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

تتطور سلسلة الهجوم عبر أربع مراحل يجب على كل مهندس CI/CD فهمها:

المرحلة الأولى — تسميم ذاكرة التخزين المؤقت: أدخل fork يتحكم فيه المهاجم ثنائيات خبيثة في ذاكرة التخزين المؤقت لـ GitHub Actions.

المرحلة الثانية — استخراج رمز OIDC: خلال تشغيل سير عمل قياسي أعاد استخدام الذاكرة المؤقتة المسمومة، استخرجت الثنائيات الخبيثة رموز OpenID Connect مباشرةً من ذاكرة عملية المنفّذ.

المرحلة الثالثة — النشر الخبيث: باستخدام رمز OIDC المسروق، نشرت TeamPCP 84 إصداراً لحزم على npm تحت مساحة الاسم @tanstack.

المرحلة الرابعة — تنفيذ الحمل الخبيث: كل إصدار خبيث احتوى على ملف JavaScript مُعتم بحجم 2.3 ميغابايت باسم router_init.js يحصد بيانات الاعتماد من بيئة المطور ويسرّبها عبر شبكة المراسلة اللامركزية Session/Oxen. أي عفريت استمرارية مدمر اسمه gh-token-monitor كان سيمحو الدليل الرئيسي للمستخدم إذا جرى إلغاء رموز GitHub.

نشرة التنبيهات السيبرانية CC-4781 من NHS Digital أكدت النطاق متعدد الأنظمة البيئية للهجوم وأثره على أدوات قطاع الرعاية الصحية.

ما يجب على فرق الهندسة فعله

1. معاملة مصادقة SLSA كضرورة لكنها غير كافية

تُعيد حادثة TanStack تأطير مصادقة SLSA من إشارة ثقة إلى إشارة تتبع. المصادقة تُخبرك أين بُنيت الحزمة؛ لا تُخبرك ما إذا كانت بيئة البناء نظيفة في تلك اللحظة. المنظمات التي أزالت الحزم غير المعتمدة من قوائم السماح بعد عام 2024 تحتاج الآن إلى إضافة طبقة ثانية: تحليل السلوك وقت التشغيل والفحص بعد التثبيت. أدوات مثل مراقبة سلسلة التوريد من Socket.dev أو مراجعة التبعيات في GitHub Advanced Security ترصد الشذوذات السلوكية — استدعاءات الشبكة وقت التثبيت وإنتاج العمليات وأنماط الوصول إلى مسارات بيانات الاعتماد — التي لا تستطيع المصادقة رصدها.

2. عزل منفّذات GitHub Actions عن مخازن بيانات الاعتماد

تطلّب استخراج رمز OIDC في هجوم TanStack تشغيل الثنائيات الخبيثة داخل العملية على منفّذ Actions. تأكد أن منفّذات CI/CD لا تملك وصولاً مباشراً إلى مخازن بيانات الاعتماد في بيئة الإنتاج أو أدوار IAM السحابية ذات صلاحيات الكتابة أو رموز نشر npm ذات نطاق واسع. استخدم رموز OIDC قصيرة الأجل ومحدودة النطاق مع قيود صريحة على الجمهور المستهدف. رموز نشر npm ذات الدقة العالية من GitHub صُممت تحديداً لهذا النموذج من التهديد.

3. مراجعة كل مدخل في ذاكرة التخزين المؤقت لـ GitHub Actions هذا السبرنت

نقطة الدخول كانت مدخلاً مسموماً في الذاكرة المؤقتة. أجرِ مراجعة فورية: سرّد كل مفاتيح الذاكرة المؤقتة النشطة (gh cache list)، وتحقق من سير العمل الذي أنشأ كل مدخل، واحذف أي مدخلات لا يمكن نسبها إلى تشغيل سير عمل معروف ونظيف. مستقبلاً، ربط مفاتيح الذاكرة المؤقتة بهاشات SHA للإيداعات بدلاً من أسماء الفروع.

4. تثبيت التبعيات على هاشات Digest المتحقق منها وليس على نطاقات الإصدار

نطاقات إصدار الحزم (^1.2.0، ~2.3) هي الآلية التي سمحت بسحب الحزم الخبيثة من TanStack تلقائياً من قِبل مشاريع كانت تثق بالفعل في مساحة الاسم @tanstack. ثبّت كل تبعية مباشرة وعابرة على هاش digest غير قابل للتغيير في ملف القفل الخاص بك، وتحقق من فشل قناة CI/CD إذا تغير ملف القفل دون مراجعة كود مقابلة.

5. الاشتراك في تغذيات أمن النظام البيئي وأتمتة الاستجابة

تم الكشف عن حادثة TanStack من قِبل باحث خارجي في 20-26 دقيقة — أسرع من تنبيهات الأمن الداخلية لمعظم المنظمات. المنظمات التي تستخدم حزم @tanstack كانت ستحصل على إشارة قابلة للتنفيذ خلال الساعة لو اشتركت في نشرات أمان npm أو GitHub Security Advisories أو تغذيات الطرف الثالث مثل OSV.dev. أتمتة الاستجابة: قم بتكوين قناة إدارة التبعيات لحجب البنيات تلقائياً عند ظهور أي حزمة على أي من هذه التغذيات.

الدرس البنيوي: سلاسل الثقة بقوة أضعف افتراضاتها

هجوم TanStack برهان دقيق على مخاطر سلسلة التوريد من الدرجة الثانية: الخصوم الذين لا يستطيعون كسر ضماناتك التشفيرية سيخترقون السياق الذي تُمارَس فيه تلك الضمانات. مصادقة SLSA متينة تشفيرياً. رموز OIDC متينة تشفيرياً. ذاكرة عملية المنفّذ ليست كذلك.

مراقبة Unit 42 المستمرة لهجمات سلسلة توريد npm توثق اتجاهاً واضحاً: تتزايد تعقيد الهجمات بسرعة أكبر من تبني الضوابط الدفاعية. لا يوجد ضابط واحد يجعل قناة CI/CD جديرة بالثقة. الدفاع يتطلب طبقات — مصادقة المصادر ومراقبة السلوك وقت التشغيل وتثبيت التبعيات وعزل المنفّذات وتنبيهات النظام البيئي السريعة — لا تكفي أي منها بمفردها.

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

المصادر والقراءات الإضافية

• هجوم سلسلة توريد npm على TanStack — تحليل تفصيلي — Rescana
• مراقبة هجمات سلسلة توريد npm — Unit 42، Palo Alto Networks
• تعزيز أمن سلسلة التوريد — GitHub Blog
• تنبيه سيبراني CC-4781: اختراق سلسلة توريد TanStack — NHS Digital
• Instructure تبرم اتفاقية فدية — The Hacker News