اختراق GitHub عبر إضافة VS Code مسمومة: دروس أمان سلسلة توريد المطورين

ما حدث: هجوم نموذجي على بنية تحتية للتطوير

في 20 مايو 2026، كشف GitHub أن قراصنة اخترقوا الشركة عبر جهاز موظف مخترق. كان متجه الهجوم إضافة Visual Studio Code مسمومة — أداة مصممة لتحسين إنتاجية المطورين في بيئة التطوير المتكاملة التي يستخدمها ملايين المهندسين يومياً. وفقاً لتقرير TechCrunch عن الحادث، تأثر نحو 3,800 مستودع كود داخلي، إذ ادّعى المهاجمون — الذين عرّفوا أنفسهم بـ TeamPCP — بيع البيانات المُسرَّبة في منتدى للجرائم الإلكترونية.

TeamPCP ليست جهة جديدة. المجموعة نفّذت سابقاً سرقة بيانات المفوضية الأوروبية (أكثر من 90 غيغابايت)، وكانت وراء الحملة التي اخترقت ماسح الثغرات Trivy في مارس 2026. وهي مجموعة متواصلة وجيدة الموارد لديها نمط موثق يتمثل في استهداف سلسلة أدوات تطوير البرمجيات ذاتها بدلاً من أنظمة الإنتاج أو حسابات المستخدمين النهائيين. هذا الهجوم يقع ضمن نمط أوسع: في أبريل 2026، وثّقت The Register حملة سلسلة التوريد لـ TeamPCP التي استهدفت أدوات الأمان، والتي اخترقت Trivy وKICS وLiteLLM وTelnyx وBitwarden CLI وGitHub Actions الخاصة بـ Checkmarx، وأثرت على أكثر من 10 ملايين مستخدم لـ Bitwarden وأكثر من 50,000 شركة. اختراق GitHub هو نفس المجموعة تطبّق نفس الأسلوب على هدف أعلى قيمة.

لماذا أصبحت أدوات المطورين سطح الهجوم الرئيسي

يفترض نموذج الأمان في معظم الشركات أن سطح الهجوم الرئيسي هو بيئة الإنتاج — الخوادم وقواعد البيانات وواجهات API. تُعامَل أدوات المطورين تاريخياً كبنية تحتية موثوقة.

هذا الافتراض بات غير صالح تشغيلياً. يضم سوق إضافات VS Code أكثر من 50,000 إضافة؛ ينشر npm أكثر من 30,000 حزمة يومياً، كما أشار دليل أمان سلسلة التوريد الخاص بـ GitHub. سطح الهجوم المتاح عبر أدوات المطورين أكبر بمراتب من أسطح هجوم الإنتاج، والضوابط المطبقة على هذا السطح أضعف بمراتب.

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

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

1. مراجعة وإغلاق مخزون إضافات VS Code

أظهر اختراق GitHub أن إضافة واحدة مخترقة يمكن أن تمنح المهاجمين وصولاً إلى آلاف المستودعات الداخلية. يجب على الفرق الهندسية إجراء جرد فوري لجميع إضافات VS Code المُثبَّتة على أجهزة المطورين — ليس ما هو موصى به رسمياً فحسب، بل ما هو مُثبَّت فعلاً. مقارنة تلك القائمة بقائمة بيضاء للإضافات المعتمدة. بالنسبة لأي إضافة خارج القائمة البيضاء، تحقق من هوية الناشر وراجع طلبات الأذونات وتحقق من تثبيت الإضافة على إصدار محدد بدلاً من التحديث التلقائي. للمضي قدماً، طبّق سياسة إضافات معتمدة عبر ملف توصيات إضافات VS Code (.vscode/extensions.json) واستخدم منصة MDM أو إدارة نقطة النهاية لمنع تثبيت الإضافات غير المعتمدة على الأجهزة المُدارة من قِبَل الشركة. هذا ليس ضبطاً مثالياً — سيقاوم المطورون على أجهزتهم الشخصية — لكنه يضيّق سطح الهجوم بشكل ملحوظ في البيئات الأكثر حساسية.

2. تثبيت والتحقق من كل إجراء وتبعية طرف ثالث

يوصي دليل أمان سلسلة التوريد من GitHub صراحةً بتثبيت GitHub Actions من أطراف ثالثة على SHA كاملة للـ commit بدلاً من علامات الإصدار. العلامات قابلة للتحريك؛ SHA للـ commit ليست كذلك. تنطبق نفس المنطق على حزم npm ومكتبات Python وصور Docker الأساسية وأي كود طرف ثالث يدخل خط أنابيب البناء. تطبيق Dependabot أو أداة تحديث تبعيات مماثلة تفرض الإصدارات المثبتة.

3. معاملة بيانات اعتماد المطورين كبيانات اعتماد الإنتاج

نجح هجوم GitHub لأن جهاز المطور المخترق كان يملك صلاحية الوصول إلى المستودعات الداخلية. في معظم المنظمات الهندسية، تتلقى مفاتيح SSH ورموز API وبيانات الاعتماد السحابية للمطورين رقابة أقل من حسابات خدمة الإنتاج — رغم أن بيانات اعتماد المطورين عادةً ما تتمتع بوصول أوسع للكود المصدري وبنية بناء البرمجيات. طبّق نفس الحوكمة على بيانات اعتماد المطورين التي تطبقها على بيانات اعتماد الإنتاج: اعمل على تدويرها بشكل دوري، وقيّدها بأقل الصلاحيات اللازمة، وراجع استخدامها، وأبطلها فوراً عندما يغير المطور دوره أو يغادر المنظمة. طبّق مفاتيح الأمان المادية أو مصادقة FIDO2 لصلاحية الوصول إلى المستودعات — اختراق GitHub تجاوز المصادقة الثنائية عبر اختراق الجهاز، لكن بيانات الاعتماد المرتبطة بالأجهزة تجعل هذا الالتفاف أصعب بكثير. خزّن الأسرار في مدير أسرار (HashiCorp Vault أو AWS Secrets Manager) بدلاً من المتغيرات البيئية أو الملفات المخفية على أجهزة المطورين.

4. تفعيل ومراجعة قاعدة بيانات تنبيهات GitHub وأدوات المسح الأمني

CodeQL مجاني للمستودعات العامة ويمكنه مراجعة تطبيقات سير عمل GitHub Actions بحثاً عن أنماط هجمات سلسلة التوريد الشائعة — بما فيها الصلاحيات الموسّعة على مُشغِّلات pull_request_target وحقن السكريبتات من المحتوى الذي يرسله المستخدمون. تُنبّه تنبيهات Dependabot للتبعيات ذات الثغرات المعروفة. يكشف المسح السري عن بيانات الاعتماد المُلزَمة عن طريق الخطأ. هذه الأدوات لا تمنع صنف الهجوم الذي ضرب GitHub مباشرةً — جهاز داخلي مخترق — لكنها تُغلق فئة واسعة من متجهات سلسلة التوريد التي يستخدمها المهاجمون حين الاختراق المباشر غير متاح. يجب على الفرق الهندسية مراجعة إعدادات الأمان الحالية في GitHub والتأكد من تفعيل الأدوات الثلاثة ومراجعة تنبيهاتها بشكل دوري.

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

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

• GitHub يؤكد سرقة هاكرز لبيانات من آلاف المستودعات الداخلية — TechCrunch
• حملة سلسلة التوريد تستهدف أدوات الأمان — The Register
• تأمين سلسلة توريد المصدر المفتوح عبر GitHub — مدونة GitHub
• هاكرز يخترقون عشرات الحزم الشهيرة في المصدر المفتوح — TechCrunch