عندما يتم تجاهل نتائج فحص الأمان (وكيفية إصلاح ذلك)

خط أنابيب CI/CD لديك مزود بأدوات فحص الأمان. الأدوات مُهيأة، والبوابات (gates) في مكانها. كل شيء يبدو جيدًا على الورق.

لكن إليك ما يحدث فعليًا: يتلقى المطور إشعارًا بأن خط الأنابيب فشل بسبب CVE-2024-1234 في إحدى التبعيات. يُظهر السجل رمز خطأ ومسار ملف طويل. يفتح المطور متصفحًا، ويبحث عن هذا CVE، ويقرأ الأوصاف الفنية، ويحاول معرفة ما إذا كان هذا الخطر حقيقيًا أم مجرد ضوضاء. يستغرق هذا الأمر خمس عشرة دقيقة من تبديل السياق. بعد المرة الثالثة في هذا الأسبوع، يتعلم المطور إما تجاهل الإشعار أو إيجاد طريقة سريعة لتجاوز البوابة.

هذه ليست مشكلة فريق كسول. هذه مشكلة عرض وتدفق عمل.

لماذا يتوقف المطورون عن الاهتمام بنتائج الفحص

الطريقة الافتراضية التي تقدم بها معظم أدوات الأمان النتائج مُحسَّنة لإعداد تقارير الامتثال، وليس للتنفيذ. إنها تُفرغ أرقام CVE الخام، ودرجات الخطورة الفنية، ومسارات الملفات. إنها تفترض أن القارئ لديه الوقت والسياق للتحقيق في كل نتيجة من الصفر.

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

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

اجعل النتائج قابلة للتنفيذ، وليست إعلامية فقط

يبدأ الإصلاح بتغيير طريقة عرض نتائج الفحص. بدلاً من عرض رقم CVE الخام، قم بتضمين المعلومات التي يحتاجها المطور فعليًا للتنفيذ:

• ما هو الخطر الفعلي؟ ليس فقط "خطورة حرجة"، بل "تسمح هذه المكتبة بتنفيذ التعليمات البرمجية عن بُعد".
• ما هو الإصلاح؟ "قم بتحديث المكتبة X من الإصدار 1.2.3 إلى الإصدار 1.2.4."
• من يمكنه المساعدة؟ "اتصل بفريق الأمان على Slack في #security-help."

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

فيما يلي مثال على نتيجة فحص جيدة التنظيم وقابلة للتنفيذ بصيغة JSON:

{
  "cve": "CVE-2024-1234",
  "package": "lodash",
  "current_version": "4.17.20",
  "severity": "critical",
  "risk": "تلوث النموذج الأولي (Prototype pollution) يؤدي إلى تنفيذ التعليمات البرمجية عن بُعد",
  "fix_version": "4.17.21",
  "owner": "team-payments",
  "remediation_url": "https://docs.internal.example.com/fix-lodash-rce",
  "contact_channel": "#security-help"
}

ينطبق نفس المبدأ على نتائج التحليل الثابت (static analysis)، ومشكلات تراخيص الامتثال، وأخطاء تكوين البنية التحتية. يجب أن تجيب كل نتيجة على ثلاثة أسئلة: ما هي المشكلة؟ ماذا يجب أن أفعل؟ من أسأل إذا كنت عالقًا؟

حدد الملكية دون لوم

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

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

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

اجعل التصعيد تلقائيًا، وليس شخصيًا

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

نمط عملي: يرسل خط الأنابيب النتائج إلى قناة Slack الخاصة بالفريق المعني كتذكرة يمكن تعيينها ووسمها وتتبعها. إذا اقترب الموعد النهائي، يتصاعد الإشعار إلى قناة مدير الهندسة. إذا تجاوزه، يتصاعد أكثر.

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

استخدم الاتجاهات، وليس القوائم الخام

لوحة المعلومات التي تعرض قائمة خام من النتائج هي أمر مربك وغير مفيد لفهم الصورة الأكبر. لوحة المعلومات التي تعرض الاتجاهات تحكي قصة.

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

عندما تستطيع الفرق رؤية أن جهودها تقلل عدد النتائج بمرور الوقت، يصبح الفحص أداة للتحسين بدلاً من أن يكون مصدرًا للاحتكاك.

قائمة ممارسات عملية لجعل نتائج الفحص ملزمة

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

التحول من بوابة إلى دليل

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

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

هذا هو الهدف الحقيقي. ليس فقط العثور على الثغرات، ولكن بناء فريق ينتج بشكل طبيعي عددًا أقل منها بمرور الوقت.