원본 영상을 바탕으로 AI의 도움을 받아 작성했습니다. 원본 영상이 기준입니다.
Log in to leave a comment
아직 작성된 글이 없습니다
المصادر المفتوحة مريحة، لكنها محفوفة بالمخاطر بنفس القدر. وفقاً لدراسة أجريت عام 2025، ومع بدء الذكاء الاصطناعي في كتابة الأكواد نيابة عن البشر، ارتفع معدل الأخطاء بنسبة 41% مقارنة بالعام السابق. بالنسبة لمسؤول أمني يضطر لمراجعة عشرات الآلاف من الأسطر في المكتبات الخارجية بمفرده، فإن هذا ليس أقل من كارثة. بما أنه لا يمكن قراءة كل الكود، يجب علينا جعل الذكاء الاصطناعي حليفاً لنا. لقد لخصنا كيفية إنشاء سير عمل أمني يعمل بذكاء، تماماً مثل Project Glasswing.
يمكن أن تؤدي أتمتة المراجعة الأمنية إلى التخلص من المهام المتكررة البسيطة التي كانت تستغرق أكثر من 10 ساعات أسبوعياً. كما تمنع الأخطاء التي قد يغفل عنها البشر عند المسح البصري. قم ببناء خط أنابيب (Pipeline) يستدعي واجهة برمجة تطبيقات LLM في بيئة GitHub Actions للمسح في الوقت الفعلي في كل مرة يتم فيها رفع طلب سحب (Pull Request). المفتاح هنا ليس مجرد طرح الأسئلة، بل استراتيجية فصل التحديد (Identification) عن التدقيق (Audit).
LLM_API_KEY في GitHub Secrets. يجب وضعه في مستودع Libsodium المشفر لمنع تسرب المفتاح للخارج.path-filter في إعدادات YAML لاختيار وفحص المجلدات الحساسة فقط مثل src/auth أو lib/core التي قد تؤدي كارثة فيها إلى نهاية المشروع.بمجرد انتهاء هذا الإعداد، لن يحتاج المسؤول الأمني إلا إلى مراجعة التقرير الأمني الذي لخصه الذكاء الاصطناعي بدلاً من عشرات الآلاف من أسطر الكود.
تنجح أدوات الذكاء الاصطناعي في العثور على الثغرات، لكنها تعطي الكثير من النتائج الإيجابية الكاذبة (False Positives). إذا وجدت 100 ثغرة وكان 15 منها غير حقيقي، فسيشعر فريق التطوير بالإحباط لا محالة. لتجنب هدر موارد التطوير المحدودة، نحتاج إلى معايير لتمييز التهديدات الحقيقية. حدد الأولويات من خلال دمج درجات CVSS 4.0 مع مؤشرات EPSS التي تخبرك ما إذا كانت هناك هجمات فعلية تحدث حالياً.
التركيز فقط على الثغرات ذات الدرجات الطارئة التي تبلغ 9.0 فما فوق سيزيد من مستوى الأمان بشكل كبير. كما أن تقليل طلبات التعديل غير الضرورية سيقلل بشكل طبيعي من الصراعات مع فريق التطوير.
قد تبدو التعديلات المقترحة من الذكاء الاصطناعي مثالية في الظاهر، لكنها أحياناً تفسد وظائف سليمة. شركات مثل Shopify تستخدم الذكاء الاصطناعي لكنها لا تثق في الكود المولد بشكل أعمى. يجب وضع إجراءات للتحقق تلقائياً من سلامة كود الإصلاح في بيئات معزولة مثل Firecracker أو gVisor.
sbx CLI لتشغيل MicroVM تمتلك نفس بيئة التشغيل (Runtime) الخاصة بالخدمة الحالية.وجود مثل هذه الضمانات يمنع وقوع حوادث ناتجة عن رفع أكواد صنعها الذكاء الاصطناعي تبدو صحيحة لكنها خاطئة تقنياً إلى خادم التشغيل.
لا ينبغي أن نكتفي بإصلاح خدمتنا فقط. من مسؤولية المسؤول الأمني أيضاً الإبلاغ عن عيوب المصدر المفتوح نفسه إلى المشروع الأصلي. المطورون (Maintainers) مشغولون، لذا يجب تزويدهم بأدلة واضحة. استخدم قناة PVR في GitHub لإرسال التقارير بمسؤولية.
اكتب نوع الثغرة وموقعها بوضوح في العنوان. من الأساسيات إرفاق خطوات إعادة إنتاج الثغرة ولقطات شاشة يمكن لأي شخص اتباعها. والأفضل من ذلك هو إرسال كود الإصلاح الذي تم التحقق منه مسبقاً في Sandbox. تقليل وقت المراجعة يزيد بشكل كبير من احتمالية قبول الإصلاح. تقرير واحد متقن يثبت القوة التقنية للشركة وقد يؤدي إلى الحصول على رقم CVE رسمي.