أساسيات دورة حياة تطوير البرمجيات الآمنة (SDLC)
قبل النظر في ما ينبغي للمدققين التحقق منه في كل مرحلة، يجدر تحديد المقصود فعليًا بدورة حياة تطوير البرمجيات الآمنة، ولماذا تكتسب أهميتها في البيئات الخاضعة للتنظيم، وكيف تختلف عن المفاهيم ذات الصلة. يوفّر هذا التمهيد ذلك الأساس.
لماذا تكتسب أهميتها في البيئات الخاضعة للتنظيم
تعمل تطبيقات المؤسسات الحديثة في بيئات لم تعد فيها إخفاقات الأمن محصورة في الحوادث التقنية. فهي تُترجَم مباشرةً إلى ملاحظات تنظيمية، واضطرابات تشغيلية، وعقوبات مالية، وأضرار في السمعة.
في القطاعات الخاضعة للتنظيم مثل الأعمال المصرفية والتأمين والرعاية الصحية والبنية التحتية الحيوية، لا يُعدّ أمن التطبيقات خيارًا. بل يجب أن يكون منهجيًا وقابلًا للإثبات وقابلًا للتدقيق عبر دورة حياة تطوير البرمجيات بأكملها. وهنا تصبح دورة حياة تطوير البرمجيات الآمنة مفهومًا تأسيسيًا — ليست أداةً أو قائمة تحقق أو فحصًا أمنيًا منفردًا، بل نهجًا منظمًا لترسيخ الضوابط الأمنية والحوكمة وتوليد الأدلة على مدى حياة التطبيق، من التصميم إلى الإنتاج وما بعده.
ما دورة حياة تطوير البرمجيات الآمنة؟
دورة حياة تطوير البرمجيات الآمنة امتدادٌ لدورة حياة تطوير البرمجيات التقليدية يدمج المتطلبات الأمنية والضوابط وأنشطة التحقق في كل مرحلة من مراحل التسليم. فبدلًا من التعامل مع الأمن باعتباره بوابةً نهائية أو نشاطًا لاحقًا للإصدار، تضمن أن يكون الأمن:
- مصمَّمًا من الأساس، لا مُلحقًا لاحقًا
- مُنفَّذًا باستمرار، لا مُراجَعًا دوريًا
- قابلًا للقياس والتدقيق، لا ضمنيًا
في البيئات الخاضعة للتنظيم، تخدم دورة حياة تطوير البرمجيات الآمنة أيضًا بوصفها العمود الفقري لإثبات الامتثال لأطر مثل ISO 27001 وSOC 2 وDORA وNIS2 وPCI DSS.
المبادئ الأساسية
ترتكز دورة حياة تطوير البرمجيات الآمنة الناضجة على ثلاثة مبادئ:
- الأمن بالتصميم. تُحدَّد الأهداف الأمنية جنبًا إلى جنب مع المتطلبات الوظيفية أثناء التخطيط والتصميم — من خلال نمذجة التهديدات، وتقييم المخاطر، وتحديد المتطلبات الأمنية، ومواءمة الضوابط مع التوقعات التنظيمية. والقرارات المتخذة هنا تُشكّل كل ما يليها؛ أما تركيب الأمن لاحقًا فهو مكلف وهشّ ونادرًا ما يكون جاهزًا للتدقيق.
- الضوابط المُزاحة إلى اليسار (Shift-left). ينتقل الكشف والوقاية إلى أبكر وقت ممكن، عادةً إلى مرحلتي التطوير ومراجعة الشيفرة. وتهدف ضوابط مثل الاختبار الأمني الساكن للتطبيقات، والكشف عن الأسرار، ومعايير الترميز الآمن، وفحوص سياسة الاعتماديات، ليس فقط إلى اكتشاف الثغرات مبكرًا بل إلى منع الأنماط غير الآمنة من الانتشار إلى المراحل اللاحقة.
- الإنفاذ المستمر عبر CI/CD. في بيئات المؤسسات، يصبح خط أنابيب التسليم محرّك الإنفاذ. فمن خلال السياسة بوصفها شيفرة، وبوابات الموافقة الآلية، والفحوص الأمنية الإلزامية، تُطبَّق الضوابط باتساق وتوحيد عبر الفرق، ويتعذّر تجاوزها. وفي السياقات الخاضعة للتنظيم، يجب التعامل مع خطوط الأنابيب بوصفها أنظمة خاضعة للتنظيم، لا مجرد أدوات أتمتة.
دورة حياة تطوير البرمجيات الآمنة وDevSecOps وأمن CI/CD
كثيرًا ما تُستخدَم هذه المصطلحات بالتبادل، لكنها تخدم أغراضًا مختلفة:
- دورة حياة تطوير البرمجيات الآمنة تحدد ما الضوابط الأمنية التي يجب أن توجد عبر دورة الحياة.
- DevSecOps تحدد كيف تتعاون الفرق وتعمل لتطبيق تلك الضوابط.
- أمن CI/CD يحدد كيف تُنفَّذ الضوابط تقنيًا عبر خطوط الأنابيب.
توفّر دورة حياة تطوير البرمجيات الآمنة الأساس البنيوي الذي تُبنى عليه ممارسات DevSecOps وآليات أمن CI/CD.
نظام حوكمة، لا منتج
في البيئات الخاضعة للتنظيم، تحمل دورة حياة تطوير البرمجيات الآمنة قيودًا إضافية: يجب توثيق الضوابط وتتبّعها، ويجب أن تكون القرارات قابلة للتبرير أمام المدققين، ويجب أن تكون الاستثناءات صريحة ومعتمَدة ومسجَّلة، ويجب الاحتفاظ بالأدلة وإمكان تصديرها. وهذا يحوّل دورة حياة تطوير البرمجيات الآمنة من ممارسة هندسية بحتة إلى نظام للحوكمة وإدارة المخاطر.
ويترتب على ذلك أن دورة حياة تطوير البرمجيات الآمنة لا يمكن ببساطة شراؤها. فالأدوات تدعمها لكنها لا تعرّفها؛ ومن دون أهداف واضحة للضوابط، وتدفقات عمل مُنفَّذة، ونماذج حوكمة، واستراتيجيات للاحتفاظ بالأدلة، تعجز حتى أكثر الأدوات تقدمًا عن إنتاج نتائج أمنية أو امتثالية ذات معنى. فدورة حياة تطوير البرمجيات الآمنة نموذج تشغيلي، لا منتج. والمؤسسات التي تطبّقها جيدًا تكسب عمليات تدقيق أسرع، وحوادث إنتاج أقل، واحتكاكًا أقل بين وظائف الأمن والتطوير والامتثال، وثقةً أعلى في تسليم البرمجيات. والهدف ليس إضافة مزيد من الأمن، بل جعل الأمن حتميًا وقابلًا للتحقق ومستدامًا.
وبعد ترسيخ هذا الأساس، يتناول ما تبقى من هذا الدليل دورة حياة تطوير البرمجيات الآمنة بوصفها إطارًا للضوابط، ويستعرض ما ينبغي للمدققين التحقق منه في كل مرحلة.
دورة حياة تطوير البرمجيات الآمنة بوصفها إطارًا للضوابط
كثيرًا ما تُقدَّم دورة حياة تطوير البرمجيات الآمنة (Secure SDLC) بوصفها منهجية تطوير — سلسلة من الممارسات التي تتّبعها فرق الهندسة لبناء برمجيات أكثر أمنًا. لكن بالنسبة للمدققين ومسؤولي الامتثال، ينبغي تقييمها بوصفها شيئًا أكثر جوهرية: إطارًا للضوابط.
تمثّل كل مرحلة من مراحل دورة حياة تطوير البرمجيات نقطة ضبط ينبغي أن تجري فيها أنشطة أمنية محددة، وأن تُولَّد فيها أدلة محددة، وأن تكون نتائجها محددة قابلة للتحقق. وحين تدّعي مؤسسة أنها تشغّل دورة حياة تطوير برمجيات آمنة، يجب على المدققين النظر إلى ما وراء توثيق العمليات وتقييم ما إذا كانت الضوابط تعمل فعليًا في كل مرحلة.
يستعرض هذا الدليل كل مرحلة من مراحل دورة حياة تطوير البرمجيات من منظور المدقق، محددًا ما ينبغي أن يحدث، وما الأدلة التي ينبغي طلبها، وكيف تبدو الممارسة الجيدة، وما الذي ينبغي أن يثير القلق.
مرحلة التخطيط (PLAN)
ما ينبغي أن يحدث
تُدمَج الاعتبارات الأمنية في تخطيط المشروع قبل بدء أي تطوير. ويشمل ذلك نمذجة التهديدات لتحديد نواقل الهجوم المحتملة، وتحديد المتطلبات الأمنية جنبًا إلى جنب مع المتطلبات الوظيفية، وتصنيف التطبيق وفقًا لإطار تصنيف المخاطر لدى المؤسسة.
الأدلة المطلوب طلبها
- توثيق نموذج التهديدات (مخططات تدفق البيانات، تحديد التهديدات، قرارات التخفيف)
- المتطلبات الأمنية الموثَّقة في سجل أعمال المشروع أو مستودع المتطلبات
- سجل تصنيف مخاطر التطبيق مع الموافقة
- سجلات مشاركة الأمن في جلسات التخطيط
كيف تبدو الممارسة الجيدة
- تُنشأ نماذج التهديدات لجميع تطبيقات المستوى الأول والمستوى الثاني وتُحدَّث عند تغيّر البنية المعمارية
- المتطلبات الأمنية قابلة للتتبّع — لكل تهديد مُحدَّد في النموذج متطلبٌ مقابل أو مخاطرة مقبولة
- يقود التصنيف متطلبات الضوابط اللاحقة (وتيرة الاختبار، تدفقات عمل الموافقة)
- يشارك أفراد الأمن في أنشطة التخطيط، بدليل سجلات الاجتماعات
كيف تبدو الممارسة السيئة
- لا توجد نماذج تهديدات، أو أنها أُنشئت مرةً واحدة ولم تُحدَّث قط
- المتطلبات الأمنية عامة (“يجب أن يكون التطبيق آمنًا”) بدلًا من أن تكون محددة وقابلة للاختبار
- تصنيف التطبيق مفقود أو أُجري من دون مدخلات من الأمن أو الامتثال
- لا يُشرَك الأمن إلا عند الاختبار أو النشر
مرحلة الترميز (CODE)
ما ينبغي أن يحدث
يتّبع المطورون معايير ترميز آمن موثَّقة. وتُراجَع تغييرات الشيفرة بحثًا عن المشكلات الأمنية — إما عبر مراجعة الأقران بمراجعين واعين بالأمن، أو عبر الاختبار الأمني الساكن للتطبيقات (SAST). ويمنع فحص الأسرار إدراج بيانات الاعتماد ومفاتيح واجهات البرمجة والرموز في المستودعات.
الأدلة المطلوب طلبها
- وثيقة معايير الترميز الآمن، معتمَدة وخاضعة للتحكم في الإصدارات
- سجلات مراجعة الشيفرة التي تُظهر تعليقات أمنية ومعالجاتها
- نتائج فحوص SAST المدمجة في تدفق عمل التطوير
- إعدادات فحص الأسرار وسجلات التنبيهات
- سجلات تدريب المطورين على ممارسات الترميز الآمن
كيف تبدو الممارسة الجيدة
- يعمل SAST تلقائيًا عند كل طلب دمج أو إيداع شيفرة، مع ظهور النتائج للمطورين
- تُظهر سجلات مراجعة الشيفرة تحديد الملاحظات الأمنية ومعالجتها — لا المراجعة الوظيفية فحسب
- يحجب فحص الأسرار عمليات الإيداع التي تحتوي على بيانات اعتماد، مع عملية موثَّقة لتدوير أي أسرار مكشوفة
- يتلقى المطورون تدريبًا سنويًا (كحد أدنى) على الترميز الآمن يتصل بحزمتهم التقنية
كيف تبدو الممارسة السيئة
- يُشغَّل SAST يدويًا أو قبل الإصدارات فقط، ما يعني تراكم الثغرات
- توجد مراجعات للشيفرة لكنها لا تتضمن أبدًا ملاحظات ذات صلة بالأمن
- لا يوجد فحص للأسرار، أو أن التنبيهات تُتجاهَل
- معايير الترميز الآمن قديمة أو غير متوائمة مع التقنيات المستخدَمة
مرحلة البناء (BUILD)
ما ينبغي أن يحدث
تتضمن عملية البناء تحليل تكوين البرمجيات (SCA) لتحديد الثغرات في الاعتماديات الخارجية ومفتوحة المصدر. ويُولَّد سِجل مكوّنات البرمجيات (SBOM) لكل بناء للحفاظ على جرد لجميع المكوّنات. وتُوقَّع مخرجات البناء لضمان السلامة ومنع العبث.
الأدلة المطلوب طلبها
- نتائج فحوص SCA لعمليات البناء الأخيرة، تُظهر الثغرات المحددة وطريقة التصرف فيها
- سجلات SBOM لإصدارات الإنتاج
- إعدادات توقيع المخرجات وسجلات التحقق
- سياسة عتبات الثغرات المقبولة في الاعتماديات
كيف تبدو الممارسة الجيدة
- يعمل SCA عند كل بناء مع سياسات محددة لحجب عمليات البناء التي تحتوي على ثغرات حرجة أو عالية الخطورة
- تُولَّد سجلات SBOM تلقائيًا وتُخزَّن مع سجلات الإصدار
- يُفرَض توقيع المخرجات — لا يمكن نشر المخرجات غير المُوقَّعة إلى الإنتاج
- توجد عملية للترقيع الطارئ للثغرات الحرجة في الاعتماديات
كيف تبدو الممارسة السيئة
- SCA غير مدمج في عملية البناء أو يعمل دوريًا فقط
- لا يُولَّد SBOM — تعجز المؤسسة عن تحديد المكوّنات الموجودة في الإنتاج
- لا يوجد توقيع للمخرجات — لا سبيل للتحقق من أن المخرجات المنشورة تطابق عمليات البناء المعتمَدة
- توجد ثغرات حرجة معروفة في الاعتماديات ضمن الإنتاج من دون قبول موثَّق للمخاطر
مرحلة الاختبار (TEST)
ما ينبغي أن يحدث
يُجرى الاختبار الأمني الديناميكي للتطبيقات (DAST) على التطبيقات قيد التشغيل لتحديد الثغرات التي يتعذّر على التحليل الساكن كشفها (عيوب المصادقة، مشكلات الإعداد، ثغرات الحقن في وقت التشغيل). ويوفّر اختبار الاختراق على يد أفراد مؤهلين منظورًا هجوميًا. وتُعزَل بيئات الاختبار عن الإنتاج لمنع تسرّب البيانات.
الأدلة المطلوب طلبها
- نتائج فحوص DAST وسجلات المعالجة
- تقارير اختبار الاختراق مع النطاق والمنهجية والملاحظات وحالة المعالجة
- أدلة على عزل البيئات (مخططات الشبكة، ضوابط الوصول)
- سجلات تُظهر توافق وتيرة الاختبار مع مستوى مخاطر التطبيق
كيف تبدو الممارسة الجيدة
- يكون DAST آليًا ويعمل بالوتيرة التي يحددها تصنيف مخاطر التطبيق
- يُجرى اختبار الاختراق على يد مختبِرين مستقلين مؤهلين (داخليين أو خارجيين) بنطاق محدد
- لا تحتوي بيئات الاختبار على بيانات إنتاج، أو تُقنَّع بيانات الإنتاج على النحو المناسب
- تُتابَع ملاحظات الاختبار حتى المعالجة المُتحقَّق منها
كيف تبدو الممارسة السيئة
- لا يُجرى DAST، أو تُتجاهَل نتائجه
- يُجري اختبار الاختراق الفريق نفسه الذي بنى التطبيق، من دون استقلالية
- تحتوي بيئات الاختبار على بيانات إنتاج غير مُقنَّعة
- تبقى ملاحظات الاختبار مفتوحة إلى أجل غير مسمى من دون تصعيد
مرحلة الإصدار (RELEASE)
ما ينبغي أن يحدث
تخضع الإصدارات لتدفقات عمل موافقة تتحقق من إتمام جميع الأنشطة الأمنية المطلوبة. وتفرض بوابات السياسة في خط أنابيب التسليم استيفاء المتطلبات الأمنية قبل أن تتمكن الشيفرة من التقدّم إلى الإنتاج. وتُوثَّق قرارات الإصدار كجزء من إدارة التغيير.
الأدلة المطلوب طلبها
- سجلات موافقة الإصدار التي تُظهر الاعتماد الأمني حيثما لزم
- نتائج بوابات السياسة من خط أنابيب التسليم (سجلات نجاح/إخفاق مع طوابع زمنية)
- سجلات إدارة التغيير التي تربط الإصدارات بنتائج الاختبار الأمني
- سجلات الاستثناءات لأي إصدارات تجاوزت بوابات السياسة
كيف تبدو الممارسة الجيدة
- بوابات السياسة آلية ومُنفَّذة — يمنع خط الأنابيب الإصدار إذا لم تُستوفَ المعايير الأمنية
- يُشترَط الاعتماد الأمني لتطبيقات المستوى الأول والمستوى الثاني، مع موافقة موثَّقة
- تتطلب تجاوزات البوابات موافقة استثناء رسمية وتُتتبَّع
- تُربَط سجلات الإصدار بنتائج فحص واختبار محددة
كيف تبدو الممارسة السيئة
- لا توجد بوابات سياسة — الاختبار الأمني استشاري فقط
- توجد بوابات لكنها تُتجاوَز كثيرًا من دون موافقة رسمية
- تشير موافقات الإصدار إلى الاختبار الأمني لكنها لا تُربَط بنتائج محددة
- تُستخدَم إجراءات الإصدار الطارئ روتينيًا، ما يتحايل على الضوابط المعتادة
مرحلة النشر (DEPLOY)
ما ينبغي أن يحدث
تُسجَّل عمليات النشر بتفصيل كافٍ لتحديد ما نُشِر، ومتى، ومن قِبل مَن، وإلى أي بيئة. ويُتحقَّق من الإعداد مقابل خطوط الأساس الأمنية. وتطابق بيئات الإنتاج الإعدادات التي جرى اختبارها.
الأدلة المطلوب طلبها
- سجلات النشر مع طوابع زمنية، ومعرّفات المخرجات، وهوية القائم بالنشر، والبيئة المستهدفة
- سجلات التحقق من الإعداد (فحوص خطوط الأساس الأمنية)
- أدلة على تكافؤ البيئتين بين الاختبار والإنتاج
- سجلات التراجع حيث جرى عكس عمليات النشر
كيف تبدو الممارسة الجيدة
- عمليات النشر آلية ومسجَّلة وقابلة للتدقيق — يُحظَر النشر اليدوي إلى الإنتاج أو يتطلب موافقة استثنائية
- يحدد كشف انحراف الإعداد الانحرافات عن خطوط الأساس الأمنية وينبّه عليها
- تضمن البنية التحتية بوصفها شيفرة أو ما يعادلها تكافؤ البيئات
- تُوثَّق عمليات النشر الفاشلة والتراجعات مع السبب الجذري
كيف تبدو الممارسة السيئة
- عمليات نشر يدوية بلا أثر تدقيقي
- لا يوجد تحقق من الإعداد — تُفترَض الإعدادات الأمنية بدلًا من التحقق منها
- فروق كبيرة بين بيئتي الاختبار والإنتاج
- يُمنَح الوصول للنشر على نطاق واسع من دون قيود قائمة على الأدوار
مرحلة المراقبة (MONITOR)
ما ينبغي أن يحدث
تُراقَب تطبيقات الإنتاج بحثًا عن الأحداث الأمنية والسلوك الشاذ والثغرات الجديدة. وتكشف آليات الحماية في وقت التشغيل التهديدات النشطة وتستجيب لها. وتتيح عملية الإفصاح عن الثغرات للباحثين الخارجيين الإبلاغ عن المشكلات بمسؤولية.
الأدلة المطلوب طلبها
- إعدادات المراقبة الأمنية وسجلات التنبيهات
- سجلات كشف الحوادث والاستجابة لها المتصلة بالتطبيقات
- سياسة الإفصاح عن الثغرات (متاحة للعموم)
- سجلات الثغرات المُبلَّغ عنها عبر قنوات الإفصاح وطريقة حلّها
- سجلات نشر أدوات الأمن في وقت التشغيل
كيف تبدو الممارسة الجيدة
- المراقبة الأمنية على مستوى التطبيق نشطة، مع توجيه التنبيهات إلى فريق عمليات الأمن
- تعالج إجراءات الاستجابة للحوادث تحديدًا الحوادث على مستوى التطبيق (لا البنية التحتية فحسب)
- تُنشَر سياسة للإفصاح عن الثغرات، وتُفرَز التقارير وتُتتبَّع
- تؤدي الثغرات المُفصَح عنها حديثًا في الاعتماديات إلى إعادة تقييم عبر SCA
كيف تبدو الممارسة السيئة
- لا توجد مراقبة على طبقة التطبيق — المراقبة قائمة على البنية التحتية فقط
- لا توجد عملية للإفصاح عن الثغرات — لا قناة استقبال للتقارير الخارجية
- تُعالَج الحوادث الأمنية التي تشمل التطبيقات بصورة ارتجالية من دون إجراءات موثَّقة
- لا توجد عملية للاستجابة للثغرات المُفصَح عنها حديثًا في الاعتماديات
ملخّص: الضوابط والأدلة والمؤشرات التحذيرية حسب المرحلة
| المرحلة | الضابط الرئيسي | مُخرَج الأدلة | أين تجدها | مؤشر تحذيري |
|---|---|---|---|---|
| التخطيط | نمذجة التهديدات | وثيقة نموذج التهديدات | الويكي، مستودع التصميم، سجل المخاطر | لا نماذج تهديدات أو نماذج لم تُحدَّث قط |
| الترميز | SAST / مراجعة الشيفرة | نتائج الفحص، سجلات المراجعة | سجلات خط أنابيب CI/CD، أداة مراجعة الشيفرة | SAST غير مدمج أو نتائجه مُتجاهَلة |
| البناء | SCA / SBOM | نتائج فحص الاعتماديات، ملفات SBOM | نظام البناء، مستودع المخرجات | لا جرد للمكوّنات في الإنتاج |
| الاختبار | DAST / اختبار الاختراق | تقارير الفحص، تقارير اختبار الاختراق | أدوات الاختبار الأمني، أرشيف التقارير | لا اختبار ديناميكي أو لا استقلالية |
| الإصدار | بوابات السياسة / الموافقة | نتائج البوابات، سجلات الموافقة | سجلات خط الأنابيب، نظام إدارة التغيير | تجاوز البوابات من دون موافقة |
| النشر | تسجيل النشر | سجلات النشر، فحوص الإعداد | منصة النشر، أدوات المراقبة | عمليات نشر يدوية بلا أثر تدقيقي |
| المراقبة | المراقبة في وقت التشغيل | سجلات التنبيهات، سجلات الحوادث | SIEM، منصة المراقبة، نظام التذاكر | لا مراقبة على طبقة التطبيق |
ملاحظات التدقيق الشائعة عبر مراحل دورة حياة تطوير البرمجيات
استنادًا إلى نتائج التدقيق المعتادة في المؤسسات الخاضعة للتنظيم، تشمل أكثر الملاحظات تكرارًا ما يلي:
- تغطية غير متسقة: تُطبَّق الضوابط الأمنية على بعض التطبيقات دون غيرها، من دون مبرّر موثَّق للفارق
- فجوات في الأدلة: تُوصَف الضوابط في السياسة لكن الأدلة على تنفيذها ناقصة أو مفقودة — خصوصًا لنمذجة التهديدات ومراجعة الشيفرة الأمنية
- تتبّع مكسور: يتعذّر التتبّع من إصدار إنتاجي رجوعًا إلى نتائج الاختبار الأمني المحددة التي أجازته
- ملاحظات قديمة: تبقى الثغرات المحددة في الاختبار مفتوحة أشهرًا أو سنوات من دون معالجة أو تصعيد أو قبول رسمي للمخاطر
- عملية بلا إنفاذ: لدى المؤسسة وثيقة دورة حياة تطوير برمجيات آمنة لكن لا بوابات آلية ولا تحقق مستقل من اتباعها
- إهمال مرحلة المراقبة: استثمار كبير في أمن ما قبل الإنتاج لكن لا مراقبة في وقت التشغيل ولا إدارة للثغرات لتطبيقات الإنتاج
تقييم نضج دورة حياة تطوير البرمجيات
يمكن للمدققين استخدام نموذج نضج لتوصيف مدى جودة تطبيق دورة حياة تطوير البرمجيات الآمنة. ويساعد ذلك على تأطير الملاحظات والتوصيات بصورة متناسبة.
| مستوى النضج | الخصائص | تبعات التدقيق |
|---|---|---|
| ارتجالي (المستوى 1) | تُنفَّذ الأنشطة الأمنية بصورة غير متسقة، وتعتمد على المبادرة الفردية، وغير موثَّقة في السياسة. لا أتمتة. | فجوات جوهرية في الضوابط. ستكون الملاحظات كثيرة وذات دلالة. يُوصى بإرساء سياسة وحوكمة أساسية. |
| محدَّد (المستوى 2) | توجد سياسات وإجراءات. الأنشطة الأمنية موثَّقة ومُسنَدة. الأدوات موجودة لكنها قد لا تُنفَّذ باتساق. | الضوابط موجودة لكن فاعلية تشغيلها قد تكون ضعيفة. التركيز على التحقق من الاتساق في التنفيذ وجودة الأدلة. |
| مُدار (المستوى 3) | تُطبَّق الضوابط الأمنية باتساق، وتُؤتمَت حيثما أمكن، وتُراقَب عبر مقاييس. الحوكمة نشطة. | الضوابط تعمل بفاعلية. ينتقل تركيز التدقيق إلى الحالات الحدّية والاستثناءات والتحسين المستمر. |
| مُحسَّن (المستوى 4) | تحسين مستمر مبني على المقاييس. تحديد استباقي للتهديدات. الأمن مندمج تمامًا في ثقافة التطوير وأدواته. أتمتة متقدمة. | ثقة عالية في بيئة الضوابط. يتركّز التدقيق على الاستدامة والتكيّف مع التهديدات الجديدة وحوكمة القدرات المتقدمة. |
قراءات إضافية
للاطلاع على إرشادات ذات صلة، انظر:
مواد ذات صلة للمدققين
- مسرد المصطلحات — تعريفات بلغة واضحة للمصطلحات التقنية
- كيف يراجع المدققون CI/CD
- الامتثال المستمر عبر CI/CD
- ضوابط أمن CI/CD الأساسية
جديد على تدقيق CI/CD؟ ابدأ بـدليل المدقق لدينا.
