> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # Secure SDLC: الأمن في كل مرحلة من حياة التطبيق - URL: https://arabroot.io/articles/دورة-حياة-تطوير-البرمجيات-الامنة-secure-sdlc/ - Published: 2026-10-06T15:30:00.000Z - Updated: 2026-10-09T13:02:49.000Z - Description: ماذا تفعل للأمن في كل مرحلة من حياة التطبيق من المتطلبات إلى إيقافه، ومن يملك كل خطوة، وكيف تبدأ في أول تسعين يوماً. - Author: فريق عرب رووت - Tags: الأدلة التقنية, الأمن السيبراني, DevOps وCI/CD, الاستضافة الذاتية لنفرض أن لديك فريقاً أضاف في خط CI أداة لفحص الكود SAST وأداة لفحص الاعتماديات SCA، وأصبحت كل طلبات الدمج Pull Requests تمر عليهما بنجاح، ثم يأتي تقرير اختبار الاختراق Penetration Testing بثغرة خطيرة لا تراها أي أداة، وهي أن أي عميل يستطيع أن يقرأ فواتير عميل آخر إذا غير رقماً في الرابط، والسبب أن أحداً لم يكتب في المتطلبات أن بيانات كل عميل معزولة عن غيره، ولم يسأل أحد في التصميم «ماذا لو طلب المستخدم كائناً لا يملكه؟». وفي الأسبوع نفسه يطلب المدقق دليلاً على أن الجهة «تختبر التزام التطبيقات بمتطلبات الأمن السيبراني» كما يطلب البند 1-6-3-3 من ضوابط الهيئة، فيكتشف الفريق أنه لا توجد متطلبات مكتوبة أصلاً ليختبر عليها، وأن لا أحد يعرف من المسؤول عن هذا كله. والمشكلة هنا ليست في الأدوات، فالأدوات تعمل، وإنما في أن الأمن يحدث في مكان واحد من دورة بناء التطبيق، بينما الأخطاء تولد في كل مكان: في المتطلبات وفي التصميم وفي الكود وفي الإعداد وفي التشغيل، وحتى بعد إيقاف التطبيق. وهذا هو موضوع **دورة حياة تطوير البرمجيات الآمنة Secure SDLC**. وقد شرحنا في الموقع أغلب الأجزاء في مقالات مستقلة، من متطلبات ASVS إلى نمذجة التهديدات إلى الفحوص الآلية والسجلات والتحقيق في الحوادث، وهذا المقال هو الدليل الرئيسي الذي يجمعها في مسار واحد، فيقول لك في كل مرحلة ماذا تفعل، وما الذي يخرج منها، ومن يملكها، وأي مقال يشرحها بالتفصيل. وسوف نناقش في هذا المقال ما يلي: - ما هي دورة حياة تطوير البرمجيات SDLC ومراحلها السبع، والفرق باختصار بين نموذج الشلال Waterfall والنماذج التكرارية Iterative وAgile. - لماذا يفشل الأمن الذي يضاف في النهاية، وماذا تقول المراجع عن تكلفة الإصلاح المتأخر دون أرقام مبالغ فيها، وما معنى Secure SDLC. - المراجع التي تصف Secure SDLC: إطار NIST SSDF، وممارسات Microsoft SDL، ونموذج OWASP SAMM، والضابط 8.25 في ISO/IEC 27001، والضابط 1-6-3 في ضوابط الهيئة NCA ECC، مع جدول يربطها بالمراحل وبنطاقات دليل ضوابط أمن التطبيقات ARC-ASC. - المراحل واحدة واحدة: الهدف والأنشطة والمخرجات والأدوات والمسؤول والمقال الذي يشرحها، من المتطلبات إلى إيقاف التطبيق. - الأدلة Evidence التي تتركها كل مرحلة، والأدوار Roles مع جدول RACI. - كيف يطبق فريق من ثلاثة أشخاص هذه الدورة، وكيف تطبقها شركة من خمسين، وخطة لأول تسعين يوماً، والمقاييس Metrics التي تستحق أن تقاس. ## ما هي دورة حياة تطوير البرمجيات SDLC؟ **دورة حياة تطوير البرمجيات Software Development Life Cycle**، واختصاراً SDLC، هي الطريقة التي يمر بها التطبيق من فكرة إلى برنامج يعمل ثم إلى برنامج يتوقف، وتعرفها وثيقة [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final?ref=arabroot.io) بأنها منهجية رسمية أو غير رسمية لتصميم البرمجيات وبنائها وصيانتها. ولاحظ كلمة «غير رسمية»، فحتى الفريق الذي يقول إنه لا يتبع أي منهجية يمر بهذه المراحل، فهو يفهم المطلوب ثم يفكر في الحل ثم يكتب الكود ثم يجربه ثم ينشره ثم يصلحه، والفرق أنه يفعل ذلك دون أن يسميه. ### المراحل السبع Phases تختلف أسماء المراحل من مرجع إلى آخر، ولكنها في الغالب ترجع إلى سبع مراحل، وهي التي سوف نعتمد عليها في بقية المقال: 1. **المتطلبات Requirements:** ماذا يجب أن يفعل التطبيق، ولمن، وتحت أي قيود، ومنها قيود الأمان والخصوصية والامتثال. 2. **التصميم Design:** كيف سيبنى التطبيق، أي المكونات والبيانات وحدود الثقة Trust Boundaries بينها، وكيف يتكامل مع الأنظمة الأخرى. 3. **كتابة الكود Implementation:** كتابة الكود ومراجعته واختيار المكتبات. 4. **التحقق والاختبار Verification and Testing:** التأكد من أن ما بني يفعل المطلوب ولا يفعل غير المطلوب. 5. **الإصدار والنشر Release and Deployment:** تحويل الكود إلى نسخة تنشر، ونقلها إلى الإنتاج Production. 6. **التشغيل والصيانة Operations and Maintenance:** المراقبة والتحديث وإصلاح الثغرات والاستجابة للحوادث، وهي أطول مرحلة في عمر أي تطبيق. 7. **الإيقاف Retirement أو Decommissioning:** إيقاف التطبيق وحذف بياناته وإلغاء صلاحياته وأرشفة كوده. ### الشلال Waterfall أم التكرار Iterative وAgile؟ في نموذج **الشلال Waterfall** تمر المراحل مرة واحدة بالترتيب، فتكتب كل المتطلبات ثم يكتمل التصميم ثم يكتب الكود كله ثم يختبر ثم ينشر، وهذا النموذج مناسب للمشاريع التي لا تتغير متطلباتها كثيراً، مثل نظام مرتبط بعقد ثابت. أما في **النماذج التكرارية Iterative** ومنها **Agile**، فتمر المراحل كلها في دورة قصيرة، أسبوعين مثلاً، على جزء صغير من التطبيق، ثم تعاد الدورة على الجزء التالي، ومع DevOps أصبحت الدورة أقصر، فقد يمر التغيير الواحد بالمراحل كلها في يوم واحد، من التذكرة إلى الإنتاج. وقد يتساءل البعض: إذا كانت المراحل في Agile تحدث في يوم واحد، فهل ما زال تقسيمها مفيداً؟ والإجابة نعم، والسبب أن المراحل لا تختفي في Agile وإنما تصغر، فالتذكرة التي فيها معايير القبول Acceptance Criteria هي المتطلبات، والنقاش على السبورة قبل البدء هو التصميم، وطلب الدمج هو كتابة الكود ومراجعته، وخط CI هو التحقق، والنشر الآلي هو الإصدار. ولهذا تقول NIST SSDF إن أغلب نماذج SDLC لا تتناول الأمن بالتفصيل، وإن ممارسات التطوير الآمن تضاف إلى أي نموذج تستخدمه، سواء كان الشلال أو الحلزوني Spiral أو Agile أو Agile مع DevOps. لذلك لا تحتاج أن تغير نموذج عمل فريقك لتطبق Secure SDLC، وإنما تضيف نشاطاً أمنياً صغيراً داخل كل مرحلة من المراحل التي تمر بها فعلاً، والفرق بين النماذج هو حجم هذا النشاط وتكراره فقط. ## لماذا يفشل الأمن Security الذي يضاف في النهاية؟ الطريقة التي تبدأ بها أغلب الفرق هي أن تبني التطبيق كما تريد، ثم تطلب فحصاً أمنياً قبل الإطلاق، وقد شرحنا في [دليل DevSecOps](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#late-security) لماذا يفشل هذا الحل: الفحص يأتي متأخراً، ويحدث مرة واحدة بينما الكود يتغير كل يوم، ويتحول فريق الأمن إلى طابور، ولا يتعلم المطور شيئاً من قائمة ملاحظات تصله بعد أسابيع. ولكن هناك نقطة يضيفها هذا المقال، وهي أن خط CI نفسه يبدأ من مرحلة كتابة الكود، فحتى الفريق الذي نقل الفحوص كلها إلى طلب الدمج ما زال يبدأ الأمن متأخراً بمرحلتين، لأن أخطر الأخطاء تولد قبل أول سطر. والصورة التالية تبين الفرق بين نوعين من الأخطاء: ![منحنيان يرتفعان عبر مراحل المتطلبات والتصميم وكتابة الكود والتحقق والإصدار والتشغيل: منحنى خطأ الكود يبدأ من مرحلة كتابة الكود ويرتفع ببطء من تعديل سطر إلى إصلاح عاجل وحادثة، ومنحنى خطأ التصميم مثل غياب عزل بيانات العملاء يبدأ من المتطلبات بإضافة جملة ثم تعديل المخطط ثم إعادة هيكلة ثم تأجيل الإصدار ثم إعادة التصميم وترحيل البيانات في الإنتاج، مع ملاحظة أن الرسم توضيحي بلا أرقام](https://arabroot.io/content/images/2026/10/secure-sdlc-02-cost-of-late-fix.webp) رسم توضيحي للفكرة وليس قياساً: خطأ التصميم يبدأ أبكر ويصبح أغلى بكثير من خطأ الكود كلما تأخر اكتشافه في الرسم أعلاه لاحظ التالي: - **خطأ الكود Coding Bug**، مثل استعلام SQL مبني بدمج النصوص، يولد وقت كتابة الكود، وإصلاحه في أغلب الأحوال تعديل سطر، حتى لو اكتشف في الإنتاج، فيحتاج إصدار إصلاح عاجل Hotfix، وقد يصبح حادثة إذا استغله أحد قبلك. - **خطأ التصميم Design Flaw**، مثل غياب عزل بيانات كل عميل Tenant Isolation في المثال الذي بدأنا به، يولد في المتطلبات، وإصلاحه وقتها جملة واحدة في وثيقة، وفي التصميم تعديل في المخطط، أما في الإنتاج فقد يعني إعادة تصميم طبقة الصلاحيات كلها وترحيل بيانات وإبلاغ عملاء. - لم نضع أرقاماً على المحور الرأسي، والسبب أن الأرقام المتداولة لهذه الفكرة، مثل «الإصلاح في الإنتاج يكلف مئة ضعف»، يصعب تتبعها إلى دراسة أصلية يمكن الاعتماد عليها، لذلك نعتمد على ما تكتبه [NIST SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final?ref=arabroot.io) في مقدمتها، وهو أن أغلب جوانب الأمن يمكن التعامل معها أكثر من مرة في دورة التطوير، ولكن كلما عولج الأمن أبكر في الدورة قل الجهد والتكلفة اللازمان للوصول إلى مستوى الأمان نفسه، وأن هذا المبدأ، الذي يسمى النقل إلى اليسار Shift-Left، مهم في أي نموذج تطوير. وتذكر السبب الثالث الذي تذكره الوثيقة نفسها لدمج الأمن في الدورة كلها، فهي تذكر ثلاثة أهداف: تقليل عدد الثغرات في النسخ المنشورة، وتقليل أثر استغلال الثغرات التي لم تكتشف، ومعالجة الأسباب الجذرية Root Causes للثغرات حتى لا تتكرر. والهدف الثالث لا يتحقق أبداً بفحص في النهاية، لأن الفحص يجد الثغرة ولا يسأل لماذا كتبت، أما الدورة الآمنة فتسأل، فإذا تكررت ثغرة الصلاحيات نفسها في ثلاث ميزات، فالإصلاح ليس في الميزة الرابعة، وإنما في المتطلبات أو في مكتبة موحدة للصلاحيات أو في قائمة مراجعة طلبات الدمج. ## ما معنى دورة التطوير الآمنة Secure SDLC؟ **Secure SDLC**، وتكتب أحياناً SSDLC أو S-SDLC، هي دورة حياة التطوير نفسها، بالمراحل نفسها، مع نشاط أمني محدد داخل كل مرحلة، له مخرج يمكن رؤيته ومسؤول معروف. والتشبيه الأقرب هو بناء بيت، فالمهندس الذي يفكر في مخارج الطوارئ وهو يرسم المخطط يضيفها بخط قلم، أما الذي يتذكرها بعد صب الخرسانة فيكسر الجدران، والذي يتذكرها بعد الحريق فقد تأخر كثيراً. والصورة التالية تبين المراحل السبع والنشاط الأمني في كل منها: ![عجلة من سبع مراحل مرقمة: المتطلبات مع مستوى ASVS وحالات الإساءة، والتصميم مع نمذجة التهديدات والمعمارية الآمنة، وكتابة الكود مع البرمجة الآمنة ومراجعة طلبات الدمج والأسرار، والتحقق مع SAST وSCA وDAST واختبار الاختراق، والإصدار مع التوقيع وSBOM وبوابة الموافقة، والتشغيل مع السجلات والتحديثات والاستجابة للحوادث، والإيقاف مع حذف البيانات وإلغاء الصلاحيات والأرشفة، وفي الوسط درع مكتوب عليه Secure SDLC تحيط به الحوكمة والتدريب والقياس](https://arabroot.io/content/images/2026/10/secure-sdlc-01-sdlc-wheel.webp) المراحل نفسها في أي نموذج تطوير، مع نشاط أمني داخل كل مرحلة، والحوكمة والتدريب والقياس تحيط بها كلها وقد يتساءل البعض: ما الفرق إذن بين Secure SDLC وDevSecOps الذي شرحناه في [دليل DevSecOps](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#what-is-devsecops)؟ والإجابة أن DevSecOps هو الجزء الآلي من الدورة، أي الفحوص التي تعمل في خط CI/CD مع كل تغيير، وهو مهم جداً لأنه يجعل الأمن يتكرر دون أن يتذكره أحد، أما Secure SDLC فهو الإطار الأوسع الذي يشمل ما لا تستطيع الأداة فعله: كتابة المتطلبات، والتفكير في التهديدات قبل الكود، ومراجعة الإنسان للمنطق، والموافقة على الإصدار، والاستجابة للحوادث، وإيقاف التطبيق بأمان، والأدوار والتدريب والقياس. فإذا كان عندك DevSecOps دون Secure SDLC فعندك أدوات جيدة تفحص تطبيقاً لم يحدد أحد ما يجب أن يكون عليه، وإذا كان عندك Secure SDLC دون DevSecOps فعندك وثائق جيدة لا يطبقها أحد بانتظام. وفي هذا المقال سوف نحرص على قاعدة واحدة، وهي أن كل نشاط أمني يجب أن يترك مخرجاً يمكن أن يراه غيرك، والسبب أن النشاط الذي لا يترك أثراً لا يمكن قياسه ولا مراجعته ولا إثباته للمدقق، وكما شرحنا في [مصطلحات GRC](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/#evidence) فما لم يوثق فهو لم يحدث في نظر المدقق. ## المراجع Frameworks التي تصف دورة التطوير الآمنة لا تحتاج أن تخترع دورتك من الصفر، فهناك مراجع معروفة تصف الممارسات نفسها بطرق مختلفة، وكل منها مفيد لسبب مختلف، وفيما يلي أهمها باختصار، مع ما تأخذه من كل منها. ### إطار NIST SSDF (SP 800-218) إطار تطوير البرمجيات الآمن **Secure Software Development Framework**، واختصاراً SSDF، تنشره NIST في الوثيقة [SP 800-218](https://csrc.nist.gov/pubs/sp/800/218/final?ref=arabroot.io)، والإصدار النهائي الحالي هو 1.1 المنشور في فبراير 2022، وهو لا يفرض نموذج تطوير معيناً، وإنما يصف ممارسات عالية المستوى تضاف إلى أي نموذج، مرتبة في أربع مجموعات: - **تجهيز المؤسسة Prepare the Organization (PO):** أن يكون الناس والعمليات والأدوات جاهزين، ومنها تعريف متطلبات الأمان PO.1، والأدوار والمسؤوليات PO.2، والأدوات الداعمة PO.3، ومعايير الفحوص الأمنية PO.4، وتأمين بيئات التطوير PO.5. - **حماية البرمجيات Protect the Software (PS):** حماية كل أشكال الكود من الوصول غير المصرح به والعبث PS.1، وتوفير طريقة للتحقق من سلامة النسخة المنشورة PS.2، وأرشفة كل نسخة وحمايتها PS.3. - **إنتاج برمجيات آمنة Produce Well-Secured Software (PW):** من التصميم الذي يلبي المتطلبات PW.1 ومراجعته PW.2، إلى إعادة استخدام البرمجيات الآمنة PW.4، والبرمجة الآمنة PW.5، وإعدادات البناء PW.6، ومراجعة الكود PW.7، واختبار البرنامج التنفيذي PW.8، والإعدادات الآمنة افتراضياً PW.9. - **الاستجابة للثغرات Respond to Vulnerabilities (RV):** اكتشاف الثغرات وتأكيدها باستمرار RV.1، وتقييمها وترتيبها وإصلاحها RV.2، وتحليل أسبابها الجذرية RV.3. ويجدر الانتباه إلى أن NIST نشرت في 17 ديسمبر 2025 [مسودة SP 800-218 Rev. 1](https://csrc.nist.gov/pubs/sp/800/218/r1/ipd?ref=arabroot.io) للإصدار 1.2، وأغلق باب التعليقات عليها في 30 يناير 2026، وتضيف المسودة بحسب سجل التغييرات فيها ممارستين جديدتين، هما PO.6 لخطة تحسين مستمر للعمليات، وPS.4 لضمان أن تحديثات البرنامج موثوقة ومختبرة، مع أمثلة تطبيق جديدة. وحتى وقت كتابة هذا المقال كانت صفحة المشروع في NIST ما زالت تعرض الإصدار 1.2 كمسودة، لذلك اعتمدنا في الجدول أدناه على الإصدار 1.1 النهائي. وما تأخذه من SSDF هو لغة مشتركة مع من يشتري منك البرمجيات، خصوصاً الجهات التي تتعامل مع السوق الأمريكي، ورقم ممارسة لكل نشاط تكتبه في وثائقك. ### ممارسات Microsoft SDL دورة **Security Development Lifecycle** من Microsoft هي من أقدم المراجع في هذا المجال، وتعرض صفحتها الحالية [عشر ممارسات](https://www.microsoft.com/en-us/securityengineering/sdl/practices?ref=arabroot.io): وضع معايير الأمان والمقاييس والحوكمة، واستخدام ميزات ولغات وأطر عمل أمنية مجربة، ومراجعة التصميم الأمنية ونمذجة التهديدات، وتحديد معايير التشفير واستخدامها، وتأمين سلسلة توريد البرمجيات، وتأمين بيئة الهندسة، والاختبار الأمني، وأمن منصة التشغيل، والمراقبة الأمنية والاستجابة، والتدريب الأمني. ولاحظ أن القائمة الحالية مرتبة كممارسات وليست كمراحل، وأنها تعطي سلسلة التوريد وبيئة الهندسة، أي المستودع وخط CI وأجهزة المطورين، ممارسة مستقلة لكل منهما، وهذا ما تأخذه منها: تذكير بأن الأدوات التي تبني بها التطبيق جزء من سطح الهجوم. ### نموذج OWASP SAMM للنضج نموذج **Software Assurance Maturity Model**، واختصاراً SAMM، لا يقول لك ماذا تفعل في كل مرحلة بقدر ما يقيس أين وصلت، فهو في [الإصدار الثاني](https://owaspsamm.org/model/?ref=arabroot.io) مقسم إلى خمس وظائف Business Functions هي الحوكمة Governance والتصميم Design والتنفيذ Implementation والتحقق Verification والتشغيل Operations، وفي كل وظيفة ثلاث ممارسات، فيكون المجموع خمس عشرة ممارسة، ولكل ممارسة ثلاثة مستويات نضج. وما تأخذه من SAMM هو القياس، فبدل أن تقول «أمن تطبيقاتنا جيد» تقول «نحن في المستوى 1 في نمذجة التهديدات، ونريد المستوى 2 خلال سنة»، وسوف نشرح طريقة التقييم بالتفصيل في [مقال نماذج النضج OWASP SAMM](https://arabroot.io/articles/%D9%86%D9%85%D8%A7%D8%B0%D8%AC-%D8%A7%D9%84%D9%86%D8%B6%D8%AC-owasp-samm-%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D8%B3-%D8%A7%D9%85%D9%86-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%83/). ### الضابط 8.25 في ISO/IEC 27001:2022 في ملحق الضوابط Annex A من [ISO/IEC 27001:2022](https://www.iso.org/standard/27001?ref=arabroot.io) ضابط اسمه دورة حياة التطوير الآمن Secure development life cycle برقم 8.25، ويطلب أن تحدد الجهة قواعد للتطوير الآمن للبرمجيات والأنظمة وتطبقها، وحوله ضوابط تفصل أجزاء منه: متطلبات أمان التطبيقات 8.26، ومبادئ المعمارية والهندسة الآمنة 8.27، والبرمجة الآمنة 8.28، والاختبار الأمني أثناء التطوير والقبول 8.29، والتطوير الخارجي 8.30، وفصل بيئات التطوير والاختبار والإنتاج 8.31، وإدارة التغيير 8.32\. والمعيار مثل ضوابط الهيئة يقول ماذا ولا يقول كيف، فإذا كانت جهتك تسعى إلى شهادة ISO 27001 فإن الأنشطة التي في هذا المقال هي الطريقة العملية لإثبات هذه الضوابط. ### الضابط 1-6-3 في ضوابط الهيئة NCA ECC شرحنا في [مقال الضوابط الأساسية ECC](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/#app-security) أين يقع أمن التطبيقات في [ECC-2:2024](https://cdn.nca.gov.sa/api/files/public/upload/29a9e86a-595f-4af9-8db5-88715a458a14%5FECC-2-2024---NCA.pdf?ref=arabroot.io)، والذي يهمنا هنا أن الضابط 1-6-3 يطلب أن تشمل متطلبات الأمن السيبراني لمشاريع تطوير التطبيقات بحد أدنى خمسة بنود: استخدام معايير التطوير الآمن 1-6-3-1، ومصادر مرخصة وموثوقة لأدوات التطوير والمكتبات 1-6-3-2، واختبار التزام التطبيقات بالمتطلبات 1-6-3-3، وأمن التكامل بين التطبيقات 1-6-3-4، ومراجعة الإعدادات والتحصين وحزم التحديثات قبل الإطلاق 1-6-3-5\. ويسبقه الضابط 1-6-1 الذي يطلب أن تكون متطلبات الأمن جزءاً رئيسياً من متطلبات المشاريع التقنية، والضابط 1-5-3 الذي يطلب تقييم المخاطر في المراحل المبكرة من المشاريع وقبل إطلاق الخدمات الجديدة، ثم يأتي المكون الفرعي 2-15 لتطبيقات الويب الخارجية. وتنشر الهيئة في حزمة الأدوات [قالب سياسة دورة حياة التطوير الآمن SSDLC](https://cdn.nca.gov.sa/api/files/public/upload/50068ec0-2f38-4a1e-9150-3409a2e62d55%5FPOLICY%5FSSDLC%5FTemplate%5Far%5Fv0.4.pdf?ref=arabroot.io)، وقد عددنا بقية القوالب في [قسم حزمة الأدوات](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#toolkit) من دليل ضوابط أمن التطبيقات. ### جدول الربط Mapping بين المراحل والمراجع الصورة التالية تبين أي جزء من كل مرجع يغطي كل مرحلة، والربط من عندنا للتوضيح وليس جدولاً رسمياً من أي جهة: ![مصفوفة صفوفها المراحل: كل المراحل، والمتطلبات، والتصميم، وكتابة الكود، والتحقق، والإصدار، والتشغيل، والإيقاف، وأعمدتها NIST SSDF وMicrosoft SDL وOWASP SAMM وISO 27001 وNCA ECC وARC-ASC، وفي كل خانة أرقام الممارسات أو الضوابط المقابلة، مثل PO.1 و8.26 و2-15-1 والنطاق 01 للمتطلبات، وPW.7 وPW.8 و8.29 و1-6-3-3 والنطاق 11 للتحقق، وخانات فارغة لإيقاف التطبيق في Microsoft SDL وARC-ASC](https://arabroot.io/content/images/2026/10/secure-sdlc-03-framework-matrix.webp) المراجع تغطي المراحل نفسها بأسماء وأرقام مختلفة، والربط من عندنا للتوضيح والجدول التالي يفصل الأعمدة التي يحتاجها أغلب القراء في المنطقة، وفي العمود الأخير نطاقات [دليل ضوابط أمن التطبيقات ARC-ASC](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/)، وهو مقترح مستقل من عرب رووت وليس وثيقة رسمية، وكل نطاق فيه رابط إلى ضوابطه: | المرحلة | NIST SSDF 1.1 | ISO 27001:2022 | NCA ECC-2:2024 | نطاقات ARC-ASC | | -------------------------- | ---------------------- | --------------- | ---------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | كل المراحل (الحوكمة) | PO.2 إلى PO.5 | 8.25 | 1-6-1، 1-6-4، 1-10-4 | [01 الحوكمة والمتطلبات](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d01) | | المتطلبات Requirements | PO.1 | 8.26 | 1-5-3-1، 2-15-1 | [01](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d01) | | التصميم Design | PW.1، PW.2 | 8.27 | 1-6-3-4، 2-15-3-2، 2-15-3-5 | [02 التصميم ونمذجة التهديدات](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d02) | | كتابة الكود Implementation | PW.4، PW.5، PS.1 | 8.28 | 1-6-3-1، 1-6-3-2 | [03](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d03) إلى [08](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d08)، و[09 سلسلة التوريد](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d09) | | التحقق Verification | PW.7، PW.8 | 8.29 | 1-6-3-3، 2-11 | [11 الاختبار ومراجعة الكود](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d11) | | الإصدار Release | PS.2، PS.3، PW.6، PW.9 | 8.31، 8.32 | 1-6-3-5، 1-6-2-2 | [10 خط CI/CD وحماية الكود](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d10) | | التشغيل Operations | RV.1، RV.2، RV.3 | 8.8، 8.15، 8.16 | 2-10، 2-12، 2-13، 2-15-3-1 | [12 النشر والحماية أثناء التشغيل](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d12) و[13 السجلات والجاهزية للحوادث](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d13) | | الإيقاف Retirement | PS.3 | 8.10 | لا يوجد بند مخصص، والأقرب 2-1 و2-7 | لا يوجد نطاق مخصص في الإصدار 0.1 | في الجدول أعلاه لاحظ التالي: - مرحلة الإيقاف هي أضعف مرحلة في كل المراجع تقريباً، فلا يوجد لها في ECC بند مخصص، والأقرب إليها إدارة الأصول 2-1 التي تطلب جرداً محدثاً، وحماية البيانات 2-7، وفي ISO 27001 ضابط حذف المعلومات Information deletion برقم 8.10، وفي SAMM جزء من ممارسة الإدارة التشغيلية Operational Management اسمه إيقاف الأنظمة وإدارة القديم منها System Decommissioning / Legacy Management، ولهذا خصصنا لها قسماً كاملاً أدناه. - أرقام ECC في الجدول هي البنود الأقرب لكل مرحلة، وكثير منها عام على كل الأنظمة وليس خاصاً بالتطوير، مثل إدارة الثغرات 2-10 والسجلات 2-12، فلا تقرأ الجدول على أنه تفسير رسمي للضوابط. - عمود ARC-ASC يقابل كل مرحلة بنطاق، والضوابط داخل كل نطاق مربوطة بالأرقام الدقيقة في ECC وCSCC وASVS، وفيها الأدلة المطلوبة لكل ضابط، فإذا كنت تبني دورتك لجهة تخضع لضوابط الهيئة فابدأ من هناك. ## ماذا تفعل في كل مرحلة؟ من المتطلبات Requirements إلى الإيقاف Retirement في الأقسام التالية نأخذ كل مرحلة بالشكل نفسه: الهدف، ثم الأنشطة، ثم المخرجات والأدلة، ثم الأدوات، ثم المسؤول، ثم المقالات التي تشرح التفاصيل. والقاعدة التي تجمعها أن هذا الدليل يقول لك ماذا تفعل ولماذا، ويرسلك إلى المقال الذي يقول كيف، حتى لا نكرر ما شرحناه في مكان آخر. ### المرحلة الأولى: المتطلبات الأمنية Security Requirements الحل البسيط هنا هو أن تكتب في وثيقة المشروع جملة «يجب أن يكون التطبيق آمناً»، وقد شرحنا في [مقال ASVS ومراجعة الكود](https://arabroot.io/articles/%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D9%88%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D9%85%D8%B9-owasp-asvs/#the-problem) لماذا لا تصلح هذه الجملة متطلباً، فهي لا تقول للمطور ما يكتبه، ولا للمختبر ما يختبره، ولا للمدقق ما يطلبه. والهدف من هذه المرحلة أن تتحول كلمة «آمن» إلى قائمة من المتطلبات التي يمكن اختبارها، مثل «كل طلب لكائن يتحقق من أن المستخدم يملكه، ويعيد 404 إذا لم يكن كذلك»، وهي الجملة التي كانت ستمنع الثغرة في مثالنا الأول. - **الأنشطة:** تصنيف التطبيق حسب أهميته Criticality وحساسية بياناته، ثم اختيار مستوى [OWASP ASVS](https://owasp.org/www-project-application-security-verification-standard/?ref=arabroot.io) المناسب له، ثم نقل المتطلبات التي تخص كل ميزة إلى التذكرة كمعايير قبول Acceptance Criteria، وكتابة حالات الإساءة Abuse Cases بجانب حالات الاستخدام، أي «ماذا يحاول المستخدم السيئ أن يفعل بهذه الميزة؟»، كما يشرح [دليل OWASP لحالات الإساءة](https://cheatsheetseries.owasp.org/cheatsheets/Abuse%5FCase%5FCheat%5FSheet.html?ref=arabroot.io). ومعها متطلبات الامتثال والخصوصية، مثل مدة الاحتفاظ بالبيانات ومكان تخزينها. - **المخرجات والأدلة:** وثيقة متطلبات أمان معتمدة لكل تطبيق، ومستوى ASVS مكتوب، وتذاكر فيها معايير قبول أمنية قابلة للاختبار. - **الأدوات:** قالب تذكرة في نظام إدارة المهام فيه حقل للمتطلبات الأمنية، وملف ASVS بصيغة CSV للبحث فيه، وجدول بسيط لتصنيف التطبيقات. - **المسؤول:** مالك المنتج Product Owner أو قائد الفريق التقني Tech Lead يكتب ويقبل، وسفير الأمن Security Champion يقترح المتطلبات، وفريق الأمن AppSec يضع القالب ويحدد المستوى الأدنى لكل درجة. والتفاصيل في [من المتطلب إلى قصة المستخدم والاختبار](https://arabroot.io/articles/%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D9%88%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D9%85%D8%B9-owasp-asvs/#requirements-to-tests)، وفي ضوابط [النطاق 01](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d01) من دليل ضوابط أمن التطبيقات، وإذا كان التطبيق واجهة API أو مساعداً يعمل بنموذج لغة فأضف متطلبات [OWASP API Security Top 10](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D9%88%D8%A7%D8%AC%D9%87%D8%A7%D8%AA-api-%D9%85%D8%B9-owasp-api-security-top-10/) و[قائمة LLM Top 10](https://arabroot.io/articles/owasp-top-10-%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%86%D9%85%D8%A7%D8%B0%D8%AC-%D8%A7%D9%84%D9%84%D8%BA%D8%A9-llm/#checklist). ### المرحلة الثانية: التصميم الآمن ونمذجة التهديدات Threat Modeling هنا تولد أغلى الأخطاء كما رأينا في الرسم، وفئة [التصميم غير الآمن Insecure Design](https://arabroot.io/articles/owasp-top-10-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#a06) في OWASP Top 10 موجودة لهذا السبب، فهي ثغرات لا يصلحها كود أفضل، لأن المشكلة ليست في سطر كتب خطأ، وإنما في سطر لم يكتب أصلاً. والهدف من هذه المرحلة أن تسأل «ما الذي قد يسوء؟» قبل أن يصبح الجواب مكلفاً. - **الأنشطة:** رسم مخطط تدفق البيانات DFD وتحديد حدود الثقة، ثم نمذجة التهديدات بأسئلتها الأربعة وطريقة STRIDE، ثم اتخاذ قرار لكل تهديد: تخفيف أو إزالة أو نقل أو قبول. ومعها مراجعة المعمارية: فصل الطبقات والمستويات Tiers and Layers، وأين تتم المصادقة والصلاحيات، وكيف تتكامل مع الأنظمة الأخرى، واختيار خدمات أمنية موحدة بدل أن تكتب كل ميزة صلاحياتها بنفسها، مثل مزود هوية مركزي، واختيار معايير التشفير. - **المخرجات والأدلة:** نموذج تهديدات مكتوب لكل ميزة عالية الخطورة، فيه التهديدات والقرار لكل منها، وسجل قرارات معمارية ADR للقرارات الأمنية، ومراجعة تصميم موقعة مقابل المتطلبات. - **الأدوات:** سبورة وورقة في أغلب الحالات، وأدوات مثل OWASP Threat Dragon وpytm عندما تريد أن يعيش النموذج مع الكود. - **المسؤول:** المطورون الذين سيبنون الميزة يرسمون ويسألون، وسفير الأمن يدير الجلسة، وفريق الأمن يراجع نماذج التطبيقات الأعلى أهمية. والتفاصيل في [نمذجة التهديدات Threat Modeling للمبتدئين](https://arabroot.io/articles/%D9%86%D9%85%D8%B0%D8%AC%D8%A9-%D8%A7%D9%84%D8%AA%D9%87%D8%AF%D9%8A%D8%AF%D8%A7%D8%AA-threat-modeling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#what-is) مع [قالب جاهز للنسخ](https://arabroot.io/articles/%D9%86%D9%85%D8%B0%D8%AC%D8%A9-%D8%A7%D9%84%D8%AA%D9%87%D8%AF%D9%8A%D8%AF%D8%A7%D8%AA-threat-modeling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#template)، وفي [المعمارية متعددة الطبقات Tiers وLayers](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF%D8%A9-%D8%A7%D9%84%D8%B7%D8%A8%D9%82%D8%A7%D8%AA-tiers-%D9%88-layers/) للفرق بين فصل المستويات الذي يطلبه البند 2-15-3-2 وتقسيم الكود إلى طبقات، وفي [جدول القرار في التشفير للمطورين](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B4%D9%81%D9%8A%D8%B1-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D9%87%D8%A7%D8%B4-%D9%88%D9%83%D9%84%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D9%88%D8%B1-%D9%88%D8%A7%D9%84%D9%85%D9%81%D8%A7%D8%AA%D9%8A%D8%AD/#decision-table)، وفي ضوابط [النطاق 02](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d02). ### المرحلة الثالثة: كتابة الكود الآمن Secure Implementation هذه المرحلة هي التي يظنها الكثيرون كل الأمن، وهي جزء مهم منه، ولكنها تعتمد على ما قبلها، فالمطور لا يستطيع أن يطبق متطلباً لم يكتب ولا أن يحمي حداً للثقة لم يرسم. والهدف منها أن يكون الطريق الآمن هو الطريق الأسهل للمطور، وأن يمر كل سطر على عين ثانية قبل الدمج. - **الأنشطة:** معيار برمجة آمنة Secure Coding Standard مكتوب لكل لغة وإطار عمل يستخدمه الفريق، ومراجعة الكود الأمنية Security Code Review في كل طلب دمج بقائمة قصيرة، ومنع الأسرار من دخول المستودع، ومراجعة كل مكتبة جديدة قبل إضافتها مع ملفات القفل Lock Files، وحماية المستودع نفسه بحماية الفرع الرئيسي Branch Protection والمراجعة الإلزامية. ومعها فروع قصيرة تدمج يومياً، لأن طلب الدمج الصغير يراجع فعلاً، أما طلب الدمج الذي فيه ثلاثة آلاف سطر فيوافق عليه المراجع وهو يتمنى الخير. - **المخرجات والأدلة:** المعيار المكتوب، وطلبات دمج عليها موافقة مراجع غير الكاتب، وإعدادات حماية الفرع، ونتيجة فحص الأسرار على كل commit. - **الأدوات:** قواعد المحرر، وGit Hook لفحص الأسرار، وقالب طلب الدمج فيه القائمة الأمنية، وأداة تحديث الاعتماديات آلياً. - **المسؤول:** المطورون يكتبون ويراجعون بعضهم، وسفير الأمن يراجع التغييرات الحساسة مثل المصادقة والصلاحيات والتشفير، وفريق الأمن يكتب المعيار ويحدثه. والتفاصيل في [البرمجة الآمنة Secure Coding للمطورين](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D8%A9-secure-coding-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86/) مع [قائمة لكل لغة](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D8%A9-secure-coding-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86/#checklists)، وفي [قائمة المراجعة الأمنية لكل طلب دمج](https://arabroot.io/articles/%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D9%88%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D9%85%D8%B9-owasp-asvs/#pr-checklist)، وفي [منع تسرب الأسرار من البداية](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D8%B3%D8%B1%D8%A7%D8%B1-%D8%A7%D9%84%D9%85%D8%B3%D8%B1%D8%A8%D8%A9-%D9%85%D8%B9-gitleaks-%D9%88-trufflehog/#prevention)، وفي [ملفات القفل وتثبيت الإصدارات](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#lockfiles)، وفي [التطوير على الفرع الرئيسي Trunk-Based](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B7%D9%88%D9%8A%D8%B1-%D8%B9%D9%84%D9%89-%D8%A7%D9%84%D9%81%D8%B1%D8%B9-%D8%A7%D9%84%D8%B1%D8%A6%D9%8A%D8%B3%D9%8A-trunk-based/)، وفي ضوابط النطاقات من [03](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d03) إلى [08](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d08). وإذا أردت أن ترى الثغرات التي يمنعها هذا كله وهي تعمل، فارجع إلى [ثغرات الويب بالتجربة](https://arabroot.io/articles/%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%88%D9%8A%D8%A8-%D8%A8%D8%A7%D9%84%D8%AA%D8%AC%D8%B1%D8%A8%D8%A9-sql-injection-%D9%88-xss-%D9%88-ssrf/). ### المرحلة الرابعة: التحقق والاختبار الأمني Security Testing الهدف من هذه المرحلة سؤالان مختلفان، والكثير من الفرق تجيب عن الأول وتنسى الثاني: هل في التطبيق ثغرات معروفة الشكل؟ وهل يلبي التطبيق المتطلبات التي كتبناها في المرحلة الأولى؟ والسؤال الأول تجيب عنه الأدوات، أما الثاني فهو ما يطلبه البند 1-6-3-3 بالضبط، ولا تجيب عنه أداة فحص عامة، وإنما اختبارات مكتوبة من المتطلبات نفسها. - **الأنشطة:** الفحص الثابت للكود SAST، وفحص الاعتماديات SCA، وفحص ال Docker Image والبنية ككود IaC، والفحص أثناء التشغيل DAST على بيئة المعاينة، واختبارات أمنية مكتوبة من المتطلبات، مثل اختبار يتأكد أن المستخدم «أ» يحصل على 404 عند طلب فاتورة المستخدم «ب»، واختبار الأحمال للميزات المعرضة للاستهلاك غير المحدود، واختبار الاختراق Penetration Testing للتطبيقات المهمة قبل الإطلاق الكبير ودورياً بعده. - **المخرجات والأدلة:** تقارير الفحوص محفوظة مع كل بناء، ونتائج الاختبارات الأمنية مربوطة بأرقام المتطلبات، وتقرير اختبار الاختراق مع خطة إصلاح، وقرار مكتوب لكل نتيجة لم تصلح. - **الأدوات:** Semgrep وOSV-Scanner وTrivy وZAP وPlaywright، وكل منها مشروح في مقاله. - **المسؤول:** خط CI يشغل الفحوص آلياً، والمطورون يصلحون النتائج في طلباتهم، وسفير الأمن يفرز النتائج ويزيل الإنذارات الخاطئة، وفريق الأمن يحدد القواعد ويدير اختبار الاختراق. ولا نكرر هنا مكان كل فحص في الخط، فقد رسمناه في [أين يعمل كل فحص في خط CI/CD](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#pipeline)، والتفاصيل في [SAST](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D8%A7%D9%84%D8%AB%D8%A7%D8%A8%D8%AA-sast-%D9%85%D8%B9-semgrep-%D9%88-sonarqube/) و[SCA](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF%D9%8A%D8%A7%D8%AA-sca-%D9%85%D8%B9-osv-scanner-%D9%88-dependency-track/) و[فحص الحاويات والبنية ككود](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AD%D8%A7%D9%88%D9%8A%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%8A%D8%A9-%D9%83%D9%83%D9%88%D8%AF-%D9%85%D8%B9-trivy/) و[DAST](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82-%D8%A7%D8%AB%D9%86%D8%A7%D8%A1-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-dast-%D9%85%D8%B9-zap/)، وفي [أين يعمل كل اختبار في خط CI](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/#tests-in-ci) و[اختبار الأحمال داخل خط CI/CD](https://arabroot.io/articles/%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1-%D8%A7%D9%84%D8%A7%D8%AD%D9%85%D8%A7%D9%84-%D9%88%D8%A7%D9%84%D8%B6%D8%BA%D8%B7-load-%D9%88-stress-testing-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#ci-cd)، وطريقة ترتيب النتائج في [فرز النتائج Triage](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#triage)، وضوابط [النطاق 11](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d11). ### المرحلة الخامسة: الإصدار والنشر الآمن Secure Release الحل البسيط في هذه المرحلة هو أن ينشر المطور من جهازه، أو أن يبني خط CI نسخة جديدة لكل بيئة، وقد شرحنا في [طرق نشر التطبيقات من FTP إلى GitOps](https://arabroot.io/articles/%D8%B7%D8%B1%D9%82-%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%85%D9%86-ftp-%D8%A7%D9%84%D9%89-gitops/) كيف تطورت هذه الطرق ولماذا. والهدف الأمني من هذه المرحلة أن تكون النسخة التي تعمل في الإنتاج هي نفسها التي فحصت واختبرت، دون تغيير، وأن تستطيع إثبات ذلك، وأن يمر النشر على قرار مكتوب وليس على مزاج من يملك الصلاحية. - **الأنشطة:** بناء ال Docker Image مرة واحدة ونقلها كما هي بين البيئات، وكتابة قائمة مكونات SBOM لكل نسخة، وتوقيع النسخة Signing بأداة مثل [Sigstore cosign](https://docs.sigstore.dev/cosign/signing/overview/?ref=arabroot.io)، وتسجيل مصدر البناء Provenance كما يصفه [إطار SLSA](https://slsa.dev/spec/v1.0/provenance?ref=arabroot.io)، وبوابة قبل النشر تطبق سياسة مكتوبة مثل «لا تنشر نسخة فيها ثغرة Critical لها إصلاح»، ومراجعة الإعدادات والتحصين قبل الإطلاق كما يطلب البند 1-6-3-5، وموافقة على النشر إلى الإنتاج لمن له الصلاحية فقط، وأرشفة كل نسخة منشورة كما تطلب ممارسة PS.3 في SSDF، لأنك سوف تحتاج أن تعرف بعد سنة ما الذي كان يعمل يوم الحادثة. - **المخرجات والأدلة:** SBOM وتوقيع لكل نسخة، وسجل الموافقة على النشر، وقائمة مراجعة الإعدادات، وملاحظات الإصدار Release Notes التي تذكر الإصلاحات الأمنية. - **الأدوات:** Container Registry يحفظ ال Images والتوقيعات، وبيئات في نظام CI لها مراجعون إلزاميون، ومستودع GitOps للإعداد. - **المسؤول:** فريق التشغيل Ops أو SRE يملك الخط وصلاحيات النشر، وقائد الفريق التقني يوافق، وفريق الأمن يكتب سياسة البوابة. والتفاصيل في [ابن ال Docker Image مرة واحدة](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D8%A7%D9%8A%D9%86%D8%A9-%D8%A7%D9%84%D9%85%D9%8A%D8%B2%D8%A7%D8%AA-%D9%88-gitops-%D9%84%D9%84%D9%81%D8%B1%D9%82/#build-once) و[الإصدارات وترحيل قواعد البيانات بين البيئات](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D8%A7%D9%8A%D9%86%D8%A9-%D8%A7%D9%84%D9%85%D9%8A%D8%B2%D8%A7%D8%AA-%D9%88-gitops-%D9%84%D9%84%D9%81%D8%B1%D9%82/#releases)، وفي [قائمة SBOM](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#sbom) و[التوقيع](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#signing) و[SLSA](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#slsa) في مقال سلسلة التوريد، وفي ضوابط [النطاق 10](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d10). ### المرحلة السادسة: التشغيل والمراقبة والاستجابة Operations and Response هذه أطول مرحلة في عمر التطبيق، والخطأ الشائع أن يعتبر الفريق أن الأمن انتهى يوم الإطلاق، بينما الثغرات الجديدة تنشر كل يوم في مكتبات لم تتغير، والمخترق لا يبدأ عمله إلا بعد أن يصبح التطبيق متاحاً. والهدف من هذه المرحلة ثلاثة أشياء: أن تحمي التطبيق وهو يعمل، وأن ترى ما يحدث فيه، وأن تستجيب بسرعة عندما يحدث شيء، ومنها البلاغات التي تصلك من خارج الفريق. - **الأنشطة:** طبقات الحماية أمام التطبيق مثل جدار حماية تطبيقات الويب WAF الذي يطلبه البند 2-15-3-1 والحد من معدل الطلبات Rate Limiting وترويسات الأمان، وتحديث النظام والحزم Patching في مواعيد مكتوبة، وإعادة فحص ال Images التي تعمل في الإنتاج دورياً، وتسجيل الأحداث الأمنية Security Events وجمعها مركزياً مع تنبيهات، وسجل تدقيق Audit Trail لعمليات العمل الحساسة، وخطة استجابة للحوادث Incident Response مجربة، وتحليل السبب الجذري لكل ثغرة مهمة كما تطلب ممارسة RV.3، وسياسة للإفصاح عن الثغرات Vulnerability Disclosure تقول للباحث الخارجي أين يبلغ. - **المخرجات والأدلة:** السجلات محفوظة للمدة المطلوبة، وتذاكر الثغرات مع تاريخ الاكتشاف والإصلاح، وتقارير الحوادث والدروس المستفادة، وملف SECURITY.md في المستودع وملف security.txt على الموقع. - **الأدوات:** Reverse Proxy مع WAF، وأداة جمع السجلات المركزي، وأداة تجمع نتائج الفحوص ومواعيد إصلاحها مثل DefectDojo. - **المسؤول:** فريق التشغيل يملك المنصة والمراقبة، والمطورون يصلحون ثغرات كودهم، وفريق الأمن يدير الاستجابة للحوادث ويستقبل البلاغات. أما الإفصاح عن الثغرات فهو أبسط مما يظن الكثيرون، فملف `SECURITY.md` في المستودع يقول، بحسب [وثائق GitHub](https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository?ref=arabroot.io)، الإصدارات التي ما زالت تتلقى إصلاحات أمنية وطريقة الإبلاغ عن الثغرة، وملف `security.txt` الذي يصفه [المعيار RFC 9116](https://www.rfc-editor.org/rfc/rfc9116?ref=arabroot.io) يوضع في المسار `/.well-known/security.txt` على موقعك، وفيه حقلان إلزاميان هما `Contact` لطريقة التواصل و`Expires` لتاريخ انتهاء صلاحية الملف، ويشرح [دليل OWASP للإفصاح عن الثغرات](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability%5FDisclosure%5FCheat%5FSheet.html?ref=arabroot.io) ما يحتاجه الباحث ومالك التطبيق، وقد شرحنا في [مقال حوكمة المشاريع مفتوحة المصدر](https://arabroot.io/articles/%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D8%A7%D9%84%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1-%D9%88%D8%A7%D9%84%D9%85%D8%B3%D8%A7%D9%87%D9%85%D8%A9-%D9%81%D9%8A%D9%87%D8%A7/#security-reports) لماذا لا تفتح للثغرة بلاغاً عاماً. والتفاصيل في [جدار حماية تطبيقات الويب](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%A7%D9%84%D9%88%D9%8A%D8%A8-%D8%B9%D9%84%D9%89-%D9%85%D8%B3%D8%AA%D9%88%D9%89-http/#waf) و[ترويسات الأمان](https://arabroot.io/articles/%D8%AA%D8%B1%D9%88%D9%8A%D8%B3%D8%A7%D8%AA-%D8%A7%D9%84%D8%A3%D9%85%D8%A7%D9%86-hsts-%D9%88-csp/)، وفي [ماذا تسجل في كل حدث](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AC%D9%84%D8%A7%D8%AA-logging-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D9%88%D9%85%D8%AF%D9%8A%D8%B1%D9%8A-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/#what-to-log) و[سجل التدقيق Audit Trail](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/)، وفي [مواعيد الإصلاح SLA](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#sla)، وفي [الاستعداد قبل أن تقع الحادثة](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/#prepare) و[نموذج ملاحظات الحادثة](https://arabroot.io/articles/%D8%A7%D8%B3%D8%AA%D9%83%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D8%AE%D8%B7%D8%A7%D8%A1-%D9%88%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%A7%D9%84%D8%A7%D8%AF%D8%A7%D8%A1-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/#runbook)، وفي ضوابط [النطاق 12](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d12) و[النطاق 13](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#d13). ### المرحلة السابعة: إيقاف التطبيق بأمان Decommissioning هذه المرحلة ينساها الجميع، والطريقة البسيطة التي تتبعها أغلب الفرق هي إيقاف الخدمة ونسيانها، فيبقى السيرفر يعمل بلا تحديثات لأن أحداً لا يجرؤ على حذفه، وتبقى قاعدة البيانات بنسخها الاحتياطية وفيها بيانات عملاء، ويبقى مفتاح API صالحاً في خدمة خارجية، ويبقى سجل DNS يشير إلى خدمة سحابية حذفت، وهذا الأخير بالتحديد يسمح لمن يحجز الاسم نفسه في الخدمة السحابية أن يستولي على النطاق الفرعي Subdomain Takeover كما تشرح [وثائق Microsoft عن سجلات DNS المعلقة](https://learn.microsoft.com/en-us/azure/security/fundamentals/subdomain-takeover?ref=arabroot.io). والهدف من هذه المرحلة أن يختفي التطبيق فعلاً، وأن لا يترك خلفه بيانات أو صلاحيات أو أسماء يستطيع أحد استخدامها. - **الأنشطة:** قرار مكتوب بالإيقاف مع تاريخ، وإبلاغ المستخدمين وترحيلهم، ثم حذف البيانات أو أرشفتها حسب مدة الاحتفاظ المطلوبة نظاماً، وتطهير الوسائط Media Sanitization التي حملت بيانات حساسة بحسب [NIST SP 800-88 Rev. 2](https://csrc.nist.gov/pubs/sp/800/88/r2/final?ref=arabroot.io) الصادرة في سبتمبر 2025، وإلغاء كل الأسرار والمفاتيح والشهادات وحسابات الخدمة التي كان يستخدمها، وحذف سجلات DNS وقواعد الجدار الناري، وإزالته من جرد الأصول الذي يطلبه المكون 2-1، والإبقاء على السجلات المطلوبة للمدة التي تفرضها الأنظمة، وأرشفة المستودع. - **المخرجات والأدلة:** قرار الإيقاف، وسجل الحذف أو الأرشفة مع التاريخ ومن نفذه، وقائمة الأسرار التي ألغيت، وتحديث جرد الأصول. - **الأدوات:** قائمة تحقق Checklist ثابتة لإيقاف أي تطبيق، وجرد الأصول، ونظام إدارة الأسرار الذي يعرض كل سر يملكه التطبيق. - **المسؤول:** مالك المنتج يقرر، وفريق التشغيل ينفذ، والمسؤول عن البيانات أو الخصوصية يوافق على الحذف أو الأرشفة. ولاحظ أن أرشفة المستودع في GitHub، بحسب [وثائقها](https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories?ref=arabroot.io)، تجعله للقراءة فقط لكل المستخدمين، وتنصح الوثائق قبل الأرشفة بإغلاق البلاغات وطلبات الدمج المفتوحة وتحديث ملف README ووصف المستودع، ويمكن إلغاء الأرشفة لاحقاً، فاكتب في README أن المشروع متوقف وتاريخ ذلك، حتى لا يأخذ أحد الكود ويستخدمه في مشروع جديد وهو يظن أنه مدعوم. والأرشفة لا تحذف الأسرار التي في تاريخ Git، فإذا كان فيه سر قديم فقم بإلغائه قبل الأرشفة كما شرحنا في [خطة الاستجابة لتسرب مفتاح](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D8%B3%D8%B1%D8%A7%D8%B1-%D8%A7%D9%84%D9%85%D8%B3%D8%B1%D8%A8%D8%A9-%D9%85%D8%B9-gitleaks-%D9%88-trufflehog/#leak-response). ## الأدلة Evidence التي تتركها كل مرحلة إذا طبقت ما سبق فسوف تجد أن كل مرحلة تترك ملفاً أو سجلاً، وهذه الملفات هي نفسها ما يطلبه المدقق، وما يحتاجه الفريق بعد سنة ليعرف لماذا اتخذ قراراً معيناً. والصورة التالية تبين ذلك: ![سبع مراحل مرقمة في صف واحد، وتحت كل مرحلة وثيقة: المتطلبات الأمنية ومستوى ASVS، ونموذج التهديدات ومراجعة التصميم، وطلبات الدمج المراجعة ومعيار البرمجة، وتقارير الفحص والاختبار، وSBOM والتوقيع والموافقة على الإصدار، والتنبيهات والحوادث والإصلاحات، وسجل الحذف والمفاتيح الملغاة، وكلها تنزل إلى صندوق واحد للأدلة لكل إصدار في مجلد docs/security وملفات خط CI وروابط التذاكر، ومنه سهم إلى المدقق مع ECC 1-6-3-3 وISO 27001 8.25، وسهم إلى الفريق](https://arabroot.io/content/images/2026/10/secure-sdlc-04-evidence-pipeline.webp) كل مرحلة تترك دليلاً، والأدلة تعيش مع الكود وخط CI وليس في مجلد يجمع قبل زيارة المدقق والطريقة العملية لجمعها أن تضع في كل مستودع مجلداً مثل `docs/security/` فيه وثيقة المتطلبات ونموذج التهديدات وسجل القرارات، وأن يحفظ خط CI تقارير الفحوص وSBOM مع كل بناء، وأن تربط التذاكر بطلبات الدمج. وبهذا الشكل يصبح سؤال المدقق «أرني دليلاً على اختبار الالتزام بالمتطلبات» رابطاً ترسله، وليس أسبوعاً من جمع لقطات الشاشة. ولا تقم بكتابة الأدلة بعد الحدث لتمر من التدقيق، والسبب أن الدليل الذي يكتب بأثر رجعي لا يحمي أحداً، ويكتشفه المدقق الجيد من التواريخ. ## من يفعل ماذا؟ الأدوار Roles وجدول RACI أكبر سبب لفشل Secure SDLC في الواقع ليس نقص الأدوات، وإنما أن لا أحد يملك النشاط، فنمذجة التهديدات «مهمة الجميع» تعني أنها مهمة لا أحد. والصورة التالية تبين الأدوار المعتادة حول التطبيق الواحد: ![تطبيق واحد في الوسط تحيط به ست بطاقات: مالك المنتج وقائد الفريق يقبلان المخاطرة ويضعان المتطلبات في التذاكر، والقيادة وفريق الحوكمة للسياسات والاستثناءات والميزانية وأدلة التدقيق، والمطورون يكتبون ويراجعون الكود ويصلحون النتائج، وفريق التشغيل للتحصين والتحديثات والسجلات والاستجابة للحوادث، وسفير الأمن واحد في كل فريق بدوام جزئي لنمذجة التهديدات ومساعدة المراجعة، وفريق أمن التطبيقات للمعايير والأدوات والتدريب واختبار الاختراق](https://arabroot.io/content/images/2026/10/secure-sdlc-05-roles.webp) الفريق الذي يكتب الكود يملك أمانه، وفريق الأمن يضع القواعد ويساعد، وسفير الأمن هو الجسر بينهما - **المطورون Developers:** يكتبون الكود ويراجعونه ويصلحون النتائج، وهم أصحاب أمان كودهم، والسبب أنهم الوحيدون الذين يستطيعون إصلاحه بسرعة. - **سفير الأمن Security Champion:** مطور من الفريق نفسه، يأخذ جزءاً معترفاً به من وقته للأمن، فيدير جلسات نمذجة التهديدات ويراجع التغييرات الحساسة ويفرز نتائج الأدوات، ويرجع إلى فريق الأمن في الحالات الصعبة، ويشرح [دليل OWASP لسفراء الأمن](https://securitychampions.owasp.org/?ref=arabroot.io) كيف تبني هذا البرنامج، وقد ذكرناه في [دليل DevSecOps](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#champions) و[برنامج التوعية](https://arabroot.io/articles/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D8%AC-%D8%A7%D9%84%D8%AA%D9%88%D8%B9%D9%8A%D8%A9-%D8%A8%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/#culture). - **فريق أمن التطبيقات AppSec:** يكتب المعايير ويختار الأدوات ويضبط قواعدها ويدرب الفرق ويدير اختبار الاختراق ويساعد في الحالات الصعبة، ولا يراجع كل طلب دمج بنفسه، لأن عدده لا يسمح بذلك في أي شركة. - **فريق التشغيل Ops أو SRE:** يملك المنصة وخط النشر والتحديثات والمراقبة، ويقود الجانب التقني من الاستجابة للحوادث. - **مالك المنتج أو قائد الفريق التقني:** يضع المتطلبات الأمنية في الخطة ويعطيها وقتاً، ويقبل المخاطرة المتبقية Residual Risk باسمه عندما يقرر الفريق عدم إصلاح شيء. - **القيادة وفريق الحوكمة GRC:** يعتمدون السياسة ويوافقون على الاستثناءات ويوفرون الميزانية، ويتابعون الأدلة والمقاييس. والجدول التالي مقترح لتوزيع المسؤولية بطريقة RACI، أي من ينفذ Responsible، ومن يحاسب على النتيجة Accountable وهو شخص واحد فقط في كل صف، ومن يستشار Consulted، ومن يبلغ Informed. وعدله بحسب حجم فريقك، فالمهم أن يكون في كل صف حرف A واحد باسم شخص حقيقي: | النشاط | المطورون | سفير الأمن | فريق AppSec | التشغيل Ops | مالك المنتج أو قائد الفريق | | ---------------------------------- | -------- | ---------- | ----------- | ----------- | -------------------------- | | المتطلبات الأمنية ومستوى ASVS | C | R | C | I | A | | نمذجة التهديدات | R | R | C | C | A | | البرمجة الآمنة ومراجعة طلبات الدمج | R | C | I | I | A | | الفحوص الآلية في خط CI | R | R | A | C | I | | اختبار الاختراق | C | C | A | C | I | | الموافقة على الإصدار والنشر | C | C | C | R | A | | التحديثات والمراقبة | C | I | C | A | I | | الاستجابة للحوادث | R | R | A | R | I | | استقبال بلاغات الثغرات وإصلاحها | R | C | A | C | I | | إيقاف التطبيق | C | I | C | R | A | في الجدول أعلاه لاحظ أن فريق AppSec هو المحاسب على الأدوات والاختبار والحوادث، ولكنه ليس المحاسب على أمان الكود نفسه، فهذا يبقى عند الفريق الذي يملك المنتج، والسبب أن الجهة التي تجعل فريق الأمن مسؤولاً عن كل ثغرة في كل تطبيق تعطي المطورين رسالة أن الأمن ليس مسؤوليتهم، وتعود إلى مشكلة البوابة الأخيرة التي بدأنا بها. ## من فريق من ثلاثة أشخاص إلى شركة من خمسين قد يبدو كل ما سبق مناسباً لشركة كبيرة فقط، وقد يتساءل البعض: نحن ثلاثة مطورين، فمن سيكون فريق AppSec وسفير الأمن ومالك المنتج؟ والإجابة أن الأدوار هي قبعات وليست وظائف، والشخص الواحد يلبس أكثر من قبعة، والمهم أن تعرف أي قبعة يلبس في كل نشاط. وقد شرحنا في [خارطة CTO لشركة SaaS ناشئة](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/#security) ما يتغير في الأمن مع نمو الفريق، وفيما يلي ما يعنيه ذلك لدورة التطوير. ### فريق صغير من ثلاثة أشخاص - **المتطلبات:** مستوى ASVS 1 للتطبيق كله، وحقل «المتطلبات الأمنية» في قالب التذكرة، يملأ للميزات التي تلمس المصادقة أو الصلاحيات أو المدفوعات أو رفع الملفات فقط. - **التصميم:** ثلاثون دقيقة أمام السبورة للميزة الخطرة، بالأسئلة الأربعة لنمذجة التهديدات، وصورة للسبورة في التذكرة، وهذا يكفي. - **الكود:** مراجعة إلزامية من شخص ثان لكل طلب دمج، وقائمة المراجعة الأمنية في قالب طلب الدمج، وحماية الفرع الرئيسي. - **التحقق:** فحص الأسرار وSCA وSAST في خط CI بإعداداتها الافتراضية، واختبار آلي واحد على الأقل للصلاحيات بين المستخدمين. - **الإصدار والتشغيل:** Image واحدة تنقل بين البيئات، وتحديثات آلية للنظام، وسجلات مركزية بسيطة، وملف SECURITY.md، وورقة واحدة تقول ماذا تفعل إذا تسرب مفتاح أو اخترق السيرفر. - **الأدوار:** أحد الثلاثة هو سفير الأمن، والشخص الذي يملك القرار التقني هو المحاسب، ولا يوجد فريق AppSec، فتعوضه المراجع المفتوحة واختبار اختراق خارجي عندما يطلبه أول عميل كبير. ### شركة من خمسين شخصاً - **الحوكمة:** سياسة دورة تطوير آمن معتمدة، يمكن أن تبدأ من قالب الهيئة، وتصنيف كل تطبيق بدرجة أهمية تحدد ما يلزمه من الأنشطة، وسجل استثناءات Exceptions Register يوقع فيه من يقبل المخاطرة، وتقييم SAMM مرة في السنة. - **الأدوار:** شخص أو شخصان متفرغان لأمن التطبيقات، وسفير أمن في كل فريق منتج له وقت معترف به، ولقاء أسبوعي قصير للسفراء. - **التصميم:** نمذجة التهديدات إلزامية للميزات عالية الخطورة وللتطبيقات في الدرجة الأعلى، ومراجعة من فريق الأمن لنماذجها. - **التحقق:** الفحوص كلها في الخط بقواعد مضبوطة وخط أساسي Baseline، وDAST على بيئة المعاينة، واختبار اختراق سنوي للتطبيقات المهمة، ومكان واحد تجمع فيه النتائج ومواعيد إصلاحها. - **الإصدار والتشغيل:** توقيع ال Images وSBOM للتطبيقات المهمة، وبوابة نشر بسياسة مكتوبة، وفصل صلاحيات النشر إلى الإنتاج، وخطة استجابة للحوادث مجربة مرة على الأقل في السنة، وقائمة تحقق لإيقاف التطبيقات. - **القياس:** لوحة واحدة بالمقاييس التي سوف نذكرها أدناه، تراجع شهرياً. ولاحظ أن الفرق بين الحالتين ليس في وجود المراحل، فالمراحل نفسها موجودة في الحالتين، وإنما في عمق النشاط داخل كل مرحلة، وفي عدد الأشخاص الذين يحملون الأدوار، وفي كمية الأدلة المكتوبة. وهذا ما يقيسه SAMM بمستوياته الثلاثة، وما يحدده دليل ضوابط أمن التطبيقات بالدرجات Tiers التي شرحناها في [كيف تستخدم الدليل بحسب أهمية التطبيق](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/#how-to-use). ## خطة أول تسعين يوماً Adoption Plan شرحنا في [دليل DevSecOps](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/#adoption) خطة لإدخال الأدوات إلى خط CI على مراحل، أما الخطة هنا فهي للدورة كلها، أي للناس والوثائق والقرارات بجانب الأدوات، والصورة التالية تلخصها: ![ثلاث مراحل مرقمة على خط زمني: الأيام 1 إلى 30 لمعرفة ما تملكه، فيها جرد التطبيقات وتصنيفها، ومالك لكل تطبيق، ومستوى ASVS لكل تطبيق، وملفا SECURITY.md وsecurity.txt، وفحص الأسرار وSCA في خط CI، والأيام 31 إلى 60 للتصميم والكود، فيها نمذجة تهديدات لأهم تطبيق، والمتطلبات الأمنية في التذاكر، وقائمة مراجعة طلبات الدمج، وSAST مع خط أساسي، ومنع الثغرات الحرجة الجديدة، والأيام 61 إلى 90 للإصدار والتشغيل، فيها نسخ موقعة مع SBOM، وDAST على بيئة الاختبار، والأحداث الأمنية والتنبيهات، ودليل الاستجابة للحوادث مع تمرين، وأول المقاييس وتقييم SAMM، وتحتها لقاء أسبوعي لسفراء الأمن](https://arabroot.io/content/images/2026/10/secure-sdlc-06-ninety-days.webp) ابدأ بالجرد والمسؤولين، ثم انقل الأمن إلى التصميم والكود، ثم إلى الإصدار والتشغيل 1. **الأيام 1 إلى 30، اعرف ما تملكه:** قم بجرد كل التطبيقات وواجهات API، وصنف كل منها بدرجة أهمية، واكتب لكل تطبيق مالكاً باسمه، واختر مستوى ASVS لكل درجة، وسم سفيراً للأمن في كل فريق، وأضف ملف SECURITY.md لكل مستودع وملف security.txt للموقع، وشغل فحص الأسرار بوضع المنع وفحص الاعتماديات بوضع التنبيه فقط. وفي نهاية الشهر سوف تعرف لأول مرة كم تطبيقاً عندك، وهذه وحدها نتيجة مهمة. 2. **الأيام 31 إلى 60، التصميم والكود:** نفذ نمذجة تهديدات لأهم تطبيق، ولكل ميزة جديدة عالية الخطورة، وأضف حقل المتطلبات الأمنية إلى قالب التذكرة، وقائمة المراجعة الأمنية إلى قالب طلب الدمج، وشغل SAST مع خط أساسي يمنع الجديد فقط، وأضف بوابة تمنع نشر ثغرة Critical جديدة أو ثغرة في قائمة KEV. 3. **الأيام 61 إلى 90، الإصدار والتشغيل:** وقع نسخ التطبيق الأهم واكتب لها SBOM، وشغل DAST على بيئة المعاينة، وتأكد أن الأحداث الأمنية تسجل وتصل تنبيهاتها إلى شخص حقيقي، واكتب دليل الاستجابة للحوادث ونفذ تمريناً على الطاولة Tabletop Exercise لمدة ساعة، وطبق قائمة تحقق الإيقاف على تطبيق قديم واحد، ثم اجمع أول المقاييس وقم بتقييم SAMM سريع لتختار الفجوات الثلاث التالية. ولا تقم بفتح كل الجبهات في الأسبوع الأول، والسبب أن الفريق الذي يستلم سياسة من عشرين صفحة وست أدوات جديدة في يوم واحد سوف يحكم على الفكرة كلها بأنها بيروقراطية، ويبحث عن طرق للالتفاف عليها. والترتيب أعلاه مقصود، فالجرد والمسؤولون أولاً لأن كل نشاط بعدهما يحتاج أن تعرف على أي تطبيق تعمل ومن يقرر، وقد شرحنا الفكرة نفسها للتوعية في [خطة أول تسعين يوماً لبرنامج التوعية](https://arabroot.io/articles/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D8%AC-%D8%A7%D9%84%D8%AA%D9%88%D8%B9%D9%8A%D8%A9-%D8%A8%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/#plan-90-days)، ويمكن تشغيل الخطتين معاً. ## ماذا تقيس دون أن تخدع نفسك؟ المقاييس Metrics يقول المثل المعروف في الإدارة إن ما لا يقاس لا يدار، ولكن في الأمن هناك مشكلة عكسية، وهي أن ما يقاس بطريقة خاطئة يدار بطريقة خاطئة. وفيما يلي مقاييس قليلة تستحق الجمع، مع ما تقوله وما لا تقوله، وتجد الفكرة نفسها في ممارسة [الاستراتيجية والمقاييس Strategy and Metrics](https://owaspsamm.org/model/governance/strategy-and-metrics/?ref=arabroot.io) في SAMM: - **متوسط زمن الإصلاح Mean Time to Remediate حسب الخطورة:** من يوم اكتشاف الثغرة إلى يوم نشر إصلاحها، مقسماً حسب الخطورة، ومقارناً بمواعيد الإصلاح المكتوبة. وانظر إلى النسبة التي تجاوزت موعدها أكثر من المتوسط نفسه، لأن ثغرة واحدة حرجة بقيت ستة أشهر تختفي داخل متوسط جميل. - **نسبة المستودعات التي يعمل فيها فحص الأسرار وSAST وSCA:** مقياس تغطية بسيط وصادق، ويكشف المستودعات المنسية، ولكنه لا يقول هل يقرأ أحد النتائج. - **نسبة الميزات عالية الخطورة التي لها نموذج تهديدات:** لاحظ كلمة «عالية الخطورة»، فإذا قست كل الميزات فسوف يملأ الفريق نماذج فارغة لميزات تغيير لون زر حتى يرتفع الرقم. - **الثغرات التي هربت Escaped Vulnerabilities:** الثغرات التي اكتشفت في الإنتاج أو في اختبار الاختراق أو من بلاغ خارجي، مقابل التي اكتشفت في الخط قبل الدمج. وهذا أقرب مقياس لجودة الدورة كلها، والأهم فيه السؤال لكل ثغرة هاربة: في أي مرحلة كان يمكن أن تكتشف، ولماذا لم تكتشف؟ وهذا هو تحليل السبب الجذري الذي تطلبه RV.3. - **عدد الاستثناءات المفتوحة وأعمارها:** كل مخاطرة قبلها أحد يجب أن يكون لها تاريخ مراجعة، والاستثناء الذي عمره ثلاث سنوات دون مراجعة هو ثغرة معروفة بقرار رسمي. ولا تقم بالحكم على الفرق بعدد النتائج المفتوحة، والسبب أن الفريق الذي أضاف أداة جديدة هذا الشهر سوف يظهر فيه عدد أكبر من النتائج، وهذا تحسن وليس تراجعاً، والفريق الذي يعرف أنه يقيم بعدد النتائج سوف يتعلم بسرعة كيف يخفيها، بتعطيل القواعد أو بتوسيع الاستثناءات. وكذلك لا تقارن الفرق ببعضها بالأرقام المطلقة، لأن تطبيقاً عمره عشر سنوات وتطبيقاً عمره شهر لا يبدآن من النقطة نفسها، وإنما قارن كل فريق بنفسه قبل ثلاثة أشهر. ## مسار القراءة Reading Path حسب المرحلة هذه هي المقالات الأهم التي يجمعها هذا الدليل، فابدأ بالصورة العامة ثم بالمرحلة التي يقف عندها فريقك اليوم: [![](https://arabroot.io/content/images/2026/10/devsecops-cover-cover.webp)دليلDevSecOps للمبتدئين: الأمن داخل خط CI/CD ومتى يعمل كل فحصما الذي يجده كل فحص أمني في خط CI/CD وما الذي يفوته، وكيف ترتب نتائجه حتى تصل إلى قرار بدل قائمة طويلة.](https://arabroot.io/articles/devsecops-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-sast-%D9%88-dast-%D9%88-sca/)[![](https://arabroot.io/content/images/2026/10/threat-modeling-cover-cover.webp)دليلنمذجة التهديدات Threat Modeling للمبتدئينكيف تسأل ما الذي قد يسوء في تصميم تطبيقك قبل أن تكتب الكود، وتقرر لكل تهديد هل تصلحه أو تقبله، مع قالب جاهز للنسخ.](https://arabroot.io/articles/%D9%86%D9%85%D8%B0%D8%AC%D8%A9-%D8%A7%D9%84%D8%AA%D9%87%D8%AF%D9%8A%D8%AF%D8%A7%D8%AA-threat-modeling-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/asvs-review-cover-cover.webp)دليلOWASP ASVS ومراجعة الكود الأمنية لكل Pull Requestكيف تكتب متطلبات أمان يمكن اختبارها مع OWASP ASVS، وتراجع كل طلب دمج أمنياً في عشرين دقيقة بقائمة جاهزة.](https://arabroot.io/articles/%D9%85%D8%AA%D8%B7%D9%84%D8%A8%D8%A7%D8%AA-%D8%A7%D9%84%D8%A7%D9%85%D8%A7%D9%86-%D9%88%D9%85%D8%B1%D8%A7%D8%AC%D8%B9%D8%A9-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D9%85%D8%B9-owasp-asvs/)[![](https://arabroot.io/content/images/2026/10/owasp-top10-cover-cover.webp)دليلOWASP Top 10 للمبتدئين: أخطر عشر مشكلات في تطبيقات الويبأخطر عشر مشكلات أمنية في تطبيقات الويب، كل واحدة بمثال ضعيف ثم مصلح، وكيف تمنعها في الكود وأين تكتشفها.](https://arabroot.io/articles/owasp-top-10-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/appsec-controls-cover-cover.webp)دليلضوابط أمن التطبيقات: دليل مقترح بنطاقات وضوابط مرقمة، مربوط بضوابط NCA وOWASP ASVSمقترح مستقل من عرب رووت بتسعين ضابطاً مرقماً لأمن تطبيقات الويب وواجهات API وخط CI/CD، لكل ضابط متطلب ودليل للمدقق، مربوط بالبنود التي يدعمها في ECC-2:2024 وCSCC وبأرقام OWASP ASVS 5.0، مع ملف Excel للتقييم الذاتي.](https://arabroot.io/articles/%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%AF%D9%84%D9%8A%D9%84-%D9%85%D9%82%D8%AA%D8%B1%D8%AD-%D9%85%D8%B9-%D8%B1%D8%A8%D8%B7-ecc-%D9%88-asvs/)[![](https://arabroot.io/content/images/2026/10/samm-cover-cover.webp)دليلOWASP SAMM: كيف تقيس نضج أمن تطبيقاتك وتحسنهكيف تعرف أين يقف أمن التطبيقات في فريقك بنموذج OWASP SAMM، ثم تحول نتيجة التقييم إلى خطة تحسين على مراحل.](https://arabroot.io/articles/%D9%86%D9%85%D8%A7%D8%B0%D8%AC-%D8%A7%D9%84%D9%86%D8%B6%D8%AC-owasp-samm-%D9%83%D9%8A%D9%81-%D8%AA%D9%82%D9%8A%D8%B3-%D8%A7%D9%85%D9%86-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%83/) المتطلبات والتصميم: [![](https://arabroot.io/content/images/2026/10/owasp-overview-cover-cover.webp)دليلما هي OWASP؟ مشاريعها ووثائقها ومتى تستخدم كلاً منهامن يدير OWASP ولماذا كل ما تنشره مجاني، وأي مورد من مواردها تفتح في كل مرحلة من بناء تطبيقك.](https://arabroot.io/articles/%D9%85%D8%A7-%D9%87%D9%8A-owasp-%D9%85%D8%B4%D8%A7%D8%B1%D9%8A%D8%B9%D9%87%D8%A7-%D9%88%D9%88%D8%AB%D8%A7%D8%A6%D9%82%D9%87%D8%A7-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/api-security-cover-cover.webp)دليلأمن ال API بالأمثلة مع OWASP API Security Top 10أشهر عشرة مخاطر في واجهات API كما ترتبها OWASP، ولكل خطر مثال لكود ضعيف وكيف تصلحه وتختبره.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D9%88%D8%A7%D8%AC%D9%87%D8%A7%D8%AA-api-%D9%85%D8%B9-owasp-api-security-top-10/)[![](https://arabroot.io/content/images/2026/10/llm-top10-cover-cover.webp)دليلOWASP Top 10 لتطبيقات LLM: المخاطر وكيف تحمي تطبيقكأخطر عشر مشكلات في التطبيقات المبنية على نماذج اللغة، من حقن التعليمات Prompt Injection إلى تسرب البيانات، وكيف تمنع كلاً منها.](https://arabroot.io/articles/owasp-top-10-%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%86%D9%85%D8%A7%D8%B0%D8%AC-%D8%A7%D9%84%D9%84%D8%BA%D8%A9-llm/)[![](https://arabroot.io/content/images/2026/10/tiers-layers-cover-cover.webp)دليلالفرق بين Tiers وLayers: متى يكون نظامك ثلاثي الطبقات فعلاً؟ماذا يعني أن يكون نظامك ثلاثي الطبقات 3-tier فعلاً، والفرق بين الطبقة داخل الكود والمستوى في الشبكة، وما تطلبه الضوابط بالنص.](https://arabroot.io/articles/%D8%A7%D9%84%D9%85%D8%B9%D9%85%D8%A7%D8%B1%D9%8A%D8%A9-%D9%85%D8%AA%D8%B9%D8%AF%D8%AF%D8%A9-%D8%A7%D9%84%D8%B7%D8%A8%D9%82%D8%A7%D8%AA-tiers-%D9%88-layers/)[![](https://arabroot.io/content/images/2026/10/crypto-for-devs-cover-cover.webp)دليلالتشفير للمطورين: ماذا تستخدم ولماذا لا تخترع خوارزميتكأي هاش تستخدم لكلمات المرور، ومتى تحتاج التشفير المتماثل أو غير المتماثل، وأين تحفظ المفاتيح بأمان في تطبيقك.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%B4%D9%81%D9%8A%D8%B1-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D8%A7%D9%84%D9%87%D8%A7%D8%B4-%D9%88%D9%83%D9%84%D9%85%D8%A7%D8%AA-%D8%A7%D9%84%D9%85%D8%B1%D9%88%D8%B1-%D9%88%D8%A7%D9%84%D9%85%D9%81%D8%A7%D8%AA%D9%8A%D8%AD/) كتابة الكود والتحقق: [![](https://arabroot.io/content/images/2026/10/secure-coding-cover-cover.webp)دليلالبرمجة الآمنة Secure Coding بأمثلة من أربع لغاتكيف تكتب الكود الذي يتعامل مع مدخلات المستخدم والملفات والأخطاء بحيث لا يحتاج إصلاحاً أمنياً لاحقاً، بأمثلة في أربع لغات.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D8%A9-secure-coding-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/secrets-scanning-cover-cover.webp)دليلSecrets Scanning: كيف تكتشف الأسرار المسربة في الكودكيف يخرج المفتاح من جهازك إلى تاريخ Git وخط CI، وكيف تكتشفه قبل غيرك، وماذا تفعل في الساعة الأولى بعد تسربه.](https://arabroot.io/articles/%D8%A7%D9%83%D8%AA%D8%B4%D8%A7%D9%81-%D8%A7%D9%84%D8%A7%D8%B3%D8%B1%D8%A7%D8%B1-%D8%A7%D9%84%D9%85%D8%B3%D8%B1%D8%A8%D8%A9-%D9%85%D8%B9-gitleaks-%D9%88-trufflehog/)[![](https://arabroot.io/content/images/2026/10/sast-cover-cover.webp)دليلSAST: كيف يجد تحليل الكود الثابت الثغرات قبل التشغيلكيف تقرأ أداة SAST الكود بحثاً عن الثغرات، وما الذي لا تراه أبداً، وكيف تمنع الإنذارات الخاطئة من أن تفقد الفريق ثقته بها.](https://arabroot.io/articles/%D8%AA%D8%AD%D9%84%D9%8A%D9%84-%D8%A7%D9%84%D9%83%D9%88%D8%AF-%D8%A7%D9%84%D8%AB%D8%A7%D8%A8%D8%AA-sast-%D9%85%D8%B9-semgrep-%D9%88-sonarqube/)[![](https://arabroot.io/content/images/2026/10/sca-cover-cover.webp)دليلSCA: كيف تجد الثغرات المعروفة في مكتبات مشروعككيف تجد أداة فحص الاعتماديات SCA المكتبات المصابة في مشروعك، ولماذا تختلف نتائج الأدوات، وكيف تبقي مكتباتك محدثة.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%A7%D8%B9%D8%AA%D9%85%D8%A7%D8%AF%D9%8A%D8%A7%D8%AA-sca-%D9%85%D8%B9-osv-scanner-%D9%88-dependency-track/)[![](https://arabroot.io/content/images/2026/10/container-scanning-cover-cover.webp)دليلفحص ال Docker Images وملفات البنية ككود IaCماذا يرى فاحص الثغرات داخل ال Docker Image وما الذي يفوته، وكيف تختار Base Image أصغر وتجعل الفحص بوابة في خط CI.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AD%D8%A7%D9%88%D9%8A%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%86%D9%8A%D8%A9-%D9%83%D9%83%D9%88%D8%AF-%D9%85%D8%B9-trivy/)[![](https://arabroot.io/content/images/2026/10/dast-cover-cover.webp)دليلDAST: فحص تطبيقك من الخارج وهو يعملكيف يفحص ZAP تطبيقك من الخارج وهو يعمل، ومتى يحق لك أن تشغله، وكيف تحول نتائجه إلى بوابة في خط CI.](https://arabroot.io/articles/%D9%81%D8%AD%D8%B5-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82-%D8%A7%D8%AB%D9%86%D8%A7%D8%A1-%D8%A7%D9%84%D8%AA%D8%B4%D8%BA%D9%8A%D9%84-dast-%D9%85%D8%B9-zap/)[![](https://arabroot.io/content/images/2026/10/web-vulns-lab-cover-cover.webp)دليلثغرات الويب بالتجربة: تطبيق نكسره ثم نصلحهنرى أثر أشهر ثغرات الويب على متجر صغير على جهازك، ثم السطر المسؤول عن كل ثغرة، ثم الإصلاح والاختبار الذي يثبته.](https://arabroot.io/articles/%D8%AB%D8%BA%D8%B1%D8%A7%D8%AA-%D8%A7%D9%84%D9%88%D9%8A%D8%A8-%D8%A8%D8%A7%D9%84%D8%AA%D8%AC%D8%B1%D8%A8%D8%A9-sql-injection-%D9%88-xss-%D9%88-ssrf/)[![](https://arabroot.io/content/images/2026/10/testing-types-cover-cover.webp)دليلأنواع الاختبارات للمبتدئين: من Unit إلى E2E مع Playwrightما الذي يكشفه كل نوع من الاختبارات وما الذي يفوته، وكم اختباراً تكتب من كل نوع، وأين يعمل كل منها في خط CI.](https://arabroot.io/articles/%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D8%A7%D9%84%D8%A7%D8%AE%D8%AA%D8%A8%D8%A7%D8%B1%D8%A7%D8%AA-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-unit-%D9%88-integration-%D9%88-e2e/) الإصدار والتشغيل: [![](https://arabroot.io/content/images/2026/10/supply-chain-cover-cover.webp)دليلأمن سلسلة التوريد البرمجية Software Supply Chain للمبتدئينكل ما بين كود غيرك وسيرفرك قد يحمل كود المهاجم، وهنا تعرف التهديدات الحقيقية بحوادث موثقة والدفاع المناسب لكل حلقة.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/environments-gitops-cover-cover.webp)دليلمن الفرع إلى الإنتاج: البيئات وGitOps للفرقكيف يختبر فريقك كل ميزة وحدها ويعرضها على العميل دون أن تصل ميزة غير جاهزة إلى الإنتاج.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D9%85%D8%B9%D8%A7%D9%8A%D9%86%D8%A9-%D8%A7%D9%84%D9%85%D9%8A%D8%B2%D8%A7%D8%AA-%D9%88-gitops-%D9%84%D9%84%D9%81%D8%B1%D9%82/)[![](https://arabroot.io/content/images/2026/10/deployment-history-cover-cover.webp)دليلطرق نشر التطبيقات من FTP إلى GitOps، وأين تقف أنتكيف تطور نشر التطبيقات عبر السنين، وما الذي يتعطل في كل طريقة، وكيف تعرف أين تقف وما خطوتك التالية.](https://arabroot.io/articles/%D8%B7%D8%B1%D9%82-%D9%86%D8%B4%D8%B1-%D8%A7%D9%84%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D9%85%D9%86-ftp-%D8%A7%D9%84%D9%89-gitops/)[![](https://arabroot.io/content/images/2026/10/http-protection-cover-cover.webp)دليلحماية تطبيقات الويب بطبقات أمان في ال Reverse Proxyكلمة المرور وحدها لا تحمي تطبيقاً مكشوفاً على الإنترنت، لذلك نضع أمامه طبقات حماية في ال Reverse Proxy نفسه.](https://arabroot.io/articles/%D8%AD%D9%85%D8%A7%D9%8A%D8%A9-%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA-%D8%A7%D9%84%D9%88%D9%8A%D8%A8-%D8%B9%D9%84%D9%89-%D9%85%D8%B3%D8%AA%D9%88%D9%89-http/)[![](https://arabroot.io/content/images/2026/10/logging-basics-cover-cover.webp)دليلالسجلات Logging للمطورين: ماذا تسجل وماذا لا تسجلكيف تكتب سجلات Logs تساعدك على فهم ما حدث في الإنتاج، وما الذي لا يدخل السجل أبداً، وكيف تجمعها في مكان واحد.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B3%D8%AC%D9%84%D8%A7%D8%AA-logging-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86-%D9%88%D9%85%D8%AF%D9%8A%D8%B1%D9%8A-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/audit-trail-cover-cover.webp)دليلAudit Trail: كيف تبني سجل تدقيق لا يقبل العبثكيف تصمم سجلاً يجيب عن سؤال من غير هذه الصلاحية ومتى، وتحميه من الحذف والتعديل بعد كتابته.](https://arabroot.io/articles/%D8%B3%D8%AC%D9%84-%D8%A7%D9%84%D8%AA%D8%AF%D9%82%D9%8A%D9%82-audit-trail-%D9%85%D9%86-%D9%81%D8%B9%D9%84-%D9%85%D8%A7%D8%B0%D8%A7-%D9%88%D9%85%D8%AA%D9%89/)[![](https://arabroot.io/content/images/2026/10/dfir-basics-cover-cover.webp)دليلالتحقيق الرقمي DFIR للمبتدئين: احفظ الأدلة قبل أن تنظف السيرفرماذا تفعل عندما تشك أن سيرفرك مخترق، ولماذا تمسح إعادة التشغيل والتنظيف الأدلة التي تحتاجها لتعرف ما حدث.](https://arabroot.io/articles/%D8%A7%D9%84%D8%AA%D8%AD%D9%82%D9%8A%D9%82-%D8%A7%D9%84%D8%B1%D9%82%D9%85%D9%8A-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86-dfir/) الحوكمة والامتثال: [![](https://arabroot.io/content/images/2026/10/nca-ecc-cover-cover.webp)دليلالضوابط الأساسية للأمن السيبراني NCA ECC بلغة بسيطةكيف تقرأ الضوابط الأساسية ECC دون أن تضيع في أرقامها، وعلى من تنطبق، وما المطلوب من جهتك فعلاً في كل مكون.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B6%D9%88%D8%A7%D8%A8%D8%B7-%D8%A7%D9%84%D8%A7%D8%B3%D8%A7%D8%B3%D9%8A%D8%A9-%D9%84%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-nca-ecc-%D8%A8%D9%84%D8%BA%D8%A9-%D8%A8%D8%B3%D9%8A%D8%B7%D8%A9/)[![](https://arabroot.io/content/images/2026/10/grc-terms-cover-cover.webp)دليلمصطلحات GRC للمبتدئين بمثال من شركة صغيرةما الذي يعنيه GRC فعلاً، وما الكلمات التي يستخدمها المدقق، وكيف تثبت له أن ضوابطك تعمل كما تقول.](https://arabroot.io/articles/%D9%85%D8%B5%D8%B7%D9%84%D8%AD%D8%A7%D8%AA-grc-%D8%A7%D9%84%D8%AD%D9%88%D9%83%D9%85%D8%A9-%D9%88%D8%A7%D9%84%D9%85%D8%AE%D8%A7%D8%B7%D8%B1-%D9%88%D8%A7%D9%84%D8%A7%D9%85%D8%AA%D8%AB%D8%A7%D9%84/)[![](https://arabroot.io/content/images/2026/10/security-awareness-cover-cover.webp)دليلبرنامج التوعية بالأمن السيبراني بأدوات مفتوحة المصدرالمحاضرة السنوية لا تغير ما يفعله الموظف أمام الرسالة المشبوهة، لذلك تبني هنا برنامج توعية مستمراً وتقيس أثره بأدوات مفتوحة المصدر.](https://arabroot.io/articles/%D8%A8%D8%B1%D9%86%D8%A7%D9%85%D8%AC-%D8%A7%D9%84%D8%AA%D9%88%D8%B9%D9%8A%D8%A9-%D8%A8%D8%A7%D9%84%D8%A7%D9%85%D9%86-%D8%A7%D9%84%D8%B3%D9%8A%D8%A8%D8%B1%D8%A7%D9%86%D9%8A-%D8%A8%D8%A7%D8%AF%D9%88%D8%A7%D8%AA-%D9%85%D9%81%D8%AA%D9%88%D8%AD%D8%A9-%D8%A7%D9%84%D9%85%D8%B5%D8%AF%D8%B1/)[![](https://arabroot.io/content/images/2026/10/saas-cto-blueprint-cover-cover.webp)دليلخارطة CTO لشركة SaaS ناشئة من اليوم الأول إلى خمسين موظفاًماذا يجهز المدير التقني في كل مرحلة من نمو شركة SaaS ناشئة، وما الذي يؤجله حتى يحتاجه فعلاً.](https://arabroot.io/articles/%D8%AE%D8%A7%D8%B1%D8%B7%D8%A9-cto-%D9%84%D8%B4%D8%B1%D9%83%D8%A9-saas-%D9%86%D8%A7%D8%B4%D8%A6%D8%A9-%D8%A7%D9%84%D8%B3%D9%8A%D8%B1%D9%81%D8%B1%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D8%A8%D9%8A%D8%A6%D8%A7%D8%AA-%D9%88%D8%A7%D9%84%D9%81%D8%B1%D9%82/) ## أخطاء شائعة Common Mistakes - **اعتبار الأدوات في خط CI هي الدورة كلها:** الأدوات تبدأ من مرحلة الكود، أما أخطاء المتطلبات والتصميم فلا تراها، فأضف المتطلبات ونمذجة التهديدات قبلها. - **كتابة سياسة دون مسؤولين:** سياسة من عشرين صفحة لا يوجد فيها اسم شخص محاسب على كل نشاط لا يطبقها أحد، فابدأ بجدول RACI قبل السياسة. - **نسخ قالب السياسة كما هو:** القوالب، ومنها قالب الهيئة، أمثلة تخصص للجهة، فالسياسة التي تذكر أدوات لا تستخدمها وخطوات لا تنفذها تفشل في أول تدقيق. - **نمذجة تهديدات لكل شيء أو لا شيء:** الأولى تتحول إلى أوراق فارغة، والثانية تترك الميزات الخطرة دون تفكير، والحل أن تلزم بها الميزات عالية الخطورة فقط. - **اختبار التطبيق دون متطلبات مكتوبة:** فلا تستطيع أن تقول للمدقق إن التطبيق «يلتزم بالمتطلبات»، لأنه لا توجد متطلبات ليلتزم بها. - **جعل فريق الأمن مسؤولاً عن أمان كل تطبيق:** فيتحول إلى بوابة أخيرة، ويتعلم المطورون أن الأمن ليس عملهم. - **اعتبار يوم الإطلاق نهاية الأمن:** الثغرات الجديدة تنشر كل يوم في مكتبات لم تتغير، والمخترق يبدأ بعد الإطلاق. - **نسيان مرحلة الإيقاف:** سيرفر قديم بلا تحديثات، وقاعدة بيانات فيها بيانات عملاء، ومفتاح API صالح، وسجل DNS معلق، وكل منها باب مفتوح. - **جمع الأدلة قبل التدقيق بأسبوع:** الأدلة يجب أن تخرج من العمل نفسه، من التذكرة وطلب الدمج وخط CI. - **قياس عدد النتائج بدل زمن إصلاحها:** فيتعلم الفريق إخفاء النتائج بدل إصلاحها. ## قائمة تحقق Checklist لدورة التطوير الآمنة - هل لكل تطبيق مالك باسمه، ودرجة أهمية، ومستوى ASVS مكتوب؟ - هل في قالب التذكرة حقل للمتطلبات الأمنية، وهل تكتب حالات الإساءة للميزات الخطرة؟ - هل لكل ميزة عالية الخطورة نموذج تهديدات فيه قرار لكل تهديد؟ - هل يوجد معيار برمجة آمنة مكتوب لكل لغة يستخدمها الفريق؟ - هل يمر كل طلب دمج على مراجع غير الكاتب، مع قائمة مراجعة أمنية؟ - هل يعمل فحص الأسرار وSAST وSCA وفحص ال Images في خط CI لكل مستودع؟ - هل توجد اختبارات آلية مكتوبة من المتطلبات الأمنية، مثل الصلاحيات بين المستخدمين؟ - هل تبنى ال Image مرة واحدة، وتوقع، ولها SBOM، وتمر على بوابة بسياسة مكتوبة قبل الإنتاج؟ - هل تراجع الإعدادات والتحصين قبل كل إطلاق كبير؟ - هل تسجل الأحداث الأمنية مركزياً، وتصل تنبيهاتها إلى شخص حقيقي؟ - هل لكل خطورة موعد إصلاح مكتوب، ويقاس الالتزام به؟ - هل يوجد SECURITY.md في المستودعات وsecurity.txt على الموقع، ومن يقرأ البلاغات؟ - هل توجد خطة استجابة للحوادث نفذ عليها تمرين خلال السنة الأخيرة؟ - هل توجد قائمة تحقق لإيقاف التطبيقات، تشمل البيانات والأسرار وسجلات DNS وجرد الأصول؟ - هل يوجد جدول RACI، وفي كل صف فيه شخص محاسب واحد؟ - هل تراجع المقاييس شهرياً، وتقيم الدورة كلها مرة في السنة بنموذج مثل SAMM؟ ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - دورة حياة التطوير SDLC موجودة في كل فريق سواء سماها أم لا، ومراحلها السبع من المتطلبات إلى الإيقاف موجودة في الشلال وفي Agile، والفرق في حجم كل مرحلة وتكرارها. - Secure SDLC هو أن تضيف نشاطاً أمنياً داخل كل مرحلة، له مخرج يراه غيرك ومسؤول معروف، وDevSecOps هو الجزء الآلي منه في خط CI/CD. - أخطاء التصميم تولد قبل الكود، ولا تراها الأدوات، وإصلاحها متأخراً قد يعني إعادة تصميم، لذلك تبدأ الدورة بالمتطلبات ونمذجة التهديدات، وNIST SSDF تقول إن معالجة الأمن أبكر تقلل الجهد والتكلفة للوصول إلى المستوى نفسه. - المراجع تصف الشيء نفسه بأسماء مختلفة: SSDF بمجموعاتها الأربع PO وPS وPW وRV، وMicrosoft SDL بممارساته العشر، وSAMM بوظائفه الخمس ومستوياته الثلاثة، وISO 27001 بالضابط 8.25 وما حوله، وضوابط الهيئة بالضابط 1-6-3 والمكون 2-15، ودليل ARC-ASC بنطاقاته الثلاثة عشر. - مرحلة التشغيل أطول المراحل، ومرحلة الإيقاف أكثرها نسياناً، وكلاهما جزء من الدورة. - الفريق الذي يكتب الكود يملك أمانه، وفريق الأمن يضع القواعد ويساعد، وسفير الأمن هو الجسر بينهما، ولكل نشاط شخص محاسب واحد. - ابدأ بالجرد والمسؤولين، ثم التصميم والكود، ثم الإصدار والتشغيل، وقس زمن الإصلاح والثغرات الهاربة بدل عدد النتائج. وفي المقالات القادمة بإذن الله سوف نشرح تقييم نضج الفريق بنموذج OWASP SAMM خطوة خطوة، وخط CI/CD آمن من البداية إلى النهاية يجمع الفحوص والتوقيع والبوابات في مثال واحد. ## سجل التحديثات - أكتوبر 2026: كتابة الدليل، والتحقق من NIST SP 800-218 (الإصدار 1.1 النهائي، ومسودة الإصدار 1.2 المنشورة في ديسمبر 2025)، وممارسات Microsoft SDL العشر، ونموذج OWASP SAMM v2، وضوابط ISO/IEC 27001:2022 من 8.25 إلى 8.32، ونص الضوابط 1-5-3 و1-6 و2-15 في ECC-2:2024، وNIST SP 800-88 Rev. 2، وRFC 9116، ووثائق GitHub عن SECURITY.md وأرشفة المستودعات.