سياسة دورة حياة تطوير البرمجيات الآمنة

Control 16
الإجراءات الوقائية المعنية: 16.1 16.2 16.3 16.4 16.5 16.6 16.7 16.8 16.9 16.10 16.11 16.12 16.13 16.14

1. الغرض

وضع متطلبات لدمج الأمان عبر دورة حياة تطوير البرمجيات لمنع واكتشاف ومعالجة الثغرات الأمنية في التطبيقات المطورة والمكتسبة من [ORGANIZATION].

2. النطاق

تنطبق هذه السياسة على جميع البرمجيات المطورة أو المخصصة أو المكتسبة من قبل [ORGANIZATION]، بما في ذلك التطبيقات الداخلية وتطبيقات الويب وواجهات برمجة التطبيقات وتطبيقات الأجهزة المحمولة والبرامج النصية المنشورة في بيئات الإنتاج.

3. السياسة

3.1 متطلبات أمان دورة حياة تطوير البرمجيات

3.1.1

يجب على [ORGANIZATION] دمج الأنشطة الأمنية في كل مرحلة من مراحل دورة حياة تطوير البرمجيات: المتطلبات (متطلبات الأمان ونمذجة التهديدات) والتصميم (مراجعة الهندسة الآمنة وأنماط التصميم الأمني) والتطوير (معايير البرمجة الآمنة ومراجعة الشفرة من قبل الأقران) والاختبار (اختبار الأمان وفحص الثغرات) والنشر (إجراءات النشر الآمن ومراجعة التكوين) والصيانة (إدارة التصحيحات والمراقبة المستمرة).

3.1.2

يجب توثيق عملية دورة حياة تطوير البرمجيات الآمنة وإبلاغها لجميع فرق التطوير.

3.1.3

يجب تحديد متطلبات الأمان لكل تطبيق بناءً على تصنيف البيانات وتقييم المخاطر.

3.2 ممارسات البرمجة الآمنة

3.2.1

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

3.2.2

يجب تطوير الشفرة لمنع فئات الثغرات الشائعة بما في ذلك: هجمات الحقن (SQL والأوامر وLDAP) والبرمجة عبر المواقع (XSS) وتزوير طلبات عبر المواقع (CSRF) وإلغاء التسلسل غير الآمن والمصادقة المعطلة وكشف البيانات الحساسة.

3.2.3

يجب تتبع المكتبات والمكونات الخارجية في قائمة مواد البرمجيات (SBOM) ومراقبتها بحثاً عن الثغرات الأمنية المعروفة.

3.2.4

يُحظر تضمين بيانات الاعتماد ومفاتيح API والأسرار مباشرة في شفرة المصدر. يجب إدارة الأسرار من خلال حلول إدارة الأسرار المعتمدة.

3.3 اختبار الأمان

3.3.1

يجب دمج اختبار أمان التطبيقات الثابت (SAST) في خط أنابيب CI/CD وإجراؤه على جميع الشفرة قبل الدمج في الفرع الرئيسي.

3.3.2

يجب إجراء اختبار أمان التطبيقات الديناميكي (DAST) على جميع تطبيقات الويب على الأقل [CUSTOMIZE: quarterly/monthly] وقبل كل إصدار رئيسي.

3.3.3

يجب استخدام تحليل تكوين البرمجيات (SCA) لتحديد الثغرات في المكونات والمكتبات الخارجية.

3.3.4

يجب إجراء اختبار الاختراق على التطبيقات الحيوية على الأقل [CUSTOMIZE: annually] من قبل مختبرين مؤهلين.

3.3.5

يجب معالجة الثغرات الأمنية المحددة من خلال الاختبار وفقاً لاتفاقيات مستوى الخدمة الخاصة بسياسة إدارة الثغرات.

3.4 أمان النشر

3.4.1

يجب أن تتبع عمليات النشر في بيئة الإنتاج عملية موثقة وقابلة للتكرار باستخدام أتمتة CI/CD حيثما أمكن.

3.4.2

لا يجوز للمطورين الوصول المباشر إلى بيئات الإنتاج. يجب أن يتم النشر من خلال خطوط أنابيب آلية أو من قبل موظفي العمليات المعينين.

3.4.3

يجب أن تكون بيئات الإنتاج منفصلة عن بيئات التطوير والاختبار والتجهيز مع عدم مشاركة بيانات الاعتماد.

3.4.4

يجب توثيق واختبار إجراءات التراجع عن النشر لكل تطبيق حيوي.

4. الامتثال

4.1

الامتثال لهذه السياسة إلزامي لجميع الموظفين ضمن نطاقها. سيتم مراقبة الامتثال من خلال عمليات التدقيق الدورية والضوابط الآلية ومراجعة الإدارة.

4.2

يجب توثيق الاستثناءات من هذه السياسة مع مبرر عمل، والحصول على موافقة [CUSTOMIZE: CISO/فريق الأمن]، ومراجعتها سنوياً على الأقل.

5. الإنفاذ

5.1

قد تؤدي مخالفات هذه السياسة إلى إجراء تأديبي يصل إلى إنهاء التوظيف أو العقد، وقد تؤدي إلى عقوبات مدنية أو جنائية في حال مخالفة القانون المعمول به.

5.2

تحتفظ [ORGANIZATION] بالحق في تدقيق الامتثال لهذه السياسة في أي وقت، بإشعار أو بدونه.

6. المراجعة والتنقيح

6.1

تُراجع هذه السياسة سنوياً على الأقل من قبل [CUSTOMIZE: CISO/مالك السياسة] وتُحدث حسب الحاجة لتعكس التغييرات في مشهد التهديدات أو المتطلبات التنظيمية أو الهيكل التنظيمي.

6.2

يجب توثيق جميع المراجعات برقم الإصدار والتاريخ والمؤلف ووصف التغييرات.

اعتماد السياسة

اعتمد من قبل

[CUSTOMIZE]

المسمى الوظيفي

[CUSTOMIZE]

التاريخ

[CUSTOMIZE]

التحكم في المستند

الإصدار: [CUSTOMIZE: 1.0]
تاريخ السريان: [CUSTOMIZE]
آخر مراجعة: [CUSTOMIZE]
المراجعة القادمة: [CUSTOMIZE]
التصنيف: داخلي