كيفية ربط واجهة برمجة تطبيقات LLM بمسح الثغرات الأمنية في المصادر المفتوحة لتقليل وقت المراجعة الأمنية

المصادر المفتوحة مريحة، لكنها محفوفة بالمخاطر بنفس القدر. وفقاً لدراسة أجريت عام 2025، ومع بدء الذكاء الاصطناعي في كتابة الأكواد نيابة عن البشر، ارتفع معدل الأخطاء بنسبة 41% مقارنة بالعام السابق. بالنسبة لمسؤول أمني يضطر لمراجعة عشرات الآلاف من الأسطر في المكتبات الخارجية بمفرده، فإن هذا ليس أقل من كارثة. بما أنه لا يمكن قراءة كل الكود، يجب علينا جعل الذكاء الاصطناعي حليفاً لنا. لقد لخصنا كيفية إنشاء سير عمل أمني يعمل بذكاء، تماماً مثل Project Glasswing.

تثبيت محرك أمني يعمل بالذكاء الاصطناعي في GitHub Actions

يمكن أن تؤدي أتمتة المراجعة الأمنية إلى التخلص من المهام المتكررة البسيطة التي كانت تستغرق أكثر من 10 ساعات أسبوعياً. كما تمنع الأخطاء التي قد يغفل عنها البشر عند المسح البصري. قم ببناء خط أنابيب (Pipeline) يستدعي واجهة برمجة تطبيقات LLM في بيئة GitHub Actions للمسح في الوقت الفعلي في كل مرة يتم فيها رفع طلب سحب (Pull Request). المفتاح هنا ليس مجرد طرح الأسئلة، بل استراتيجية فصل التحديد (Identification) عن التدقيق (Audit).

• حماية مفتاح API: قم بتسجيل LLM_API_KEY في GitHub Secrets. يجب وضعه في مستودع Libsodium المشفر لمنع تسرب المفتاح للخارج.
• إعداد المجلدات المستهدفة: ليس من الضروري فحص جميع الملفات. استخدم path-filter في إعدادات YAML لاختيار وفحص المجلدات الحساسة فقط مثل src/auth أو lib/core التي قد تؤدي كارثة فيها إلى نهاية المشروع.
• التحقق المتبادل: في الخطوة الأولى، اترك LLM يحلل هيكل الكود ويكتب ملاحظات، ثم في الخطوة الثانية، قم بإجراء المسح بشكل متكرر 3 مرات أو أكثر بناءً على تلك الملاحظات. أحياناً يهذي الذكاء الاصطناعي، لذا يلزم إجراء عملية مطابقة النتائج من خلال التحقق لعدة مرات.

بمجرد انتهاء هذا الإعداد، لن يحتاج المسؤول الأمني إلا إلى مراجعة التقرير الأمني الذي لخصه الذكاء الاصطناعي بدلاً من عشرات الآلاف من أسطر الكود.

اختيار التهديدات الحقيقية باستخدام CVSS و EPSS

تنجح أدوات الذكاء الاصطناعي في العثور على الثغرات، لكنها تعطي الكثير من النتائج الإيجابية الكاذبة (False Positives). إذا وجدت 100 ثغرة وكان 15 منها غير حقيقي، فسيشعر فريق التطوير بالإحباط لا محالة. لتجنب هدر موارد التطوير المحدودة، نحتاج إلى معايير لتمييز التهديدات الحقيقية. حدد الأولويات من خلال دمج درجات CVSS 4.0 مع مؤشرات EPSS التي تخبرك ما إذا كانت هناك هجمات فعلية تحدث حالياً.

1. التحقق من الدرجة الأساسية: انظر أولاً إلى الخطورة التقنية من خلال درجة CVSS 4.0 الأساسية.
2. تعديل الدرجة البيئية: قم بخفض أو زيادة الدرجة بناءً على ما إذا كان الكود معرضاً للإنترنت الخارجي أو يعمل فقط داخل الشبكة الداخلية.
3. مقارنة احتمالية الهجوم: استعلم من قاعدة بيانات EPSS للتأكد مما إذا كانت تلك الثغرة شائعة بين المهاجمين حالياً. إذا تجاوزت احتمالية الهجوم 50%، يجب تنحية كل الأعمال الأخرى جانباً وإصلاحها فوراً.

التركيز فقط على الثغرات ذات الدرجات الطارئة التي تبلغ 9.0 فما فوق سيزيد من مستوى الأمان بشكل كبير. كما أن تقليل طلبات التعديل غير الضرورية سيقلل بشكل طبيعي من الصراعات مع فريق التطوير.

التحقق من كود الإصلاح في Sandbox ونشره

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

• إنشاء بيئة معزولة: استخدم sbx CLI لتشغيل MicroVM تمتلك نفس بيئة التشغيل (Runtime) الخاصة بالخدمة الحالية.
• محاكاة الهجوم: تأكد من أن الثغرة قابلة للاختراق فعلياً باستخدام نص هجوم (Exploit Script)، ثم طبق الإصلاح المقدم من الذكاء الاصطناعي وهاجم مرة أخرى للتأكد من سد الثغرة.
• اختبار الوظائف: قم بتشغيل اختبارات الوحدة (Unit Tests) الحالية بعد تطبيق الإصلاح. لا فائدة من سد الثغرة الأمنية إذا أصبح تسجيل الدخول لا يعمل.

وجود مثل هذه الضمانات يمنع وقوع حوادث ناتجة عن رفع أكواد صنعها الذكاء الاصطناعي تبدو صحيحة لكنها خاطئة تقنياً إلى خادم التشغيل.

كتابة تقرير يقبله مطورو المصادر المفتوحة فوراً

لا ينبغي أن نكتفي بإصلاح خدمتنا فقط. من مسؤولية المسؤول الأمني أيضاً الإبلاغ عن عيوب المصدر المفتوح نفسه إلى المشروع الأصلي. المطورون (Maintainers) مشغولون، لذا يجب تزويدهم بأدلة واضحة. استخدم قناة PVR في GitHub لإرسال التقارير بمسؤولية.

اكتب نوع الثغرة وموقعها بوضوح في العنوان. من الأساسيات إرفاق خطوات إعادة إنتاج الثغرة ولقطات شاشة يمكن لأي شخص اتباعها. والأفضل من ذلك هو إرسال كود الإصلاح الذي تم التحقق منه مسبقاً في Sandbox. تقليل وقت المراجعة يزيد بشكل كبير من احتمالية قبول الإصلاح. تقرير واحد متقن يثبت القوة التقنية للشركة وقد يؤدي إلى الحصول على رقم CVE رسمي.