جاهزية CRA تبدأ من قاعدة الكود: 7 أسئلة لكشف الثغرات

غالبًا ما يُنظر إلى قانون المرونة السيبرانية (CRA) كتحدٍ سياسي أو متعلق بالإبلاغ، لكن أثره على مصنّعي العناصر الرقمية يظهر أبكر بكثير: في pull request، وخطوط build، وموافقات الإصدار، ومجموعات الاختبارات. لن تتمكن الشركة من تقديم تقرير موثوق عن ثغرة مستغلة إذا لم تستطع مسبقًا الإجابة عن أسئلة هندسية بسيطة: ما الإصدارات المتأثرة، وما المكوّن الذي أنشأ الخطر، وهل نجح الإصلاح في المنتج الفعلي.

المواعيد التي دخلت حيز التنفيذ بالفعل

في إطار CRA، يُلزَم مصنّعو العناصر الرقمية بالإبلاغ، عبر عملية الإبلاغ في الاتحاد الأوروبي، عن الثغرات المستغلة فعليًا والحوادث الجسيمة. يسري هذا المطلب اعتبارًا من 11 سبتمبر من هذا العام، بينما يدخل معظم الالتزامات الأخرى حيّز التنفيذ في ديسمبر 2027. التواريخ مهمة، لكن السؤال الأكثر فائدة لقادة الهندسة هو ما إذا كان نظام تسليم البرمجيات قادرًا على تسجيل نتائج أمنية موثوقة وإثباتها. نادرًا ما تكمن الإجابة في أداة أمنية منفردة أو تدقيق يُجرى في اللحظة الأخيرة.

من السياسات إلى ضوابط قابلة للمراقبة

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

سبعة أسئلة تكشف الفجوات

يقترح المقال سبعة فحوص تركز على قاعدة الكود: هل الإعدادات الافتراضية الآمنة مدمجة في المنتج؛ هل يستطيع الفريق تمييز التغييرات الحساسة مثل التفويض والتشفير؛ هل يمكن تتبع كل إصدار إلى المصدر الدقيق والمكوّنات، بما في ذلك SBOM؛ هل تعمل الفحوص المطلوبة قبل دمج الكود؛ هل يمكن لنتيجة شديدة الخطورة أن توقف build أو الإصدار؛ هل تختبر الاختبارات السلوك الخبيث وغير المتوقع؛ وهل تثبت اختبارات الإصدار السلوك الأمني الفعلي وقت التشغيل.

ترتيب الأولويات حسب المخاطر وأثر AI

يجب أن تكون نتيجة التقييم خطة مرتبة حسب المخاطر: إعداد افتراضي آمن مفقود في منتج مفتوح للإنترنت أكثر إلحاحًا من خلل في أتمتة مكوّن داخلي منخفض المخاطر. يؤخذ في الاعتبار انفتاح المنتج، وحرجية الوظيفة، وقابلية الاستغلال، وعدد الإصدارات المتأثرة. ويُضاف إلى ذلك نمو التطوير الوكيلي: في دراسة أجرتها Sonar، يقول 96% من المطورين إنهم لا يثقون تمامًا بالكود الذي يكتبه AI، لكن 48% فقط يفحصونه دائمًا قبل commit. هذا الفارق يجعل الضوابط الآلية لا بديل عنها، بغض النظر عن كون الكود من إنسان أم من وكيل.

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