ضوابط أمن التطبيقات: دليل مقترح بنطاقات وضوابط مرقمة، مربوط بضوابط NCA وOWASP ASVS

لنفرض أنك مسؤول عن فريق تطوير في جهة حكومية، ووصلك مشروع بوابة خدمات جديدة على الإنترنت، وفي آخر وثيقة المشروع سطر يقول «يجب الالتزام بضوابط الهيئة الوطنية للأمن السيبراني»، فتفتح الضوابط الأساسية للأمن السيبراني ECC وتبحث عن الجزء الخاص بالتطبيقات، فتجد ضابطاً من خمسة بنود قصيرة يطلب معايير التطوير الآمن ومصادر موثوقة ومرخصة للمكتبات واختبار الامتثال والتكامل الآمن، ومكوناً فرعياً لحماية تطبيقات الويب الخارجية يطلب متطلبات موثقة ومعتمدة وجدار حماية ومعمارية متعددة المستويات وHTTPS. وكل هذا صحيح ومهم، ولكن المطور الذي يجلس أمام الكود يسأل أسئلة أخرى: أي معيار للبرمجة الآمنة بالضبط؟ وما الذي يجب أن يختبر في «اختبار الامتثال»؟ وما الذي سوف يطلبه المدقق Auditor دليلاً على أن الصلاحيات صحيحة؟

وهذه الأسئلة ليست تقصيراً في الضوابط، لأن الضوابط الأساسية مكتوبة للجهة كلها، من الاستراتيجية والموارد البشرية إلى النسخ الاحتياطي والأمن المادي، فلا يتوقع منها أن تنزل إلى مستوى طلب الدمج Pull Request وتوكن الجلسة. ولكن بين «استخدام معايير التطوير الآمن» وسطر الكود مسافة كبيرة، وكل جهة تملؤها اليوم بطريقتها، وغالباً بقائمة OWASP Top 10 ومراجعة قبل الإطلاق. لذلك أقترح في هذا الدليل مجموعة ضوابط مرقمة لأمن التطبيقات، مبنية بالشكل الذي تعرفه الجهات السعودية من ضوابط الهيئة (نطاقات ثم ضوابط، ولكل ضابط هدف ومتطلب ودليل)، ومربوطة بالبند الذي تدعمه في ضوابط الهيئة وبالأرقام المقابلة في OWASP ASVS وغيره، ومع كل ضابط مقال من عرب رووت يشرح كيف تنفذه.

وسوف نناقش في هذا المقال ما يلي:

• ماذا تقول الضوابط الأساسية ECC-2:2024 وضوابط الأنظمة الحساسة CSCC عن أمن التطبيقات بالنص والرقم، وما الذي تقدمه حزمة أدوات الهيئة من قوالب، وأين تبقى الفجوة.
• كيف بني الدليل: ثلاثة عشر نطاقاً Domains وتسعون ضابطاً Controls، وتشريح الضابط الواحد، ونظام الترقيم.
• الربط Mapping مع OWASP ASVS 5.0 وOWASP Top 10:2025 وAPI Security Top 10:2023 وNIST SSDF وISO/IEC 27001:2022، وحدود كل ربط.
• كيف تستخدم الدليل بحسب أهمية التطبيق: الدرجة، ثم مستوى ASVS، ثم الضوابط التي تلزمك.
• النطاقات الثلاثة عشر وجدول ضوابط كل نطاق مع الروابط إلى مقالات التنفيذ.
• مسار التبني Adoption في الجهة، والتقييم الذاتي Self-assessment بملف Excel، وملفات التحميل.
• ما الذي لم يشمله الإصدار الأول، والترخيص، وكيف ترسل ملاحظاتك.

ماذا تقول ضوابط الهيئة عن أمن التطبيقات Application Security بالضبط؟

قبل أن أقترح أي شيء يجب أن نقرأ النص نفسه، لأن الكثير مما يقال عن «ضوابط NCA للتطبيقات» منقول من ذاكرة أو من عرض تقديمي، والأرقام في هذا القسم كلها من الوثائق الرسمية المنشورة على موقع الهيئة وقت كتابة المقال (أكتوبر 2026). والصور في هذا القسم مقتطفات قصيرة من وثائق الهيئة العامة للشرح فقط، مع رابط المصدر تحت كل صورة، والتظليل الأصفر مضاف للتوضيح وليس في الأصل.

الضوابط الأساسية للأمن السيبراني ECC-2:2024

الإصدار الحالي من الضوابط الأساسية هو ECC-2:2024، وتقول مقدمته في النسخة العربية (صفحة 6) والنسخة الإنجليزية (صفحة 7) إنها تتكون من 4 مكونات أساسية Main Domains، و28 مكوناً فرعياً Subdomains، و108 ضوابط أساسية Controls، و92 ضابطاً فرعياً Subcontrols، ولاحظ أن الإصدار الأول ECC-1:2018 كان فيه 5 مكونات أساسية و29 مكوناً فرعياً و114 ضابطاً، فإذا قرأت مرجعاً يذكر هذه الأرقام فهو يتحدث عن الإصدار القديم. والضوابط تنطبق بحسب نصها على الجهات الحكومية والجهات التابعة لها، وعلى جهات القطاع الخاص التي تملك أو تشغل أو تستضيف بنى تحتية وطنية حساسة، وتشجع الهيئة بقية الجهات على الاستفادة منها.

ومن بين هذه الضوابط المئة والثمانية يوجد ضابط واحد مخصص لمشاريع تطوير البرمجيات، هو الضابط 1-6-3 داخل المكون الفرعي 1-6 «الأمن السيبراني ضمن إدارة المشاريع المعلوماتية والتقنية» (صفحة 13 في النسخة العربية، وصفحة 16 في الإنجليزية)، والصورة التالية تبين نص المكون الفرعي كما هو في النسخة العربية، والجزء المظلل بالأصفر هو الضابط 1-6-3 ببنوده الخمسة:

ولاحظ أن البنود الخمسة تقول ماذا تريد الجهة ولا تقول كيف، فالبند 1-6-3-1 يطلب «معايير التطوير الآمن» دون أن يسمي معياراً، والبند 1-6-3-3 يطلب اختباراً لمتطلبات الجهة دون أن يحدد هذه المتطلبات، وهذه بالضبط المسافة التي يحاول هذا الدليل أن يملأها.

والجزء الثاني هو المكون الفرعي 2-15 «حماية تطبيقات الويب Web Application Security» (صفحة 21 في العربية، وصفحة 28 في الإنجليزية)، وهدفه ضمان حماية تطبيقات الويب الخارجية للجهة من المخاطر السيبرانية، والصورة التالية تبين نصه الكامل، وفيه أربعة ضوابط مظللة بالأصفر:

والضابطان 2-15-1 و2-15-2 يطلبان أن تكتب الجهة متطلبات حماية تطبيقات الويب وتعتمدها ثم تطبقها، أما الحد الأدنى لهذه المتطلبات فهو في بنود 2-15-3 الخمسة، من جدار الحماية لتطبيقات الويب Web Application Firewall والمعمارية متعددة المستويات Multi-tier Architecture وHTTPS إلى التحقق من الهوية بناء على تقييم الأثر، ثم يأتي 2-15-4 بالمراجعة الدورية. ولاحظ أن البند الأخير في الإصدار الأول كان «التحقق من الهوية متعدد العناصر لعمليات دخول المستخدمين»، وأصبح في الإصدار 2024 مبنياً على تقييم الأثر.

وهناك ضوابط أخرى في ECC تلمس التطبيقات دون أن تكون مخصصة لها، مثل إدارة الهويات والصلاحيات 2-2، والتشفير 2-8 الذي يحيل إلى المعايير الوطنية للتشفير، وإدارة الثغرات 2-10، واختبار الاختراق 2-11 الذي يشمل نطاقه تطبيقات الويب وتطبيقات الهواتف، وإدارة سجلات الأحداث 2-12 بمدة احتفاظ لا تقل عن 12 شهراً، وتدريب العاملين على تطوير البرمجيات في 1-10-4-2، وسوف تجد كل هذه الأرقام في عمود الربط داخل الدليل.

ضوابط الأمن السيبراني للأنظمة الحساسة CSCC

إذا كان التطبيق نظاماً حساساً Critical System فعليه أيضاً ضوابط الأمن السيبراني للأنظمة الحساسة في إصدارها CSCC-1:2019 (وهذا رابط النسخة الإنجليزية، والنسخة العربية منشورة أيضاً في صفحة الضوابط على موقع الهيئة)، وهي امتداد للضوابط الأساسية وتتكون بحسب صفحة 12 من النسخة الإنجليزية من 4 مكونات أساسية و21 مكوناً فرعياً و32 ضابطاً أساسياً و73 ضابطاً فرعياً. وفي الضابط 1-3-2 (صفحة 15 في النسخة العربية، وصفحة 21 في الإنجليزية) تضيف إلى بنود 1-6-3 في ECC أربعة بنود، والصورة التالية تبين نصه، والبنود الأربعة مظللة بالأصفر:

وهذه البنود الأربعة هي أقرب ما في ضوابط الهيئة إلى عمل المطور اليومي، فمراجعة الكود المصدري Source Code Review قبل الإطلاق وحماية المستودع وتأمين واجهات API والترحيل النظيف إلى الإنتاج Production دون بيانات الاختبار وحساباته تجدها كلها مربوطة بضوابط في نطاقات الدليل 08 و10 و11 كما سيأتي.

وفي المكون 2-12 لتطبيقات الويب (صفحة 27 في النسخة الإنجليزية) تضيف إدارة الجلسات الآمنة والحد الأدنى من معايير OWASP Top Ten، وتجعل المعمارية متعددة المستويات بثلاثة مستويات على الأقل، وفي المكون 2-13 «حماية التطبيقات Application Security» (صفحتا 27 و28) تطلب الشيء نفسه تقريباً للتطبيقات الداخلية للأنظمة الحساسة، كما تقصر المدد في مواضع أخرى، مثل اختبار الاختراق كل ستة أشهر على الأقل (2-10-2) والاحتفاظ بالسجلات 18 شهراً (2-11-2). ولاحظ أن CSCC صدرت قبل الإصدار الثاني من ECC وتشير إلى أرقامه القديمة، والأرقام التي استخدمتها هنا (1-6-3 و2-15 و2-12-3) لم يتغير ترقيمها بين الإصدارين.

ما الذي تقدمه حزمة أدوات الهيئة Cybersecurity Toolkits للجهات؟

وقد يتساءل البعض: هل تركت الهيئة الجهات دون أي تفصيل؟ والإجابة لا، فالهيئة تنشر حزمة أدوات الأمن السيبراني Cybersecurity Toolkits، وفيها قوالب Templates جاهزة تملؤها الجهة، ومنها ما يخص التطوير مباشرة: قالب سياسة دورة حياة التطوير الآمن SSDLC، وقالب معيار البرمجة الآمنة، وقالب قائمة التحقق من متطلبات الأمن السيبراني في تطوير البرمجيات، وقالب معيار حماية تطبيقات الويب. وقالب معيار البرمجة الآمنة بالتحديد مفصل أكثر مما يتوقع الكثيرون، فهو مقسم إلى تطوير الكود الآمن ومستودع الكود والمراجعة والاختبار، وفيه جدول إرشادات مرتب على فئات OWASP Top 10:2021، ويطلب استخدام OWASP ASVS دليلاً لتعريف المتطلبات وحالات الاختبار للأنظمة الحساسة. وتنشر الهيئة أيضاً الدليل الإرشادي لتطبيق الضوابط الأساسية GECC-2:2026، وفيه لكل بند من 1-6-3 و2-15 إرشادات تطبيق والمخرجات المتوقعة Expected Deliverables.

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

أين تبقى الفجوة Gap، ولماذا أقترح هذا الدليل؟

لنمر على الحلول التي تختارها أغلب الجهات أولاً، ولماذا لا تكفي وحدها:

1. نسخ نص 1-6-3 و2-15 في وثيقة المشروع: البند يقول ماذا تريد الجهة على مستوى عال، ولا يقول للمطور ما الذي يكتبه، ولا للمختبر ما الذي يختبره، فيبقى «اختبار الامتثال» دون شيء يختبر عليه.
2. اعتماد OWASP Top 10 كمعيار: القائمة وثيقة توعية Awareness Document بأشهر فئات المخاطر كما شرحنا في OWASP Top 10 للمبتدئين، والفئة «كسر التحكم بالوصول Broken Access Control» ليست جملة تنجح أو تفشل.
3. ملء قالب معيار البرمجة الآمنة من حزمة الأدوات: هذه بداية جيدة جداً، ولكن القالب مثال إرشادي تقول الهيئة في إخلاء المسؤولية فيه إنه يجب أن يخصص ويعتمد، وهو مبني على OWASP Top 10:2021 والإصدار الأول من ECC، ولا يربط كل بند برقم متطلب محدد يختبر، ولا يذكر الدليل المطلوب لكل بند، ولا يغطي سلسلة التوريد وخط CI/CD بالتفصيل الذي أصبحت تحتاجه اليوم.
4. اعتماد OWASP ASVS مباشرة: وهذا أقرب الحلول، فالمعيار فيه 345 متطلباً قابلاً للتحقق كما شرحنا في مقال ASVS ومراجعة الكود، ولكنه معيار تحقق للتطبيق نفسه، ولا يغطي الحوكمة ونمذجة التهديدات وحماية المستودع وخط CI/CD والترحيل إلى الإنتاج، ولا يقول للجهة أي بند من ضوابط الهيئة يدعمه كل متطلب.

والحل الذي أقترحه هو طبقة وسطى رقيقة: ضوابط قليلة نسبياً (تسعون ضابطاً في هذا الإصدار) بلغة الجهة وشكل ضوابط الهيئة، كل منها يقول «يجب» بجملة يمكن أن تنجح أو تفشل، ويذكر الدليل الذي يقدم للمدقق، ثم يشير إلى أرقام ASVS لمن يريد التفصيل الفني، وإلى البند الذي يدعمه في ECC أو CSCC لمن يكتب تقرير الامتثال، وإلى مقال عملي لمن سوف ينفذ. وبهذا الشكل تستطيع الجهة أن تأخذ الدليل وتضع اسمها عليه بعد تخصيصه، أو تستخدمه لملء قالب الهيئة نفسه.

كيف بني الدليل؟ نطاقات Domains وضوابط Controls مرقمة

الدليل مبني بالهيكل نفسه الذي تعرفه من ضوابط الهيئة: نطاقات Domains، وداخل كل نطاق ضوابط مرقمة، ولكل ضابط هدف ومتطلب. وأضفت لكل ضابط إرشادات قصيرة للتطبيق، وأمثلة للأدلة Evidence، وأعمدة الربط، ورابط المقال. والنطاقات ثلاثة عشر، موزعة على مراحل دورة حياة التطوير Software Development Life Cycle من المتطلبات إلى التشغيل، والصورة التالية تبين أين يقع كل نطاق:

ونظام الترقيم ARC-ASC-DD-CC مستقل عن ترقيم الهيئة عن قصد، فالجزء ARC-ASC اختصار ArabRoot Application Security Controls، وDD رقم النطاق من 01 إلى 13، وCC رقم الضابط داخل النطاق، فالضابط ARC-ASC-05-03 هو الضابط الثالث في نطاق الصلاحيات. والسبب في عدم استخدام صيغة مثل 1-6-3 أن أي رقم يشبه أرقام الهيئة سوف يفهمه القارئ على أنه منها، وهذا ما لا أريده إطلاقاً. والصورة التالية تبين أجزاء الضابط الواحد:

في الضابط أعلاه لاحظ التالي:

• الدرجة Tier: كل ضابط له درجة من 1 إلى 3 تحدد أقل أهمية للتطبيق يلزمه عندها، فالضوابط في الدرجة 1 تلزم كل التطبيقات، وسوف نشرح الدرجات في قسم الاستخدام.
• المتطلب بصيغة «يجب»: وهي الجملة التي يحكم عليها المدقق بنجح أو فشل، أما الإرشادات فهي نصيحة للتطبيق وليست شرطاً.
• الأدلة: أمثلة لما يقنع المدقق، وليست قائمة مغلقة، فإذا كان عندك دليل أفضل فاستخدمه.
• عمود NCA: البند الذي يدعمه الضابط وليس البند الذي يحل محله، فالتزامك بالضابط يساعدك في إثبات البند ولا يغني عن قراءة نص الهيئة.

الربط Mapping بالمراجع: ماذا يعني كل عمود؟

كل ضابط في الدليل مربوط بستة مراجع، ولكل منها دور مختلف، والصورة التالية تبين الدليل كجسر بين ما تطلبه الهيئة وما يختبره المطور:

• NCA ECC-2:2024 وCSCC-1:2019: البند الذي يدعمه الضابط، وتركته فارغاً حيث لا يوجد بند مباشر بدلاً من ربط ضعيف لا يقنع أحداً. ولاحظ أن كل ضوابط الدليل التي تنطبق على تطبيق ويب خارجي هي في الحقيقة جزء من «متطلبات حماية تطبيقات الويب الخارجية» التي يطلب 2-15-1 تحديدها و2-15-2 تطبيقها، لذلك لم أكرر هذين الرقمين في كل صف.
• OWASP ASVS 5.0.0: أرقام المتطلبات من ملف CSV الرسمي للإصدار 5.0.0 مع مستوى كل متطلب في ملف Excel، وأذكر الرقم فقط دون نسخ النص، والسبب أن نص المعيار له ترخيصه ومكانه الرسمي، وأنه يتغير بين الإصدارات، فاقرأ المتطلب دائماً من المصدر. ولاحظ أن ضابطاً من الدرجة 1 قد يذكر متطلبات من L2، وهذا مقصود، فالتطبيق في المستوى L1 يطبق من القائمة متطلبات L1 فقط.
• OWASP Top 10:2025 وAPI Security Top 10:2023: فئة الخطر التي يمنعها الضابط، كما في قائمة 2025 وقائمة API لعام 2023، وفائدتها في التواصل مع الإدارة وفي تقارير اختبار الاختراق التي تصنف النتائج بها.
• NIST SSDF 1.1: الممارسة أو المهمة في NIST SP 800-218، مثل PW.7 لمراجعة الكود وPS.1 لحماية الكود، وتفيد الجهة التي تبيع برمجيات لجهات تطلب SSDF.
• ISO/IEC 27001:2022: ضابط الملحق Annex A المقابل، ومعظم ضوابط الدليل تقع في 8.25 دورة حياة التطوير الآمن، و8.26 متطلبات أمان التطبيقات، و8.27 المعمارية الآمنة، و8.28 البرمجة الآمنة، و8.29 الاختبار الأمني أثناء التطوير والقبول، و8.31 فصل البيئات، و8.32 إدارة التغيير، و8.33 بيانات الاختبار. والأرقام بحسب قائمة ضوابط الملحق A في المعيار، والمعيار نفسه غير مجاني، فراجع الربط مع نسختك المرخصة قبل استخدامه في تدقيق رسمي.
• مقال التطبيق: مقال من عرب رووت يشرح التنفيذ بأدوات حقيقية، وبعض المقالات ما زالت في خطة النشر، وتعمل روابطها عند نشرها.

كيف تستخدم الدليل بحسب أهمية التطبيق Criticality في جهتك؟

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

1. صنف التطبيق: الدرجة 3 لكل نظام ينطبق عليه تعريف الأنظمة الحساسة في CSCC أو لتطبيق عالي القيمة تقرره الجهة، والدرجة 2 لكل تطبيق خارجي أو يعالج بيانات شخصية أو مصنفة، والدرجة 1 لما بقي. وفي أغلب الجهات سوف تجد أن معظم التطبيقات المهمة في الدرجة 2.
2. اختر مستوى ASVS: الدرجة 1 يقابلها L1، والدرجة 2 يقابلها L2، والدرجة 3 يقابلها L3، وأي انحراف يوثق في سجل القرارات.
3. فلتر الضوابط: التطبيق في درجة معينة يطبق ضوابط درجته وما قبلها، أي 56 ضابطاً للدرجة 1، و87 للدرجة 2، والتسعين كلها للدرجة 3، ومع كل ضابط متطلبات ASVS في مستواه.
4. اكتب وثيقة المتطلبات واعتمدها: احذف ما لا ينطبق مع ذكر السبب، وأضف ما خرجت به جلسة نمذجة التهديدات، ثم تعتمدها إدارة الأمن السيبراني، وهذه الوثيقة هي ما يطلبه 2-15-1 للتطبيقات الخارجية.
5. قيم وكرر: سجل حالة كل ضابط ودليله قبل الإطلاق، وأعد التقييم في المراجعة الدورية وعند كل تغيير جوهري.

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

النطاقات الثلاثة عشر Domains وضوابطها

فيما يلي النطاقات بالترتيب، ولكل نطاق جملة عن سببه ثم جدول مختصر بضوابطه: الرقم، والعنوان مع الدرجة، وأهم أرقام ASVS، وبنود الهيئة، والمقال. أما الهدف والمتطلب الكامل والإرشادات والأدلة وبقية أعمدة الربط فهي في ملف Excel وملف CSV المرفقين في قسم التحميل، لأن الجدول الكامل لا يقرأ على شاشة الهاتف.

01 الحوكمة ومتطلبات الأمان Governance and Security Requirements

هذا النطاق يحول 1-6-3 و2-15-1 و2-15-4 إلى خطوات: تعرف درجة التطبيق، فتختار مستواه، فتكتب متطلباته وتعتمدها، ثم تحملها في التذاكر وتراجعها، ولا يعمل أي نطاق بعده دون هذا النطاق، لأن «اختبار الامتثال» في 1-6-3-3 يحتاج متطلبات معتمدة يختبر عليها.

02 التصميم الآمن ونمذجة التهديدات Secure Design and Threat Modeling

أخطاء التصميم لا تجدها أداة فحص لأنها ليست سطراً خاطئاً، وإنما سطر لم يكتب، لذلك يبدأ هذا النطاق بنمذجة التهديدات التي شرحناها في نمذجة التهديدات Threat Modeling للمبتدئين، ويغطي المعمارية متعددة المستويات من 2-15-3-2 والتكامل الآمن من 1-6-3-4.

03 معايير البرمجة الآمنة Secure Coding Standards

هذا النطاق هو ما يقصده 1-6-3-1 بمعايير التطوير الآمن، والضابط الأول فيه يطلب معياراً لكل لغة، وبقية الضوابط هي البنود التي تتكرر في كل لغة: الأخطاء، والكائنات، والأسرار، والدوال الخطرة، والملفات.

04 الهوية والمصادقة والجلسات Identity, Authentication and Sessions

هنا يقع البند 2-15-3-5 الذي يربط عوامل المصادقة بتقييم الأثر، والبنود المقابلة في CSCC لكلمات المرور وحسابات الخدمة والجلسات، والفكرة الأساسية أن يدير الهوية مزود هوية Identity Provider مركزي كما شرحنا في شرح OAuth وOpenID Connect.

05 الصلاحيات Authorization

كسر التحكم بالوصول Broken Access Control هو الفئة الأولى في OWASP Top 10:2025، وثلاث من فئات API Top 10 عن الصلاحيات، ومع ذلك لا يذكرها البند 2-15 صراحة، فهي تأتي من مبادئ 2-2-3-3 (الحاجة إلى المعرفة وأقل صلاحية وفصل المهام)، والضوابط هنا تحول هذه المبادئ إلى فحص في كل طلب.

06 حماية البيانات والتشفير Data Protection and Cryptography

هذا النطاق يطبق داخل التطبيق ما يطلبه المكونان 2-7 و2-8 للجهة كلها، ويحيل في الخوارزميات إلى المعايير الوطنية للتشفير الصادرة من الهيئة كما يطلب 2-8-3، وفي التنفيذ إلى التشفير للمطورين.

07 معالجة المدخلات والمخرجات ومنع الحقن Input and Output Handling, Injection

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

08 أمن واجهات API Security

البند 1-3-2-3 في CSCC يطلب حماية واجهات API المصادق عليها، وهذا النطاق يفصل ذلك على قائمة OWASP API Security Top 10:2023، من جرد الواجهات إلى حدود الاستهلاك واستهلاك واجهات الطرف الثالث، مع ملاحظة أن صلاحيات الكائن والوظيفة في النطاق 05 تنطبق على الواجهات أيضاً.

09 سلسلة التوريد البرمجية والاعتماديات Software Supply Chain and Dependencies

البند 1-6-3-2 يطلب مصادر مرخصة وموثوقة لأدوات التطوير والمكتبات، وأصبحت سلسلة التوريد فئة مستقلة A03 في Top 10:2025، والضوابط هنا تجعل «موثوقة ومرخصة» شيئاً يقاس: مصادر معتمدة، وSBOM، وفحص، وتثبيت للإصدارات، كما شرحنا في أمن سلسلة التوريد البرمجية.

10 خط CI/CD وحماية الكود المصدري CI/CD Pipeline and Source Code Protection

هنا تقع بنود CSCC عن حماية الكود المصدري (1-3-2-2) والترحيل الآمن من الاختبار إلى الإنتاج (1-3-2-4)، وأضفت إليها حماية خط CI/CD نفسه، لأن الخط الذي يملك مفاتيح الإنتاج أصبح هدفاً بحد ذاته.

11 الاختبار الأمني ومراجعة الكود قبل الإطلاق Security Testing and Review before Release

هذا النطاق هو «اختبار الامتثال» في 1-6-3-3 و«مراجعة الإعدادات» في 1-6-3-5 و«مراجعة الكود قبل الإطلاق» في 1-3-2-1 من CSCC، ويجمع الأدوات مع الإنسان، فكل أداة تجد نوعاً من المشكلات ولا تجد الآخر، كما رأينا في DevSecOps للمبتدئين.

12 النشر والحماية أثناء التشغيل Deployment and Runtime Protection

هنا بقية بنود 2-15-3: جدار حماية تطبيقات الويب وHTTPS وسياسة الاستخدام الآمن، مع ما يحتاجه التطبيق ليعمل بأمان خلف ال Reverse Proxy وداخل ال Container.

13 السجلات والتدقيق والجاهزية للحوادث Logging, Audit and Incident Readiness

المكون 2-12 يطلب تفعيل السجلات ومراقبتها والاحتفاظ بها 12 شهراً، ويرفعها CSCC إلى 18 شهراً للأنظمة الحساسة، ولكن السجل الذي لم يكتبه التطبيق لا يجمعه أي SIEM، لذلك يحدد هذا النطاق ما يجب أن يسجله التطبيق نفسه، وما يجب أن يستطيع فعله يوم الحادث.

من أين تبدأ الجهة؟ مسار التبني Adoption

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

1. المرحلة الأولى، الأساس: صنف كل التطبيقات (01-01)، وطبق ضوابط الدرجة 1 على التطبيقات الجديدة فقط، وابدأ بالضوابط التي تفحص آلياً في خط CI/CD: فحص الأسرار، وSAST، وSCA، وحماية الفرع الرئيسي، لأن تكلفتها مرة واحدة وفائدتها في كل تغيير.
2. المرحلة الثانية، التطبيقات الخارجية: اكتب وثيقة متطلبات معتمدة لكل تطبيق من الدرجة 2 (01-03)، وأضف نمذجة التهديدات واختبارات الصلاحيات وDAST، وابدأ التقييم الذاتي قبل كل إطلاق، وهنا تصبح لديك أدلة حقيقية لتقرير الامتثال على 1-6-3 و2-15.
3. المرحلة الثالثة، الأنظمة الحساسة والقياس: طبق ضوابط الدرجة 3 ومدد CSCC على الأنظمة الحساسة، وقس نسبة التنفيذ لكل نطاق في كل مراجعة دورية، وراجع الاستثناءات المفتوحة، وطبق التحسين على التطبيقات القائمة بالتدريج.

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

التقييم الذاتي Self-assessment بملف Excel

ملف Excel المرفق فيه ثلاث أوراق: «اقرأني» وفيها التنبيه والترخيص وطريقة الاستخدام، و«الضوابط» وفيها الضوابط التسعون بكل أعمدتها مع خمسة أعمدة للتقييم الذاتي، و«النطاقات» وفيها ملخص يحسب نسبة التنفيذ لكل نطاق تلقائياً. والطريقة كما يلي:

1. انسخ الملف لكل تطبيق، وفلتر عمود الدرجة على درجة التطبيق وما قبلها، واحذف ما لا ينطبق أو اختر له «لا ينطبق» مع السبب في الملاحظات.
2. اختر لكل ضابط حالته من القائمة: منفذ، أو جزئي، أو غير منفذ، أو لا ينطبق.
3. ضع في عمود الدليل رابطاً إلى الدليل نفسه (تقرير الفحص، أو إعدادات حماية الفرع، أو محضر المراجعة)، وليس وصفاً له، لأن الوصف لا يقنع المدقق.
4. حدد المسؤول وتاريخ التقييم، وستجد نسبة التنفيذ في ورقة «النطاقات» محسوبة بالمعادلة (منفذ + نصف الجزئي) ÷ (عدد الضوابط ناقص ما لا ينطبق).

تحميل ملفات الضوابط Excel وCSV

الملفان فيهما المحتوى نفسه، والفرق في الاستخدام:

• ملف Excel للضوابط controls.xlsx: من اليمين إلى اليسار، والصف الأول مثبت، مع الفلاتر وقائمة الحالة وورقة الملخص، وهو الأنسب للتقييم الذاتي.
• ملف CSV للضوابط controls.csv: بترميز UTF-8 مع BOM حتى يفتحه Excel بالعربية مباشرة، وهو الأنسب لاستيراد الضوابط في أداة GRC أو نظام تذاكر.

وفي الملفين 90 ضابطاً في 13 نطاقاً، وأعمدتهما: الرقم، والنطاق، والعنوان بالعربية والإنجليزية، والدرجة، والهدف، والمتطلب، والإرشادات، والأدلة، وASVS 5.0.0 مع المستوى، وECC-2:2024، وCSCC-1:2019، وTop 10:2025، وAPI Top 10:2023، وSSDF 1.1، وISO/IEC 27001:2022، ورابط المقال، ثم أعمدة التقييم الذاتي.

ما الذي لم يشمله الإصدار 0.1؟

نطاق هذا الإصدار تطبيقات الويب وواجهات API وخط CI/CD فقط، والسبب أن هذا ما تبنيه أغلب الجهات اليوم، وأن كل نوع آخر يحتاج مرجعه الخاص، وفي الإصدار الثاني بإذن الله:

• تطبيقات الجوال Mobile: نطاق مبني على OWASP MASVS، لأن تخزين البيانات على الجهاز والتواصل مع الخادم وحماية التطبيق نفسه لها متطلبات لا يغطيها ASVS.
• تطبيقات الذكاء الاصطناعي AI: نطاق لتطبيقات نماذج اللغة LLM مبني على قائمة OWASP لتطبيقات LLM التي سوف نشرحها في OWASP Top 10 لتطبيقات نماذج اللغة، مثل حقن التعليمات Prompt Injection والصلاحيات الزائدة للوكلاء.
• ربط إضافي: ضوابط الحوسبة السحابية CCC وضوابط البيانات DCC من الهيئة للتطبيقات التي تعمل في السحابة أو تعالج بيانات مصنفة، وأمثلة لمعايير البرمجة الآمنة لكل لغة.

الترخيص License والملاحظات Feedback

الدليل وملفاته منشورة بترخيص المشاع الإبداعي، نسب المصنف والترخيص بالمثل CC BY-SA 4.0، وهو الترخيص نفسه الذي يستخدمه OWASP ASVS، وهذا يعني أن أي جهة أو شركة تستطيع أن تنسخه وتعدله وتضعه في سياساتها وتستخدمه تجارياً، بشرط أن تذكر المصدر وأن تنشر النسخة المعدلة بالترخيص نفسه إذا نشرتها.

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

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

الخلاصة

وصلنا لنهاية الموضوع، وأهم ما فيه:

• الضوابط الأساسية ECC-2:2024 فيها 108 ضوابط أساسية للجهة كلها، ومنها ضابط واحد لمشاريع تطوير البرمجيات (1-6-3 ببنوده الخمسة) ومكون فرعي لتطبيقات الويب الخارجية (2-15)، وتضيف CSCC للأنظمة الحساسة مراجعة الكود قبل الإطلاق وحماية الكود وتأمين API والترحيل الآمن.
• الهيئة تنشر قوالب إرشادية للتطوير الآمن ومعيار البرمجة الآمنة في حزمة الأدوات، ودليلاً إرشادياً لتطبيق ECC، ولم أجد وثيقة ضوابط مستقلة للتطوير الآمن، والفجوة هي في الربط بين البند والكود والدليل.
• هذا الدليل مقترح مستقل وليس من الهيئة: 13 نطاقاً و90 ضابطاً مرقماً بنظام ARC-ASC-DD-CC، لكل ضابط هدف ومتطلب «يجب» وإرشادات وأدلة، وربط بالبند الذي يدعمه في ECC أو CSCC وبأرقام ASVS 5.0 وفئات Top 10:2025 وAPI Top 10:2023 وممارسات SSDF وضوابط ISO 27001:2022، ومقال للتنفيذ.
• الاستخدام يبدأ بدرجة التطبيق: 1 أساسي (L1 و56 ضابطاً)، و2 قياسي (L2 و87 ضابطاً)، و3 حساس (L3 والتسعون كلها)، ثم وثيقة متطلبات معتمدة، ثم تقييم ذاتي بالأدلة.
• الملفات بترخيص CC BY-SA 4.0، والإصدار 0.1 للمراجعة، والملاحظات مرحب بها.

دليلOWASP ASVS ومراجعة الكود الأمنية لكل Pull Requestكيف تكتب متطلبات أمان يمكن اختبارها مع OWASP ASVS، وتراجع كل طلب دمج أمنياً في عشرين دقيقة بقائمة جاهزة.دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.دليلDevSecOps للمبتدئين: الأمن داخل خط CI/CD ومتى يعمل كل فحصما الذي يجده كل فحص أمني في خط CI/CD وما الذي يفوته، وكيف ترتب نتائجه حتى تصل إلى قرار بدل قائمة طويلة.دليلأمن سلسلة التوريد البرمجية Software Supply Chain للمبتدئينكل ما بين كود غيرك وسيرفرك قد يحمل كود المهاجم، وهنا تعرف التهديدات الحقيقية بحوادث موثقة والدفاع المناسب لكل حلقة.دليلOWASP Top 10 للمبتدئين: أخطر عشر مشكلات في تطبيقات الويبأخطر عشر مشكلات أمنية في تطبيقات الويب، كل واحدة بمثال ضعيف ثم مصلح، وكيف تمنعها في الكود وأين تكتشفها.دليلAuthorization: كيف تجمع قرارات الصلاحيات في مكان واحدلماذا تتحول شروط الصلاحيات المتفرقة في الكود إلى ثغرات، وكيف تنقل القرار إلى محرك سياسات واحد.

سجل التحديثات

• أكتوبر 2026: الإصدار 0.1 للمراجعة، 90 ضابطاً في 13 نطاقاً لتطبيقات الويب وواجهات API وخط CI/CD، بعد مراجعة الضوابط الأساسية ECC-2:2024 بنسختيها العربية والإنجليزية وضوابط الأنظمة الحساسة CSCC-1:2019 وحزمة أدوات الهيئة والدليل الإرشادي GECC-2:2026 من موقع الهيئة، وأرقام OWASP ASVS 5.0.0 من ملف CSV الرسمي، وقائمتي OWASP Top 10:2025 وAPI Security Top 10:2023، وNIST SP 800-218 الإصدار 1.1.
• أكتوبر 2026: صور مظللة من نصوص الضوابط الرسمية بدل سردها.