البرمجة الآمنة (Secure Coding) – تجنّب الثغرات الأمنية قبل أن تنشأ

تصنّف قائمة CWE Top 25 الصادرة عن MITRE أخطر فئات ضعف البرمجيات؛ ويستند إصدار 2025 إلى 39,080 سجل CVE من الفترة يونيو 2024 حتى يونيو 2025، مرجّحة حسب التكرار ومتوسط درجة الخطورة وفق CVSS. وتتصدّر القائمة Cross-Site Scripting (CWE-79) وSQL-Injection (CWE-89) وCross-Site Request Forgery (CWE-352) – أنماط معروفة منذ عقود، لكنها تبقى الأسباب الأكثر شيوعًا لثغرات CVE الفعلية. ويلفت النظر إلى جانب ذلك كتلتان: أخطاء الذاكرة مثل Out-of-bounds Write/Read وUse After Free (لا سيما في قواعد شيفرة C/C++)، وأربع نقاط ضعف في التفويض (CWE-862 وCWE-863 وCWE-284 وCWE-639). وبالنسبة للبرمجة الآمنة يعني ذلك: معظم الثغرات تتبع أنماطًا معروفة يمكن تجنّبها – ويمكن معالجتها بشكل موجّه.

تجمع OWASP Top 10 نقاط الضعف الفردية في فئات مخاطر؛ وإصدار 2025 هو الإصدار المنشور الحالي ويستند إلى بيانات اختبار لنحو 2.8 مليون تطبيق. يبقى Broken Access Control في المرتبة الأولى ويشمل الآن أيضًا Server-Side Request Forgery؛ والجديد هو A03 «Software Supply Chain Failures» كتوسعة لفئة «Vulnerable and Outdated Components» السابقة، وكذلك A10 «Mishandling of Exceptional Conditions». وتبقى Injection (A05) وSecurity Misconfiguration (A02) وCryptographic Failures (A04) حاضرة بقوة. تصلح Top 10 جيدًا للتوعية وتحديد الأولويات – لكنها لا تحلّ محلّ قائمة متطلبات كاملة للتطوير.

يترجم OWASP Application Security Verification Standard البرمجة الآمنة إلى متطلبات قابلة للتحقق. يضمّ الإصدار 5.0.0 (المنشور في مايو 2025) نحو 350 متطلبًا في 17 فصلًا – من Encoding وSanitization مرورًا بالتفويض وإدارة الجلسات والتشفير وصولًا إلى Secure Coding and Architecture. وقد أُعيد تقسيم المستويات الثلاثة مقارنة بالإصدار 4.x ورُتّبت حسب الأولوية: يتضمّن L1 كنقطة انطلاق نحو 20 بالمائة من المتطلبات (خط الدفاع الأول الحرج)، ويضيف L2 كمستوى مستهدف لمعظم التطبيقات نحو 50 بالمائة أخرى، ويضمّ L3 إجراءات Defense-in-Depth المتبقية. وفي الممارسة يُستخدم ASVS إطارًا للمتطلبات في التطوير والشراء، وكذلك معيارًا للتحقق في مراجعات الشيفرة واختبارات الاختراق.

تغطي أربع ممارسات جزءًا كبيرًا من خريطة الثغرات الأمنية. أولًا التحقق من المدخلات: فحص جميع المدخلات على جانب الخادم مقابل قوائم مسموح بها (النوع، الطول، نطاق القيم، الصياغة المسموحة) – وهذا يقلّص سطح الهجوم لكنه لا يحلّ محلّ الترميز. ثانيًا ترميز المخرجات حسب السياق والاستعلامات المُعلَمة: فهي تُحيّد فئات Injection مثل XSS وSQL-Injection من جذورها. ثالثًا التفويض وفق نمط «deny by default»: كل فحص للوصول إلى الكائنات والوظائف يتم على جانب الخادم وبشكل مركزي (Policy أو Middleware) بدلًا من فحوص فردية متفرقة – وذلك تحديدًا ضد الفئتين البارزتين في تصنيف CWE وهما CWE-862 وCWE-639. رابعًا التعامل مع الأسرار: لا بيانات اعتماد أو مفاتيح في الشيفرة المصدرية أو في المستودعات، بل مخازن أسرار مركزية مع التدوير والحد الأدنى من الصلاحيات، مع فحص الأسرار (Secret-Scanning) في خط المعالجة.

لا تؤتي البرمجة الآمنة ثمارها إلا إذا كانت راسخة في عملية التطوير. يحلّل SAST الشيفرة المصدرية منذ مرحلة Pull Request ويكتشف أنماطًا مثل مواضع Injection أو الأسرار المضمّنة في الشيفرة؛ ويختبر DAST التطبيق أثناء التشغيل ويكشف مشكلات الإعداد ووقت التشغيل – وكلاهما يكمّل الآخر دون أن يحلّ محلّه. وتبقى مراجعات الشيفرة الأمنية اليدوية لا غنى عنها لنقاط الضعف المنطقية مثل غياب التفويض، لأن الأدوات المؤتمتة بالكاد تكتشف مثل هذه الأخطاء. ويوفّر NIST Secure Software Development Framework (SP ⁦800-218⁩، الإصدار 1.1) الإطار التنظيمي بأربع مجموعات ممارسات من إعداد المؤسسة حتى الاستجابة للثغرات؛ وتوفّر مستويات ASVS وفئات CWE المقياس المضموني لبوابات الجودة (Quality Gates) والمقاييس.

تفشل المعايير والأدوات دون مطوّرين قادرين على تطبيقها. التمكين الفعّال مخصّص حسب الدور والتقنيات: تدريبات مبنية على فئات الثغرات المكتشفة فعليًا في الشيفرة الخاصة بدلًا من دورات سنوية عامة، مع أبطال الأمن (Security Champions) داخل الفرق كنقطة اتصال أولى. ومن المهم بالقدر نفسه مبدأ «الطريق المعبَّد» (Paved Road): مكتبات مُختبرة، وإعدادات افتراضية آمنة لأطر العمل، وقوالب تجعل الخيار الآمن هو الأسهل – وتقدّم OWASP Top 10 Proactive Controls 2024 (C1–C10) لهذا الغرض قائمة أولويات موجزة وقريبة من المطوّرين. ويصبح البرنامج قابلًا للقياس عبر مؤشرات مثل معدل تكرار ظهور فئات ثغرات بعينها والوقت حتى المعالجة.