كشف باحثون أمنيون عن حملة سلسلة توريد برمجية متطورة نُسبت إلى حساب GitHub يُدعى "BufferZoneCorp"، استخدمت تقنية الحزم النائمة (Sleeper Packages) لنشر حمولات خبيثة عبر مستودعات RubyGems وGo Modules، مستهدفةً بيئات البناء الآلي CI/CD لسرقة مفاتيح SSH وبيانات اعتماد AWS وGitHub وnpm من خوادم التطوير والنشر.

تشريح هجوم BufferZoneCorp: الحزم النائمة كسلاح سيبراني

اعتمد المهاجمون على نهج مرحلي مدروس يتجاوز معظم آليات الحماية المعروفة. في المرحلة الأولى، نُشرت حزم نظيفة تماماً تحمل أسماء مشابهة لمكتبات معروفة مثل activesupport-logger وdevise-jwt وgo-retryablehttp وgrpc-client وconfig-loader. هذا الأسلوب المعروف بـ Typosquatting يستغل أخطاء الإدخال الشائعة لدى المطورين أو يخدعهم بأسماء تبدو موثوقة. في المرحلة الثانية، وبعد اكتساب الحزم قدراً من الثقة والتنزيلات، حُدّثت بنسخ تحتوي على كود خبيث مصمم لاستخراج البيانات الحساسة من بيئات البناء.

ما يجعل هذا الهجوم خطيراً بشكل استثنائي هو أن المؤسسات التي تُثبّت التبعيات بنسخة محددة (Version Pinning) عند الإعداد الأولي قد لا تكون محمية إذا وصل التحديث الخبيث قبل تثبيت القفل. كذلك فإن أدوات المسح الآلي التي تفحص التبعيات عند إضافتها فقط — وليس عند تحديثها — قد تفوّت النسخ المسمومة تماماً.

آليات سرقة بيانات الاعتماد: من extconf.rb إلى الاستخراج الصامت

استغلت حزم Ruby الخبيثة ملف extconf.rb — وهو خطّاف تمديد أصلي في نظام RubyGems يُنفَّذ تلقائياً أثناء تثبيت الحزمة — لحصد متغيرات البيئة السرية وملفات بيانات الاعتماد المحلية. بمجرد تنفيذ أمر gem install أو bundle install، يبدأ الكود الخبيث بمسح بيئة البناء بحثاً عن مفاتيح SSH الخاصة، وبيانات اعتماد AWS المخزنة في ~/.aws/credentials، وتوكنات GitHub CLI، وملفات تكوين npm في ~/.npmrc، وبيانات اعتماد RubyGems نفسها.

تُرسل جميع البيانات المسروقة عبر طلبات HTTPS POST إلى نقاط نهاية يتحكم فيها المهاجمون، وكل ذلك يحدث قبل أن يبدأ المطور فعلياً في استخدام الحزمة. أما وحدات Go الخبيثة فاتبعت نهجاً مماثلاً مع التلاعب بإجراءات GitHub Actions وزرع آليات استمرارية عبر SSH لضمان وصول دائم إلى البنية التحتية المخترقة.

نطاق الضرر والاستجابة: أكثر من 500 حزمة خبيثة

بلغ إجمالي الحزم الخبيثة التي نُشرت خلال هذه الحملة أكثر من 500 حزمة على مستودع RubyGems وحده، مما دفع إدارة المستودع إلى اتخاذ خطوة غير مسبوقة بتعليق التسجيلات الجديدة مؤقتاً في 12 مايو 2026. تم حظر حسابات البوت المسؤولة وإزالة جميع الحزم المسمومة. كما حُظرت وحدات Go الخبيثة من مستودعاتها. لكن السؤال الحقيقي يبقى: كم مؤسسة ثبّتت هذه الحزم خلال نافذة التعرض التي امتدت لأيام قبل اكتشاف الحملة؟

التأثير على المؤسسات المالية السعودية وأنابيب DevOps

تعتمد المؤسسات المالية السعودية بشكل متزايد على أنابيب CI/CD لنشر تطبيقاتها المصرفية الرقمية وأنظمة المدفوعات وواجهات API المفتوحة. هذا الاعتماد يجعلها هدفاً مباشراً لهجمات سلسلة التوريد من هذا النوع. وفقاً لإطار SAMA CSCC، تلتزم المؤسسات المالية بتطبيق ضوابط صارمة على إدارة سلسلة التوريد التقنية (Third-Party Security Management)، بما يشمل فحص التبعيات البرمجية والتحقق من سلامة مكونات البناء.

كذلك يُلزم إطار NCA ECC المؤسسات بتطبيق ضوابط أمن التطبيقات التي تشمل مراجعة الكود ومكوناته قبل النشر في بيئات الإنتاج. أما نظام حماية البيانات الشخصية PDPL فيفرض مسؤولية مباشرة على المؤسسة عن أي تسريب بيانات ناتج عن مكونات طرف ثالث غير مفحوصة، حيث إن سرقة بيانات اعتماد AWS أو مفاتيح SSH من بيئة بناء قد تفتح الباب لاختراق قواعد بيانات العملاء وأنظمة المعاملات المالية.

التوصيات والخطوات العملية لتأمين أنابيب CI/CD

  1. تطبيق فحص التبعيات المستمر: استخدم أدوات مثل Snyk أو Socket.dev أو Dependabot لفحص كل تحديث للتبعيات — وليس فقط عند الإضافة الأولية — مع تفعيل التنبيهات الفورية عند اكتشاف سلوك مشبوه في الحزم.
  2. عزل بيئات البناء: شغّل عمليات البناء في حاويات معزولة (Ephemeral Containers) تُدمَّر بعد كل عملية بناء، ولا تخزّن بيانات اعتماد دائمة في بيئة البناء. استخدم أنظمة إدارة الأسرار مثل HashiCorp Vault أو AWS Secrets Manager مع توكنات مؤقتة.
  3. تثبيت التبعيات بملفات القفل والتحقق من التجزئة: استخدم Gemfile.lock وgo.sum مع التحقق من hash كل حزمة. فعّل --frozen في بيئات CI لمنع أي تحديث غير مُراجع.
  4. مراقبة حركة الشبكة الصادرة من بيئات البناء: طبّق قواعد جدار حماية صارمة على خوادم CI/CD تمنع الاتصالات الصادرة إلا للمستودعات المعتمدة. أي طلب HTTPS POST غير متوقع من بيئة بناء يجب أن يُطلق تنبيهاً فورياً.
  5. استخدام مستودعات خاصة (Private Registry Mirrors): أنشئ مرآة داخلية لمستودعات الحزم مثل Artifactory أو Nexus، وافحص كل حزمة جديدة قبل إتاحتها للمطورين.
  6. تدوير بيانات الاعتماد بشكل دوري: غيّر مفاتيح SSH وتوكنات API بشكل دوري، وافترض أن أي بيانات اعتماد موجودة في بيئة بناء قد تكون مكشوفة إذا لم تكن محمية بنظام إدارة أسرار مركزي.

الخلاصة

يكشف هجوم BufferZoneCorp عن تطور نوعي في هجمات سلسلة التوريد البرمجية، حيث لم يعد الخطر محصوراً في الكود النهائي بل امتد إلى البنية التحتية للتطوير نفسها. أنابيب CI/CD التي تبني وتنشر أنظمتك المالية قد تكون هي نقطة الاختراق الأولى. المؤسسات التي تعامل أمن أنابيب التطوير كأولوية ثانوية تُعرّض نفسها لمخاطر تتجاوز السرقة التقنية إلى انتهاك مباشر لمتطلبات SAMA CSCC وNCA ECC.

هل أنابيب التطوير في مؤسستك محمية؟ تواصل مع فريق فنترالينك لتقييم أمن سلسلة التوريد البرمجية وأنابيب CI/CD وفق متطلبات SAMA CSCC وأفضل ممارسات DevSecOps.