بقلم: ليلى | محررة أدوات المطورين · صوت تحريري بإشراف بشري
بعد أقل من شهر من الاختراق الأول، نجحت مجموعة TeamPCP الإجرامية في اختراق نفس حساب مايكروسوفت على GitHub مرة أخرى، هذه المرة لحقن 73 حزمة برمجية مفتوحة المصدر بكود خبيث متطور يُسمى Miasma. البرمجية الخبيثة تنشط تلقائياً عند فتح الحزم المصابة في وكلاء البرمجة بالذكاء الاصطناعي مثل Claude Code وGemini CLI وCursor وVS Code، لتبدأ في سرقة بيانات اعتماد المطورين من AWS وAzure وGoogle Cloud Platform.
(وفقاً لـ StepSecurity)، اكتشفت الأنظمة الآلية في GitHub الحزم الخبيثة وحجبتها، لكن مايكروسوفت لم تحذر المطورين صراحة من ضرورة افتراض تعرض أنظمتهم للاختراق. بدلاً من ذلك، اكتفت GitHub بالقول إن الحزم “انتهكت شروط الخدمة” وشجعت المالكين على التواصل مع الدعم الفني.
الصمت الأولي من مايكروسوفت كان مقلقاً. لم تعترف الشركة بإمكانية وجود محتوى خبيث إلا يوم الاثنين، بعد أيام من اكتشاف الاختراق، حين قالت في بريد إلكتروني مقتضب: “أزلنا مؤقتاً بعض المستودعات بينما نحقق في محتوى خبيث محتمل”. هذا التأخير في التحذير وضع آلاف المطورين في خطر محتمل دون علمهم.
الهجوم الحالي يشكل تطوراً خطيراً عن الاختراق الأول في مايو، الذي استهدف حزمة durabletask Python SDK على PyPI. تلك الحزمة، التي تحصل على 400,000 تحميل شهرياً، تُستخدم لبناء سير عمل مقاوم للأخطاء في الأنظمة الموزعة. (وفقاً لـ StepSecurity)، نجح المهاجمون في سرقة بيانات اعتماد مايكروسوفت للنشر، ما مكنهم من تجاوز خط أنابيب البناء بالكامل.
Miasma ليست مجرد برمجية خبيثة عادية. إنها نسخة محسّنة من مجموعة أدوات Mini Shai-Hulud التي طورتها TeamPCP ونشرتها كمصدر مفتوح مؤخراً. (وفقاً لـ Cloudsmith)، تحصد البرمجية رموز OIDC (OpenID-Connect) المستخدمة في إثبات SLSA، وهو نظام يوفر ضمانات مشفرة لسلامة البرمجيات.
الذكاء في Miasma يكمن في قدرتها على تقليد سير العمل الشرعي تماماً. تطلب رمز OIDC شرعي من GitHub، ثم تنشر إصداراً خبيثاً مع إثبات SLSA صحيح، ما يجعل أدوات المسح التقليدية تعتبرها تحديثاً موثوقاً. الأخطر من ذلك، تولد البرمجية حمولة مشفرة فريدة لكل إصابة منفردة، ما يجعل كشفها بواسطة التوقيعات التقليدية مستحيلاً عملياً.
التحديث الأحدث من Miasma يستهدف هويات الحوسبة السحابية بشكل خاص. بينما ركزت الإصدارات السابقة على سرقة الأسرار المحلية فقط، تحتوي النسخة الحالية على مجمعات بيانات متقدمة مصممة خصيصاً لـ GCP وAzure. تحاول حصد كل هوية سحابية يمكن للجهاز المصاب وخدمات CI/CD الوصول إليها، بهدف واضح للمهاجمين للانتقال من قاعدة الكود إلى البيئات السحابية المباشرة.
ما يجعل الوضع أكثر إثارة للقلق هو أن نفس حساب مايكروسوفت المخترق في مايو هو المستخدم في الهجوم الأخير. هذا يثير تساؤلات جدية: إما أن مايكروسوفت فشلت في تغيير بيانات اعتماد الحساب بالكامل بعد الاختراق الأول، وإما أن حزمة خبيثة مجهولة تعمل على أجهزة مطوري مايكروسوفت أنفسهم نجحت في سرقة البيانات الجديدة.
الهجوم لا يقتصر على مايكروسوفت. (وفقاً لـ Open Source Malware)، استُخدمت تقنيات مماثلة في هجوم منفصل لتسميم عشرات حزم Red Hat، ما يشير إلى حملة واسعة النطاق تستهدف سلسلة التوريد البرمجية بأكملها.
Andrew McNamara من Red Hat شرح في تحليل مفصل كيف تكشف هذه الهجمات عن حدود نظام SLSA الحالي. المشكلة الأساسية أن البروتوكولات الأمنية الحديثة صُممت لحماية سلامة الكود، وليس لكشف اختراق بيانات اعتماد المطورين. عندما يسرق المهاجمون بيانات اعتماد شرعية، يصبح من المستحيل تمييز النشاط الخبيث عن النشر الطبيعي.
التحدي التقني واضح، لكن الإشكالية الأكبر تكمن في الاستجابة. لماذا لم تصدر GitHub تحذيراً واضحاً فور اكتشاف الحزم الخبيثة؟ لماذا انتظرت مايكروسوفت أياماً قبل الاعتراف بالمشكلة؟ هذا التأخير في التواصل يضع المطورين في خطر غير ضروري ويقوض الثقة في النظام البيئي للتطوير.
المطورون الذين تعاملوا مع أي من الحزم الـ73 المصابة يواجهون الآن مهمة معقدة: فحص شامل لأنظمتهم، تدوير جميع بيانات الاعتماد، ومراجعة أذونات الحوسبة السحابية. مع قدرة Miasma على الانتشار جانبياً عبر البنية التحتية السحابية، قد تتطلب المعالجة إعادة بناء البيئات المصابة من الصفر.
هذا الحادث يكشف عن أزمة ثقة أساسية في النظام البيئي للتطوير الحديث. لا يمكن للمطورين الاعتماد على التوقيعات المشفرة والشهادات الأمنية كضمانة مطلقة. نحتاج إلى مراجعة جذرية لنموذج الثقة الحالي، مع آليات مراقبة أكثر تطوراً ونظم عزل أفضل، خاصة مع تزايد اعتماد وكلاء الذكاء الاصطناعي التي تصل إلى النظام بأكمله. الحل لا يكمن في المزيد من التشفير، بل في إعادة تصميم كيفية إدارة الثقة في سلسلة التوريد البرمجية.
