لم يكن الخطر في حملة GlassWorm مقتصرًا على إصابة جهاز مطور واحد. القيمة الحقيقية للمهاجم كانت في الصلاحيات التي يملكها هذا الجهاز: مستودعات GitHub، ومفاتيح SSH، ورموز الوصول إلى سجلات الحزم، وأسرار الخدمات السحابية، وبيئات CI/CD التي تستطيع نشر تحديثات يثق بها آلاف المستخدمين.
كُشف GlassWorm علنًا في أكتوبر 2025 بعد العثور على إضافات ضارة مرتبطة ببيئات تطوير مثل VS Code وOpen VSX. وخلال الأشهر التالية تطورت الحملة وظهرت حالات مرتبطة بحسابات نشر موثوقة وحزم ومستودعات برمجية أخرى. وفي 26 مايو 2026 أعلنت CrowdStrike، بالتعاون مع جهات أخرى، تنفيذ عملية لتعطيل قنوات القيادة والتحكم المعروفة للحملة.
لذلك أصبحت GlassWorm مثالًا مهمًا على نوع مختلف من هجمات Software Supply Chain: بدل مهاجمة المنتج النهائي مباشرة، يحاول المهاجم الوصول إلى الشخص أو الأداة التي تبنيه أو تنشره، ثم يستغل الثقة الموجودة أصلًا في سلسلة التطوير لتوسيع نطاق الإصابة.
ما هو GlassWorm؟
نشرت شركة Koi Security في 18 أكتوبر 2025 الكشف التقني الأول عن GlassWorm بعد رصد إضافات خبيثة في Open VSX. تضمنت العينات تقنيات لإخفاء أجزاء من الشيفرة باستخدام محارف Unicode غير مرئية، إلى جانب آليات للحصول على عناوين بنية القيادة والتحكم وتنفيذ وظائف لسرقة بيانات حساسة من بيئة المطور.
استهداف إضافة داخل محرر أكواد يختلف عن ملف خبيث عشوائي يصل إلى مستخدم عادي. الإضافة تعمل في بيئة قد تحتوي أصلًا على أسرار ومفاتيح وأدوات تطوير، وقد يستطيع المطور من الجهاز نفسه الوصول إلى مستودعات خاصة أو نشر حزمة جديدة أو تشغيل بنية إنتاجية.
وهذا هو السبب في أن السؤال الأهم في هذه الحملة ليس فقط: «ماذا يفعل الملف الخبيث؟»، بل: ما الذي يستطيع المهاجم الوصول إليه بعد السيطرة على بيئة المطور؟
لماذا أصبح المطور هدفًا جذابًا في هجمات Supply Chain؟
المطور ليس مجرد مستخدم يمتلك حسابًا على GitHub. في بيئة تطوير حقيقية قد توجد على جهازه أو ضمن جلساته النشطة بيانات اعتماد تسمح بالوصول إلى عدة طبقات من سلسلة البرمجيات.
- حسابات ومستودعات GitHub أو GitLab.
- مفاتيح SSH وGit credentials.
- رموز npm وPyPI وسجلات حزم أخرى.
- أسرار مخزنة في متغيرات البيئة أو ملفات إعداد محلية.
- اعتمادات لخدمات AWS أو Azure أو Google Cloud.
- جلسات مصادقة وأدوات سطر أوامر مرتبطة بحسابات العمل.
- صلاحيات على أنظمة CI/CD أو أسرار مستخدمة داخل خطوط البناء والنشر.
- مفاتيح توقيع أو حسابات تسمح بنشر إصدار جديد من برنامج موثوق.
أكدت CrowdStrike في تحليلها لعملية تعطيل GlassWorm أن مطوري البرمجيات كانوا أهدافًا ذات قيمة مرتفعة بسبب وصولهم إلى الشيفرة المصدرية والبنية السحابية وأنظمة CI/CD وسجلات الحزم. وذكرت أيضًا استخدام برمجيات مرتبطة بالحملة لسرقة بيانات اعتماد مكّنت المهاجمين من تلويث مئات مستودعات GitHub.
كيف يتحول اختراق جهاز مطور إلى هجوم على سلسلة البرمجيات؟
لا تحتاج كل حملة إلى المسار نفسه، لكن النموذج العام يمكن تبسيطه إلى سلسلة من المراحل المترابطة:
- الوصول الأولي: يثبّت المطور إضافة أو حزمة تبدو شرعية، أو يتم الاستيلاء على حساب ناشر موثوق ثم دفع تحديث ضار إلى مستخدمين حاليين.
- التنفيذ داخل بيئة التطوير: تعمل الشيفرة الضارة أثناء استخدام الأداة أو تثبيت الاعتماد أو تنفيذ أحد Scripts المرتبطة بالحزمة.
- جمع الأسرار: يبحث المهاجم عن Tokens ومفاتيح وملفات إعداد وجلسات مصادقة وبيانات اعتماد أخرى.
- توسيع الوصول: تُستخدم البيانات المسروقة لمحاولة الوصول إلى مستودعات أو سجلات حزم أو خدمات CI/CD وحسابات سحابية.
- الانتقال إلى سلسلة التوريد: إذا امتلك المهاجم صلاحيات نشر، فقد يعدّل مستودعًا أو Workflow أو حزمة أو إضافة موثوقة.
- الوصول إلى الضحايا اللاحقين: يحصل مستخدمون آخرون على الإصدار الضار من مصدر يثقون به أصلًا.
هذه النقطة هي ما يجعل Supply Chain Attack أكثر خطورة من إصابة محلية تقليدية. الثقة في اسم المطور أو الحزمة أو Marketplace قد تتحول إلى وسيلة توزيع للمهاجم.
ولا تقتصر المشكلة على إضافات VS Code. فقد أظهرت حوادث أخرى كيف يمكن لحزم Python أن تستهدف المطور مباشرة، كما في حالة حزم PyPI الخبيثة المرتبطة بـSilentSync RAT. ومع توسع أدوات الذكاء الاصطناعي ظهرت مساحة هجوم إضافية حول المكونات التي يثبتها المطور، ومنها ما ناقشناه في واقعة خادم Postmark-MCP الخبيث.
هل GlassWorm ثغرة أمنية أم برمجية خبيثة؟
من المهم عدم الخلط بين المفهومين. GlassWorm ليس اسم CVE ولا يشير في حد ذاته إلى ثغرة واحدة في VS Code أو Open VSX. الحملة اعتمدت أساسًا على برمجيات خبيثة وبيانات اعتماد مسروقة وإساءة استخدام الثقة في منظومة النشر.
قد تستخدم هجمات Supply Chain ثغرة برمجية في بعض الحالات، لكنها لا تحتاج بالضرورة إلى Zero-Day. إذا حصل المهاجم على Token صالح لحساب ناشر أو تمكن من إدخال شيفرة ضارة داخل تحديث موثوق، فقد يكون لديه كل ما يحتاجه دون استغلال ثغرة غير مرقعة.
لهذا لا يكفي سؤال فريق الأمن: «هل توجد CVE؟». يجب أيضًا مراقبة سلامة حسابات الناشرين، وتغييرات Workflows، وسلوك الحزم أثناء التثبيت، ومصدر الإصدار، ومن يملك حق نشره.
لماذا أُطلق عليها اسم GlassWorm إذا كان وصف «الدودة» محل نقاش؟
وصف الكشف الأول من Koi الحملة بأنها دودة ذاتية الانتشار. لكن التسمية أصبحت لاحقًا اسمًا للحملة نفسها، بينما أشارت بيانات Socket عن حملات GlassWorm اللاحقة إلى أنها لم ترصد في النشاط الذي تتبعته سلوكًا ذاتي الانتشار بالمعنى التقني الحرفي.
لذلك من الأدق عدم افتراض أن كل عينة تحمل اسم GlassWorm تنسخ نفسها تلقائيًا من جهاز إلى آخر. ما يهم دفاعيًا هو قدرة الحملة على استخدام حسابات وأصول تطوير مخترقة للوصول إلى ضحايا جدد عبر سلسلة التوريد.
كيف تطورت حملة GlassWorm بين 2025 و2026؟
أكتوبر 2025: الكشف الأول
بدأ الاهتمام الواسع بالحملة بعد كشف إضافات ضارة مرتبطة بـOpen VSX. ومن التقنيات اللافتة استخدام محارف Unicode غير مرئية لإخفاء شيفرة داخل الملفات، إلى جانب بنية قيادة وتحكم مصممة لتكون أقل اعتمادًا على خادم ثابت واحد.
نوفمبر 2025: عودة سريعة بعد إجراءات الإزالة
بعد إجراءات اتخذت لإزالة الإضافات المعروفة، رصد باحثو Koi موجة أخرى من الإضافات المرتبطة بالحملة. أظهر ذلك مشكلة مألوفة في Supply Chain: إزالة Artifact معروف لا تعني بالضرورة إزالة الحسابات المخترقة أو الأجهزة المصابة أو بيانات الاعتماد التي سبق سرقتها.
2026: الاستفادة من ناشرين وأصول موثوقة
أظهرت أبحاث لاحقة حالات نُشرت فيها إصدارات ضارة من إضافات لها وجود سابق ومستخدمون فعليون، وهو سيناريو أخطر من إنشاء إضافة جديدة مجهولة؛ لأن المستخدم قد يتلقى التحديث من اسم سبق أن وثق به.
كما توسعت الأبحاث حول الحملة لتشمل أساليب توزيع غير مباشرة وعلاقات بين Extensions، بما يوضح أن مراجعة اسم الحزمة وحده ليست وسيلة كافية للحكم على سلامتها.
26 مايو 2026: عملية لتعطيل البنية التحتية
أعلنت CrowdStrike تنفيذ عملية منسقة مع Google وShadowserver استهدفت قنوات القيادة والتحكم المستخدمة في البوتنت بهدف فصل المشغلين عن الأجهزة المصابة.
هذه نقطة مهمة عند تقييم الوضع الحالي في أغسطس 2026: هناك دليل موثوق على تعطيل البنية التحتية المعروفة في مايو، لكن ذلك لا يعني أن كل جهاز أصيب سابقًا أصبح نظيفًا تلقائيًا، ولا أن أساليب الهجوم نفسها لم تعد قابلة لإعادة الاستخدام في حملات أخرى.
ولهذا لا ينبغي التعامل مع GlassWorm كخبر انتهى بمجرد إسقاط خوادم أو قنوات C2؛ القيمة المستمرة للحادثة هي ما كشفته عن هشاشة الحلقة التي تربط جهاز المطور بحسابات النشر والبناء والمستخدم النهائي.
ماذا تغير في حماية npm وGitHub بعد موجة هجمات Supply Chain؟
لم تكن GlassWorm الحملة الوحيدة التي دفعت منظومات التطوير إلى إعادة تقييم نموذج الثقة. شهدت 2025 و2026 هجمات أخرى استهدفت حسابات Maintainers وTokens وLifecycle Scripts وخطوط CI/CD، وهو ما أدى إلى تغييرات عملية في طريقة نشر واستهلاك الحزم.
من أبرز الاتجاهات الحالية استخدام Trusted Publishing بالاعتماد على OIDC بدل تخزين رموز نشر طويلة العمر داخل CI، وإضافة مراحل موافقة أقوى لبعض عمليات النشر، وتقليل التنفيذ التلقائي للشيفرة القادمة من Dependencies.
وفي npm 12 أصبح تشغيل Lifecycle Scripts الخاصة بالاعتمادات أكثر تقييدًا افتراضيًا، بينما أضاف GitHub إجراءات أخرى للحد من تبني الإصدارات الجديدة المشبوهة فور صدورها وتحسين فحص الحزم. ويمكن مراجعة تفاصيل هذه التحولات في تحليل CyberOPlus حول كيف غيّرت GitHub وnpm أمان نشر الحزم بعد هجمات Supply Chain.
وتشرح GitHub في تحديثها الأمني لعام 2026 أن حملات Supply Chain الحديثة تجمع غالبًا بين سرقة بيانات الاعتماد ونقاط ضعف في عمليات النشر وCI/CD، لذلك أصبح تقليل الأسرار طويلة العمر ومنع التنفيذ غير الضروري للشيفرة جزءًا أساسيًا من الدفاع.
كيف تقلل خطر استهداف بيئة المطور؟
1. تعامل مع جهاز المطور كأصل أمني عالي القيمة
محطة التطوير التي تستطيع الوصول إلى الشيفرة أو الإنتاج لا ينبغي أن تُدار كجهاز مكتبي عادي. يجب تحديث النظام والأدوات، واستخدام حماية Endpoint مناسبة، وتقليل البرامج والإضافات غير الضرورية، ومراقبة التنفيذ غير المعتاد من المحررات ومديري الحزم.
2. قلل الأسرار الموجودة على الجهاز
كل Token طويل العمر محفوظ محليًا يمثل فرصة للمهاجم. استخدم بيانات اعتماد قصيرة العمر كلما أمكن، وافصل بين حسابات التطوير والإنتاج، وطبّق Least Privilege بحيث لا يحصل المطور أو CI job إلا على الصلاحيات التي يحتاج إليها.
وعندما يدعم Registry النشر الموثوق بواسطة OIDC، فإن ذلك أفضل من تخزين Publishing Token ثابت داخل Secrets يمكن سرقته وإعادة استخدامه خارج Workflow المصرح به.
3. استخدم مصادقة مقاومة للتصيد
حسابات GitHub والبريد والخدمات السحابية وسجلات الحزم تحتاج إلى MFA قوي، ويفضل استخدام Passkeys أو مفاتيح أمان عندما تكون الخدمة داعمة لها. المصادقة متعددة العوامل لا تمنع كل أنواع سرقة الجلسات، لكنها تقلل الاعتماد على كلمة مرور قابلة لإعادة الاستخدام.
4. لا تثق في Dependency فقط لأنها موجودة في Registry معروف
وجود الحزمة في npm أو PyPI أو إضافة في Marketplace لا يمثل ضمانًا أمنيًا. افحص اسم الناشر، وتاريخ المشروع، والمستودع المصدر، والتغييرات في الإصدارات الجديدة، والصلاحيات أو Scripts التي ستعمل أثناء التثبيت.
في المشاريع الحساسة يمكن أن تكون سياسات Allowlist أو مستودعات داخلية معتمدة مفيدة لتقليل اعتماد المطورين مباشرة على أي مكون يظهر في Registry عام. ويتوافق هذا مع مبادئ Secure Software Development Framework من NIST التي تدعو إلى دمج ممارسات أمان البرمجيات داخل دورة التطوير بدل التعامل معها كفحص نهائي فقط.
5. راقب ما يحدث داخل CI/CD
قد يكون Workflow المخترق أخطر من جهاز مطور واحد، لأنه يمتلك غالبًا أسرارًا وصلاحيات آلية ويعمل دون مراقبة بشرية مستمرة.
- احمِ الفروع الحساسة واطلب مراجعة التغييرات المهمة.
- قيد من يستطيع تعديل Workflows وملفات النشر.
- استخدم Environments وموافقات منفصلة للنشر الحساس.
- قلل صلاحيات Tokens الممنوحة تلقائيًا للوظائف.
- ثبّت إصدارات Actions والاعتمادات الحساسة بطريقة تقلل خطر استبدالها دون مراجعة.
- راقب أي تغيير غير معتاد في Secrets أو إعدادات النشر أو حسابات Maintainers.
6. افصل بين بناء البرنامج ونشره
كلما استطاع حساب واحد تعديل الشيفرة وبناء الإصدار ونشره دون حاجز إضافي، زاد أثر اختراق ذلك الحساب. الفصل بين المراحل، مع مراجعات وموافقات مستقلة عند النقاط الحساسة، يقلل قدرة بيانات اعتماد واحدة مسروقة على تحويل اختراق محلي إلى حادثة Supply Chain واسعة.
7. استفد من Provenance والتوقيعات عندما تكون متاحة
الهدف من Software Provenance هو توفير دليل يمكن التحقق منه حول مصدر Artifact وكيفية بنائه. لا تجعل Provenance الحزمة آمنة تلقائيًا، لكنها تساعد على اكتشاف إصدارات لا تتوافق مع مسار البناء المتوقع وتقلل الغموض حول أصل الملف المنشور.
ما العلامات التي تستحق التحقيق داخل بيئة تطوير؟
لا توجد علامة واحدة تثبت وجود Supply Chain Attack، لكن اجتماع سلوكيات غير معتادة يستحق التحقيق، خصوصًا على الأجهزة التي تملك صلاحيات نشر:
- عملية تابعة لمحرر الأكواد أو Package Manager تشغّل Shell أو PowerShell أو أدوات نظام بصورة غير متوقعة.
- اتصالات شبكية من Extension أو Dependency لا تحتاج عادة إلى الإنترنت.
- ظهور Tokens أو مفاتيح جديدة أو تغييرات في بيانات اعتماد حسابات النشر.
- تسجيل دخول إلى GitHub أو Registry أو Cloud من جهاز أو منطقة غير معتادة.
- تعديل Workflow أو Release Pipeline دون سبب واضح.
- نشر إصدار Package لم ينفذه Maintainer المعروف.
- إضافة Dependency جديدة أو تغيير Package lock خارج عملية التطوير المتوقعة.
- تغييرات غير مفسرة في Extensions المثبتة أو تحديثها من ناشر غير متوقع.
يجب تفسير كل مؤشر في سياقه. اتصال الشبكة من إضافة VS Code مثلًا ليس خبيثًا بحد ذاته، لأن الكثير من الإضافات تحتاج خدمات خارجية. القيمة تأتي من مقارنة السلوك بما هو متوقع للمشروع والمستخدم والجهاز.
ماذا تفعل إذا اشتبهت في إصابة جهاز مطور؟
إذا كان الاشتباه جديًا، فالأولوية ليست حذف الإضافة ثم متابعة العمل كالمعتاد. قد تكون بيانات الاعتماد قد غادرت الجهاز بالفعل.
- اعزل الجهاز أو Runner المتأثر عن الأنظمة الحساسة لمنع استمرار الوصول.
- حافظ على الأدلة اللازمة للتحقيق قبل إعادة التهيئة إذا كانت المؤسسة تملك فريق Incident Response.
- ألغِ Tokens والجلسات والمفاتيح المعرضة للخطر من جهة الخدمة نفسها، وليس فقط بحذفها من الجهاز.
- راجع GitHub وRegistries وCloud وCI/CD بحثًا عن عمليات دخول أو تغييرات أو Releases حدثت بعد وقت الإصابة المحتمل.
- افحص الإصدارات المنشورة للتأكد من عدم دفع Artifact معدل إلى المستخدمين.
- أعد بناء الجهاز من مصدر موثوق عندما لا يكون من الممكن ضمان إزالة البرمجية الخبيثة وآليات الاستمرارية.
- أنشئ بيانات اعتماد جديدة بعد الاحتواء ولا تعد استخدام أسرار يحتمل أنها ظهرت على الجهاز المصاب.
- قيّم الأثر على المستخدمين downstream إذا كان الحساب المخترق يستطيع نشر حزم أو تحديثات أو صور Containers.
إذا ثبت نشر إصدار خبيث، تتحول الحادثة من اختراق Endpoint إلى حادثة Supply Chain كاملة، ويجب عندها تحديد الإصدارات المتأثرة وإبطالها وإبلاغ الجهات التي قد تكون ثبتتها وفق خطة الاستجابة الخاصة بالمؤسسة.
الدرس الأهم من GlassWorm
أظهرت GlassWorm أن حماية المستودع وحدها لا تكفي إذا كانت محطة المطور أو حساب الناشر أو Pipeline نفسها قابلة للاختراق. فالمهاجم لا يحتاج دائمًا إلى كسر خوارزمية تشفير أو العثور على Zero-Day؛ أحيانًا يكفي أن يجعل مطورًا أو نظام بناء موثوقًا ينفذ الشيفرة بالنيابة عنه.
ولهذا يجب التعامل مع Software Supply Chain كسلسلة كاملة: جهاز المطور، والهوية، والمستودع، والاعتمادات، وCI/CD، وحساب النشر، والـArtifact النهائي. قوة السلسلة لا تحددها أفضل طبقة حماية فيها، بل أضعف نقطة تستطيع منح المهاجم طريقًا إلى الطبقات التالية.
وبالنسبة إلى GlassWorm تحديدًا، فإن عملية التعطيل التي أُعلن عنها في مايو 2026 مهمة، لكنها لا تلغي الدرس الدفاعي الذي تركته الحملة: الثقة في أداة أو ناشر أو Marketplace لا يجب أن تتحول إلى ثقة مطلقة في كل شيفرة تصل من خلاله.