المصدر المفتوح
في السابق، كان القلق بشأن الثغرات الأمنية للمصادر المفتوحة وهجمات سلاسل التوريد حكرًا على شركات البرمجيات المتخصصة وعمالقة التكنولوجيا. لكن الأزمان تغيرت. فاليوم، حتى الشركات الصغيرة باتت تمتلك وحدات تطوير برمجية خاصة بها، ما جعل هذه المشكلة تهم الجميع. وأصبحت فرق تكنولوجيا المعلومات في نصف الشركات تقريبًا مشغولة بكتابة التعليمات البرمجية، وضبط التكامل بين الأنظمة، وأتمتة سير العمل — حتى وإن كان نشاطها الأساسي بعيدًا كل البعد عن البرمجيات. هذا ما تفرضه متطلبات كفاءة الأعمال الحديثة. لكن ضريبة ذلك كانت ظهور جيل جديد من الثغرات الأمنية البرمجية – تلك التي يتجاوز إصلاحها مجرد تثبيت آخر تحديثات Windows.
لا يمكن فصل عملية تطوير البرمجيات الحديثة عن المكونات مفتوحة المصدر. ومع ذلك، فقد تزايدت المخاطر المرتبطة بها بشكل هائل في السنوات الأخيرة، وتنوعت أشكالها وازدادت تعقيدًا. ونحن نشهد الآن حقن تعليمات برمجية ضارة في مستودعات البرامج الشهيرة، وتشتتًا ونقصًا في بيانات الثغرات الأمنية، واستخدامًا منهجيًا لمكونات قديمة ومعرضة للاختراق، فضلاً عن تعقد سلاسل التبعيات بشكل متزايد.
نقص بيانات الثغرات الأمنية للمصادر المفتوحة
حتى لو كانت مؤسستك تمتلك عملية إدارة ثغرات أمنية شديدة الإحكام للبرمجيات التجارية الخارجية، ستجد أن التعليمات البرمجية مفتوحة المصدر تتطلب إعادة صياغة شاملة لتلك العملية. وغالبًا ما تكون قواعد البيانات العامة الأكثر استخدامًا غير مكتملة، أو غير دقيقة، أو ببساطة بطيئة جدًا في توفير التحديثات المتعلقة بالمصادر المفتوحة. وهذا يحوّل تحديد أولويات الثغرات إلى مجرد لعبة تخمين. ولا يمكن لأي قدر من الأتمتة أن يسعفك إذا كانت بياناتك الأساسية مليئة بالثغرات.
وفقًا لبيانات صادرة عن شركة Sonatype، فإن حوالي 65% من ثغرات المصادر المفتوحة التي تم منحها معرفًا رسميًا يطلق عليه CVE ID تفتقر إلى تقييم لدرجة الخطورة (CVSS) في قاعدة بيانات الثغرات الأمنية الوطنية (NVD) — وهي قاعدة المعرفة الأكثر انتشارًا عالميًا. ومن بين تلك الثغرات الأمنية غير المصنفة، تبيّن أن قرابة 46% منها كان سيُصنف كخطر عالٍ لو تم تحليلها بشكل سليم.
حتى في حال توفر تقييم لدرجة الخطورة (CVSS)، فإن المصادر المختلفة لا تتفق على درجة الخطورة إلا بنسبة 55% فقط. قد تُصنف إحدى قواعد البيانات ثغرة ما على أنها حرجة، بينما تمنحها قاعدة أخرى درجة متوسطة. وغالبًا ما تكون البيانات الوصفية الأكثر تفصيلاً، مثل إصدارات الحزم المتضررة، مليئة بالأخطاء والتناقضات. ونتيجة لذلك، تنتهي أدوات فحص الثغرات التي تعتمد على مقارنة إصدارات البرمجيات بإطلاق إنذارات كاذبة، أو منحك شهادة سلامة وهمية ومضللة.
يتزايد العجز في بيانات الثغرات الأمنية، بينما تتباطأ عملية الإبلاغ عنها بشكل ملحوظ. وعلى مدى السنوات الخمس الماضية، تضاعف العدد الإجمالي للثغرات الأمنية المسجلة (CVEs)، لكن عدد الثغرات التي تفتقر إلى تقييم لدرجة الخطورة تضاعف بشكل هائل بمقدار 37 مرة. ووفقاً لشركة Tenable، فإنه بحلول عام 2025، كان رمز استغلال الثغرة الأمنية (PoC) متاحًا للعلن في غضون أسبوع واحد من اكتشافها، بينما استغرق إدراج هذه الثغرة نفسها في قاعدة بيانات (NVD) ما متوسطه 15 يومًا. أما عمليات إثراء البيانات، مثل تعيين درجة تقييم الخطورة (CVSS)، فهي أبطأ من ذلك؛ إذ تقدر Sonatype في الدراسة ذاتها أن متوسط الوقت اللازم لتعيين الدرجة هو 41 يومًا، مع بقاء بعض العيوب البرمجية دون تقييم لمدة تصل إلى عام كامل.
مشكلة التعليمات البرمجية القديمة مفتوحة المصدر
وفقًا لبيانات HeroDevs، فإن ما يتراوح بين 5 إلى 15% من مشاريع الشركات تحتوي على مكتبات وتطبيقات وخدمات لم تعد تخضع للصيانة، إما لكونها مهجورة أو لوصولها رسميًا إلى نهاية عمرها الافتراضي (EOL). ويوجد عبر خمسة من أشهر مستودعات التعليمات البرمجية مفتوحة المصدر ما لا يقل عن 81000 حزمة برمجية تحتوي على ثغرات أمنية معروفة، لكنها تنتمي لإصدارات قديمة وغير مدعومة. ولن تصدر لهذه الحزم أي إصلاحات أمنية رسمية أبدًا. ويشكل هذا “الإرث الثقيل” نحو 10% من الحزم في Maven Central وPyPI، وتصل هذه النسبة إلى 25% في مستودع npm.
يؤدي استخدام هذا النوع من التعليمات البرمجية مفتوحة المصدر إلى كسر دورة حياة إدارة التصحيح القياسية: لا يمكنك تحديث تبعية برمجية لم تعد مدعومة تلقائيًا أو يدويًا. علاوة على ذلك، عند حذف الإصدارات التي وصلت لنهاية عمرها الافتراضي من نشرات الثغرات الأمنية الرسمية، فقد تصنفها أدوات فحص الأمان على أنها “غير متأثرة” بالعيب وتتجاهلها.
تعد Log4Shell خير مثال على ذلك، وهي الثغرة الحرجة التي حصلت على أقصى درجة خطورة (CVSS 10) في مكتبة Log4j الشهيرة التي اكتُشفت في عام 2021. وقد استحوذ الإصدار المصاب بالثغرة الأمنية على 40 مليون عملية تنزيل من أصل 300 مليون لمكتبة Log4j في عام 2025 وحده. وضع في الاعتبار أننا نتحدث هنا عن واحدة من أكثر الثغرات الأمنية سوءًا للسمعة وأوسعها انتشارًا في التاريخ – تلك التي تم استغلالها بنشاط، وأصدر المطور إصلاحًا لها، وتمت معالجتها في جميع المنتجات التابعة له. ولذلك، فإن الوضع في حالة العيوب البرمجية الأقل شهرة أسوأ بكثير.
يزيد وجود فجوة في الرؤية من تفاقم هذه المشكلة. وتفتقر العديد من المؤسسات إلى الأدوات اللازمة لرسم خريطة كاملة لشجرة التبعيات، أو الحصول على رؤية كاملة للحزم والإصدارات المحددة المدمجة داخل بنيتها البرمجية. ونتيجة لذلك، تظل هذه المكونات القديمة غير مرئية في الغالب، ولا تجد طريقًا لها أبدًا إلى قائمة المهام المخصصة للإصلاح والمعالجة.
البرامج الضارة في السجلات مفتوحة المصدر
أصبحت الهجمات التي تتضمن حزمًا مفتوحة المصدر، سواء كانت مصابة أو ضارة بطبيعتها، واحدة من أسرع التهديدات نموًا في سلاسل توريد البرمجيات. ووفقًا لباحثي Kaspersky، تم اكتشاف ما يقرب من 14000 حزمة ضارة في السجلات الشهيرة بحلول نهاية عام 2024، بزيادة قدرها 48% على أساس سنوي. وقد سجلت Sonatype قفزة أكثر هولاً طوال عام 2025، حيث رصدت أكثر من 450000 حزمة ضارة.
تتنوع الدوافع وراء هذه الهجمات بشكل كبير، وتشمل: سرقة العملات المشفرة، وحصد بيانات اعتماد المطورين، والتجسس الصناعي، والوصول إلى البنى التحتية عبر مسارات التكامل والتسليم المستمر (CI/CD)، أو اختراق الخوادم العامة لاستضافة حملات البريد العشوائي والتصيد الاحتيالي. وتُستخدم هذه التكتيكات من قِبل مجموعات التهديد المتقدم المستمر (APT) لأغراض التجسس، وكذلك من قِبل المجرمين السيبرانيين ذوي الدوافع المالية. وبات اختراق الحزم مفتوحة المصدر يمثل، بشكل متزايد، الخطوة الأولى فحسب في عملية اختراق مؤسسي متعددة المراحل.
تتضمن سيناريوهات الهجوم الشائعة سرقة بيانات اعتماد المطورين المسؤولين عن صيانة الحزم مفتوحة المصدر الأصلية أو نشر مكتبة “مفيدة” تحتوي على تعليمات برمجية ضارة أو نشر مكتبة ضارة تحمل اسمًا مشابهًا جدًا لاسم شائع. وكان الاتجاه المثير للقلق للغاية في عام 2025 هو ظهور الهجمات آلية شبيهة بالفيروسات المتنقلة. وتعتبر حملة Shai-Hulud أبرز مثال على ذلك. وفي هذه الحالة، سرقت التعليمات البرمجية الضارة رموز الوصول الخاصة بمنصتي GitHub وnpm واستمرت في إصابة الحزم الجديدة، وانتشرت في النهاية إلى أكثر من 700 حزمة npm وعشرات الآلاف من المستودعات. وأدى ذلك إلى تسريب أسرار التكامل والتسليم المستمر (CI/CD) ومفاتيح الوصول السحابية إلى المجال العام في هذه العملية.
على الرغم من أن هذا السيناريو لا يرتبط من الناحية الفنية بالثغرات الأمنية، إلا أن أدوات وسياسات الأمان المطلوبة لإدارته هي نفسها المستخدمة في إدارة الثغرات الأمنية.
كيف يزيد وكلاء الذكاء الاصطناعي من مخاطر استخدام التعليمات البرمجية مفتوحة المصدر؟
يؤدي الدمج السريع وواسع النطاق لوكلاء الذكاء الاصطناعي في تطوير البرمجيات إلى تعزيز سرعة المطورين بشكل كبير، لكنه في المقابل يضخم أثر أي خطأ. وبدون رقابة صارمة وضوابط محددة بوضوح، تظل التعليمات البرمجية التي يولدها الذكاء الاصطناعي عرضة للثغرات بشكل استثنائي. وتظهر الأبحاث أن 45% من التعليمات البرمجية التي يتم توليدها بواسطة الذكاء الاصطناعي تحتوي على عيوب تندرج ضمن قائمة OWASP Top 10، بينما تعاني 20% من التطبيقات المعتمدة على الذكاء الاصطناعي من أخطاء خطيرة في الإعدادات. ويعود ذلك لتدريب نماذج الذكاء الاصطناعي على مجموعات بيانات ضخمة تشمل كميات كبيرة من التعليمات البرمجية القديمة أو التجريبية أو التعليمية. وتطفو هذه المشكلات الهيكلية على السطح عندما يختار نموذج الذكاء الاصطناعي المكونات مفتوحة المصدر لدمجها في المشروع. وغالبًا ما يفتقر النموذج للمعرفة بإصدارات الحزم الحالية أو تلك المصنفة كثغرات أمنية. وبدلاً من ذلك، يقترح إصدار تبعية تم سحبه من بيانات تدريبه، والتي غالبًا ما تكون قديمة. وفي بعض الحالات، يحاول استدعاء إصدارات غير موجودة أو مكتبات وهمية تمامًا. وهذا يفتح الباب أمام هجمات ارتباك التبعيات.
في عام 2025، اقترحت حتى نماذج اللغات الكبيرة الرائدة إصدارات تبعيات غير صحيحة – حيث اختلقت ببساطة الإجابات – في 27% من الحالات.
هل يستطيع الذكاء الاصطناعي إصلاح كل شيء؟
تبدو الفكرة بسيطة ومغرية: بمجرد توجيه وكيل ذكاء اصطناعي نحو التعليمات البرمجية المصدرية الخاصة بك، فإنه سيرصد كل ثغرة أمنية ويعالجها. لكن للأسف، لا يمكن للذكاء الاصطناعي حل هذه المشكلة بشكل كامل. وتعيق العقبات الجوهرية التي ناقشناها وكلاء الذكاء الاصطناعي تمامًا كما تعيق المطورين البشر. وإذا كانت بيانات الثغرات الأمنية مفقودة أو غير موثوقة، ستجد نفسك مضطرًا لإعادة اكتشافها من الصفر بدلاً من العثور على الثغرات الأمنية المعروفة. وهي عملية تستهلك الموارد بشكل هائل وتتطلب خبرات دقيقة تظل بعيدة عن متناول معظم الشركات.
علاوة على ذلك، إذا تم اكتشاف ثغرة أمنية في مكون برمجي قديم أو غير مدعوم، فلن يتمكن وكيل الذكاء الاصطناعي من “إصلاحها تلقائيًا”. وستظل حينها في مواجهة ضرورة تطوير تصحيحات مخصصة أو تنفيذ عملية ترحيل معقدة. وإذا كانت الثغرة مدفونة في أعماق سلسلة من التبعيات، فمن المرجح أن يتجاهلها الذكاء الاصطناعي تمامًا.
ما العمل؟
لتقليل المخاطر المذكورة أعلاه، سيكون من الضروري توسيع نطاق عملية إدارة الثغرات الأمنية لتشمل سياسات تنزيل الحزم مفتوحة المصدر، وقواعد تشغيل مساعدي الذكاء الاصطناعي، وعملية بناء البرمجيات. يشمل ذلك:
- استخدام حل شامل لأمان أعباء العمل السحابية؛
- فحص الحزم مفتوحة المصدر المستخدمة في عملية تطوير برمجياتك عبر مقارنتها بمصادر معلومات التهديدات الخاصة بالمكونات مفتوحة المصدر؛
- دراسة إجراءات الأمان اللازمة لحماية التعليمات البرمجية للذكاء الاصطناعي ووكلاء الذكاء الاصطناعي؛
- الإزالة المنهجية للمكونات مفتوحة المصدر القديمة.
يمكنك قراءة المزيد عن إدارة الثغرات الأمنية في المصادر المفتوحة في مقال مخصص بمدونتنا.
النصائح