SDLC الآمن بوصفه إطار ضوابط
كثيراً ما يُقدَّم دورة حياة تطوير البرمجيات الآمنة (Secure SDLC) بوصفها منهجية تطوير — سلسلة من الممارسات التي تتبعها فرق الهندسة لبناء برمجيات أكثر أماناً. غير أن المدققين ومسؤولي الامتثال يجب أن يُقيِّموها من منظور أعمق وأكثر جوهرية: بوصفها إطار ضوابط.
تمثل كل مرحلة من مراحل SDLC نقطة ضبط ينبغي فيها وقوع أنشطة أمنية محددة وتوليد أدلة محددة والتحقق من نتائج محددة. حين تدّعي مؤسسة ما تشغيل SDLC آمن، يجب على المدققين تجاوز وثائق العمليات وتقييم ما إذا كانت الضوابط تعمل فعلياً في كل مرحلة.
يستعرض هذا الدليل كل مرحلة من مراحل SDLC من منظور المدقق، مُحدِّداً ما يجب أن يحدث، والأدلة المطلوب طلبها، وشكل الممارسة الجيدة، وما يجب أن يثير القلق.
مرحلة التخطيط (PLAN)
ما يجب أن يحدث
يُدمَج النظر الأمني في تخطيط المشروع قبل بدء أي تطوير. يشمل ذلك النمذجة التهديدية لتحديد ناقلات الهجوم المحتملة، وتحديد متطلبات الأمن جنباً إلى جنب مع المتطلبات الوظيفية، وتصنيف التطبيق وفق إطار تصنيف المخاطر في المؤسسة.
الأدلة المطلوب طلبها
- وثائق النمذجة التهديدية (مخططات تدفق البيانات وتحديد التهديدات وقرارات التخفيف)
- متطلبات الأمن الموثَّقة في backlog المشروع أو مستودع المتطلبات
- سجل تصنيف مخاطر التطبيق مع الموافقة عليه
- سجلات مشاركة الأمن في جلسات التخطيط
ملامح الممارسة الجيدة
- إنشاء نماذج تهديد لجميع تطبيقات المستوى 1 والمستوى 2 وتحديثها عند تغيير البنية المعمارية
- قابلية تتبع متطلبات الأمن — لكل تهديد مُحدَّد في النموذج متطلب مقابل أو مخاطرة مقبولة
- التصنيف يقود متطلبات الضوابط اللاحقة (تكرار الاختبار وسير عمل الموافقة)
- مشاركة موظفي الأمن في أنشطة التخطيط، موثَّقة بسجلات الاجتماعات
ملامح الممارسة السيئة
- غياب نماذج التهديد، أو إنشاؤها مرة واحدة دون تحديث
- متطلبات الأمن عامة (“يجب أن يكون التطبيق آمناً”) بدلاً من كونها محددة وقابلة للاختبار
- تصنيف التطبيق مفقود أو أُجري دون مدخلات الأمن أو الامتثال
- لا يُستعان بالأمن إلا في مرحلة الاختبار أو النشر
مرحلة الترميز (CODE)
ما يجب أن يحدث
يتبع المطورون معايير ترميز آمن موثَّقة. تخضع تغييرات الكود لمراجعة بحثاً عن مشكلات أمنية — سواء من خلال مراجعة الأقران مع مراجعين على دراية بالأمن، أو عبر الاختبار الآلي لأمن التطبيقات الساكنة (SAST). تمنع مسح الأسرار إيداع بيانات الاعتماد ومفاتيح API والرموز المميزة في المستودعات.
الأدلة المطلوب طلبها
- وثيقة معايير الترميز الآمن، معتمدة وخاضعة للتحكم بالإصدارات
- سجلات مراجعة الكود التي تُظهر تعليقات وحلولاً ذات صلة بالأمن
- نتائج SAST المُدمَجة في سير عمل التطوير
- إعداد مسح الأسرار وسجلات التنبيه
- سجلات تدريب المطورين على ممارسات الترميز الآمن
ملامح الممارسة الجيدة
- تشغيل SAST آلياً على كل pull request أو commit بحيث تكون النتائج مرئية للمطورين
- تُظهر سجلات مراجعة الكود تحديد نتائج أمنية ومعالجتها — لا مراجعة وظيفية فحسب
- مسح الأسرار يحجب عمليات الإيداع التي تحتوي على بيانات اعتماد، مع عملية موثَّقة لتدوير أي أسرار مكشوفة
- يتلقى المطورون تدريباً سنوياً (كحد أدنى) على الترميز الآمن ذا الصلة بمجموعة التقنيات التي يستخدمونها
ملامح الممارسة السيئة
- تشغيل SAST يدوياً أو قبيل الإصدارات فحسب، مما يتيح تراكم الثغرات
- وجود مراجعات للكود لا تتضمن قط تغذية راجعة ذات صلة بالأمن
- غياب مسح الأسرار، أو تجاهل التنبيهات
- معايير الترميز الآمن متقادمة أو غير متوافقة مع التقنيات المستخدمة
مرحلة البناء (BUILD)
ما يجب أن يحدث
تتضمن عملية البناء تحليل تكوين البرمجيات (SCA) لتحديد الثغرات في تبعيات الطرف الثالث ومفتوحة المصدر. يُولَّد SBOM لكل عملية بناء للحفاظ على جرد لجميع المكونات. توقيع مخرجات البناء يضمن سلامتها ويمنع التلاعب.
الأدلة المطلوب طلبها
- نتائج SCA لعمليات البناء الأخيرة، تُظهر الثغرات المُحدَّدة ومآلاتها
- سجلات SBOM للإصدارات الإنتاجية
- إعداد توقيع المخرجات وسجلات التحقق
- سياسة حدود الثغرات المقبولة في التبعيات
ملامح الممارسة الجيدة
- تشغيل SCA على كل عملية بناء مع سياسات محددة لحجب البناءات التي تحتوي على ثغرات حرجة أو عالية الخطورة
- توليد SBOMs آلياً وتخزينها بجانب سجلات الإصدار
- فرض توقيع المخرجات — لا يمكن نشر مخرجات غير موقَّعة في الإنتاج
- وجود عملية للترقيع الطارئ للثغرات الحرجة في التبعيات
ملامح الممارسة السيئة
- SCA غير مُدمَج في عملية البناء أو يُشغَّل دورياً فحسب
- غياب توليد SBOM — المؤسسة لا تستطيع تحديد المكونات الموجودة في الإنتاج
- غياب توقيع المخرجات — لا توجد وسيلة للتحقق من أن المخرجات المنشورة مطابقة للبناءات المعتمدة
- وجود ثغرات حرجة معروفة في التبعيات في الإنتاج دون قبول موثَّق للمخاطر
مرحلة الاختبار (TEST)
ما يجب أن يحدث
يُجرى اختبار أمن التطبيقات الديناميكي (DAST) على التطبيقات الجارية لتحديد الثغرات التي لا يستطيع التحليل الساكن اكتشافها (عيوب المصادقة ومشكلات الإعداد وثغرات الحقن في وقت التشغيل). يوفر اختبار الاختراق من قِبَل كوادر مؤهلة منظوراً هجومياً. بيئات الاختبار معزولة عن الإنتاج للحيلولة دون تسرب البيانات.
الأدلة المطلوب طلبها
- نتائج DAST وسجلات المعالجة
- تقارير اختبار الاختراق مع النطاق والمنهجية والنتائج وحالة المعالجة
- أدلة على عزل البيئة (مخططات الشبكة وضوابط الوصول)
- سجلات تُظهر أن تكرار الاختبار متوافق مع مستوى مخاطر التطبيق
ملامح الممارسة الجيدة
- تشغيل DAST آلياً بالتكرار المحدد في تصنيف مخاطر التطبيق
- إجراء اختبار الاختراق من قِبَل مختبِرين مستقلين مؤهلين (داخليين أو خارجيين) بنطاق محدد
- بيئات الاختبار لا تحتوي على بيانات إنتاجية، أو بيانات الإنتاج مُخفاة هويتها بشكل مناسب
- تتبع نتائج الاختبار حتى التحقق من معالجتها
ملامح الممارسة السيئة
- عدم إجراء DAST، أو تجاهل نتائجه
- إجراء اختبار الاختراق من الفريق ذاته الذي بنى التطبيق، دون استقلالية
- احتواء بيئات الاختبار على بيانات إنتاجية غير مُخفاة الهوية
- بقاء نتائج الاختبار مفتوحة إلى أجل غير مسمى دون تصعيد
مرحلة الإصدار (RELEASE)
ما يجب أن يحدث
تخضع الإصدارات لسير عمل موافقة تتحقق من اكتمال جميع الأنشطة الأمنية المطلوبة. تفرض بوابات السياسة في pipeline التسليم استيفاء متطلبات الأمن قبل انتقال الكود إلى الإنتاج. قرارات الإصدار موثَّقة كجزء من إدارة التغييرات.
الأدلة المطلوب طلبها
- سجلات موافقة الإصدار التي تُظهر موافقة الأمن حيثما كانت مطلوبة
- نتائج بوابات السياسة من pipeline التسليم (سجلات النجاح/الفشل مع الطوابع الزمنية)
- سجلات إدارة التغييرات التي تربط الإصدارات بنتائج الاختبارات الأمنية
- سجلات الاستثناءات لأي إصدارات تجاوزت بوابات السياسة
ملامح الممارسة الجيدة
- بوابات السياسة آلية ومفروضة — الـ pipeline يمنع الإصدار إن لم تُستوفَ معايير الأمن
- موافقة الأمن إلزامية لتطبيقات المستوى 1 والمستوى 2، مع موافقة موثَّقة
- تجاوز البوابات يستلزم موافقة رسمية على الاستثناء ويُتتبَّع
- سجلات الإصدار مرتبطة بنتائج فحص محددة ونتائج اختبار بعينها
ملامح الممارسة السيئة
- غياب بوابات السياسة — اختبار الأمن استشاري فحسب
- وجود بوابات لكنها تُتجاوز كثيراً دون موافقة رسمية
- موافقات الإصدار تُشير إلى اختبارات أمنية دون ربطها بنتائج محددة
- الاستخدام الروتيني لإجراءات الإصدار الطارئة للتحايل على الضوابط المعتادة
مرحلة النشر (DEPLOY)
ما يجب أن يحدث
تُسجَّل عمليات النشر بتفصيل كافٍ لتحديد ما نُشر ومتى ومن قِبَل مَن وإلى أي بيئة. يُتحقَّق من الإعداد مقابل خطوط الأمان. بيئات الإنتاج تطابق الإعدادات التي خضعت للاختبار.
الأدلة المطلوب طلبها
- سجلات النشر مع الطوابع الزمنية ومعرّفات المخرجات وهوية مُنفِّذ النشر والبيئة المستهدفة
- سجلات التحقق من الإعداد (فحوصات خط الأمان)
- أدلة على تكافؤ البيئة بين الاختبار والإنتاج
- سجلات التراجع حين يُعكَس النشر
ملامح الممارسة الجيدة
- عمليات النشر آلية ومُسجَّلة وقابلة للتدقيق — النشر اليدوي إلى الإنتاج محظور أو يستلزم موافقة استثنائية
- اكتشاف الانحراف في الإعداد يُنبِّه على الانحرافات عن خطوط الأمان
- البنية التحتية كـ كود أو ما يعادلها يضمن تكافؤ البيئات
- توثيق النشريات الفاشلة والتراجعات مع تحليل السبب الجذري
ملامح الممارسة السيئة
- نشريات يدوية دون مسار تدقيق
- غياب التحقق من الإعداد — تُفتَرض إعدادات الأمن لا تُتحقَّق
- فوارق جوهرية بين بيئتي الاختبار والإنتاج
- منح وصول النشر على نطاق واسع دون قيود قائمة على الأدوار
مرحلة المراقبة (MONITOR)
ما يجب أن يحدث
تُراقَب تطبيقات الإنتاج للرصد الأمني والسلوك الشاذ والثغرات الجديدة. آليات الحماية أثناء التشغيل تكشف التهديدات النشطة وتستجيب لها. عملية الإفصاح عن الثغرات تُتيح للباحثين الخارجيين الإبلاغ عن المشكلات بمسؤولية.
الأدلة المطلوب طلبها
- إعداد المراقبة الأمنية وسجلات التنبيه
- سجلات اكتشاف الحوادث والاستجابة لها المتعلقة بالتطبيقات
- سياسة الإفصاح عن الثغرات (متاحة للعموم)
- سجلات الثغرات المُبلَّغ عنها عبر قنوات الإفصاح ومآلاتها
- سجلات نشر أدوات أمن وقت التشغيل
ملامح الممارسة الجيدة
- المراقبة الأمنية على مستوى التطبيق نشطة، مع توجيه التنبيهات إلى فريق عمليات الأمن
- إجراءات الاستجابة للحوادث تُعالج تحديداً الحوادث على مستوى التطبيق (ليس البنية التحتية فحسب)
- سياسة الإفصاح عن الثغرات منشورة، والتقارير تُصنَّف وتُتتبَّع
- الثغرات المُفصَح عنها حديثاً في التبعيات تُطلِق إعادة التقييم عبر SCA
ملامح الممارسة السيئة
- غياب المراقبة على مستوى التطبيق — مراقبة البنية التحتية فحسب هي ما هو مطبَّق
- غياب عملية الإفصاح عن الثغرات — التقارير الخارجية ليس لها قناة استقبال
- معالجة حوادث الأمن المتعلقة بالتطبيقات بشكل ارتجالي دون إجراءات موثَّقة
- غياب عملية للاستجابة للثغرات المُفصَح عنها حديثاً في التبعيات
ملخص: الضوابط والأدلة والمؤشرات التحذيرية حسب المرحلة
| المرحلة | الضابط الرئيسي | أداة الإثبات | أين تجدها | المؤشر التحذيري |
|---|---|---|---|---|
| التخطيط | النمذجة التهديدية | وثيقة نموذج التهديد | الويكي، مستودع التصميم، سجل المخاطر | غياب نماذج التهديد أو عدم تحديثها |
| الترميز | SAST / مراجعة الكود | نتائج الفحص وسجلات المراجعة | سجلات CI/CD pipeline، أداة مراجعة الكود | SAST غير مُدمَج أو نتائجه متجاهَلة |
| البناء | SCA / SBOM | نتائج فحص التبعيات، ملفات SBOM | نظام البناء، مستودع المخرجات | غياب جرد المكونات للإنتاج |
| الاختبار | DAST / اختبار الاختراق | تقارير الفحص، تقارير الاختبار | أدوات الاختبار الأمني، أرشيف التقارير | غياب الاختبار الديناميكي أو الاستقلالية |
| الإصدار | بوابات السياسة / الموافقة | نتائج البوابات وسجلات الموافقة | سجلات الـ pipeline، نظام إدارة التغييرات | تجاوز البوابات دون موافقة |
| النشر | تسجيل النشر | سجلات النشر، فحوصات الإعداد | منصة النشر، أدوات المراقبة | نشريات يدوية بلا مسار تدقيق |
| المراقبة | المراقبة أثناء التشغيل | سجلات التنبيه، سجلات الحوادث | SIEM، منصة المراقبة، نظام التذاكر | غياب المراقبة على مستوى التطبيق |
نتائج التدقيق الشائعة عبر مراحل SDLC
استناداً إلى نتائج التدقيق النموذجية في المؤسسات الخاضعة للتنظيم، أبرز النتائج المتكررة هي:
- التغطية غير المتسقة: تُطبَّق ضوابط الأمن على بعض التطبيقات دون سواها دون مبرر موثَّق للتمييز
- فجوات الأدلة: الضوابط موصوفة في السياسة لكن أدلة تنفيذها ناقصة أو مفقودة — ولا سيما للنمذجة التهديدية ومراجعة كود الأمن
- قطع قابلية التتبع: يتعذر تتبع إصدار إنتاجي وصولاً إلى نتائج الاختبارات الأمنية المحددة التي أجازته
- النتائج المتقادمة: ثغرات مُكتشَفة في الاختبار تظل مفتوحة لأشهر أو سنوات دون معالجة أو تصعيد أو قبول رسمي للمخاطر
- عملية بلا إنفاذ: المؤسسة لديها وثيقة Secure SDLC لكن لا توجد بوابات آلية ولا تحقق مستقل من الاتباع
- إهمال مرحلة المراقبة: استثمار كبير في الأمن قبل الإنتاج دون مراقبة أثناء التشغيل أو إدارة ثغرات للتطبيقات الإنتاجية
تقييم نضج SDLC
يمكن للمدققين استخدام نموذج نضج لتوصيف مدى جودة تطبيق SDLC الآمن. يُساعد ذلك في تأطير النتائج والتوصيات بشكل متناسب.
| مستوى النضج | الخصائص | التداعيات على التدقيق |
|---|---|---|
| ارتجالي (المستوى 1) | الأنشطة الأمنية تُنفَّذ بشكل متذبذب، وتعتمد على المبادرة الفردية، وغير موثَّقة في السياسة. لا أتمتة. | فجوات ضوابط جوهرية. النتائج ستكون كثيرة وبالغة الأثر. يُوصى بوضع سياسة وحوكمة أساسيتين. |
| محدَّد (المستوى 2) | السياسات والإجراءات موجودة. الأنشطة الأمنية موثَّقة ومُسنَدة. الأدوات موجودة لكن قد لا تُطبَّق باتساق. | الضوابط موجودة لكن فاعليتها التشغيلية قد تكون ضعيفة. التركيز على التحقق من الاتساق في التنفيذ وجودة الأدلة. |
| مُدار (المستوى 3) | الضوابط الأمنية مُطبَّقة باتساق وآلية قدر الإمكان ومُراقَبة عبر المقاييس. الحوكمة نشطة. | الضوابط تعمل بفاعلية. تنتقل بؤرة التدقيق إلى الحالات الهامشية والاستثناءات والتحسين المستمر. |
| مُحسَّن (المستوى 4) | تحسين مستمر قائم على المقاييس. تحديد استباقي للتهديدات. الأمن مندمج كلياً في ثقافة التطوير والأدوات. أتمتة متقدمة. | ثقة عالية في بيئة الضوابط. بؤرة التدقيق تتحول نحو الاستدامة والتكيف مع التهديدات الجديدة وحوكمة القدرات المتقدمة. |
قراءة إضافية
للاطلاع على توجيهات ذات صلة، راجع:
ذو صلة للمدققين
- المسرد — تعريفات بلغة مبسطة للمصطلحات التقنية
- كيف يراجع المدققون بيئات CI/CD
- الامتثال المستمر عبر CI/CD
- ضوابط أمن CI/CD الأساسية
هل أنت جديد على تدقيق CI/CD؟ ابدأ بـدليل المدقق.
