منهجية تطوير آمن معتمدة
سياسة التطوير الآمن، ومعيار البرمجة الآمنة، ومعيار أمن التطبيقات، معتمدة ومربوطة بالمكوّن 1-6 من الضوابط الأساسية والقسم 3.3.6 من إطار ساما.
تطبيق DevSecOps
أطلق برمجياتك، والأمن جزء من بنائها
تدمج ليمـاز قرارات الأمن وفحوصه وأدلته في عمل الفرق الهندسية، من تصميم البرمجيات وبنائها إلى إطلاقها وتشغيلها.
أمن يواكب مسار التسليم ولا يعطّله
منهجية DevSecOps ليست مجموعة أدوات فحص، بل قرارات وضوابط وحلقات تغذية راجعة ومسؤوليات موزّعة على دورة التسليم، تمكّن الفرق من معالجة المخاطر دون أن يتحول كل إصدار إلى استثناء.
ننطلق من دورة التطوير الحالية وملف المخاطر، ثم نضيف أصغر ضابط فعّال في النقطة التي يمنع فيها المشكلة أو يختصر معالجتها.
ما ننفّذه
- نموذج التسليم الآمن
- الأدوار، ومستويات المخاطر، ومعايير الإصدار، وصلاحية الاستثناء، ومتطلبات الأدلة.
- ضوابط التصميم
- نمذجة التهديدات، ومراجعة المعمارية، والمتطلبات الأمنية، وتحليل سيناريوهات إساءة الاستخدام.
- ضوابط الشفرة والاعتماديات
- الفحص الساكن للشفرة (SAST)، وتحليل مكونات البرمجيات، وقواعد التراخيص، ونتائج واضحة قابلة للمعالجة.
- أمن الأسرار والمسار
- إدارة بيانات الاعتماد، والمتغيرات المحمية، وصلاحيات منفّذات المسار، وسلامة مخرجات البناء، وضوابط الفروع.
- اختبار التطبيقات
- الفحص الديناميكي (DAST)، واختبار واجهات البرمجة (API)، وفحص الحاويات وقوالب البنية التحتية كرمز.
- البوابات والمعالجة
- عتبات مبنية على المخاطر، ومسؤوليات، ومستويات خدمة للمعالجة، واستثناءات، وإعادة اختبار، ودليل إقفال.
- المقاييس والتسليم
- مؤشرات تقيس التغطية وسلامة المعالجة، مع إجراءات تشغيل موثّقة لفرق الهندسة والأمن.
متطلبات الهيئة وساما وPCI DSS للتطوير الآمن
تنص الأطر التنظيمية في المملكة صراحةً على التطوير الآمن. فالضابط 1-6-3 من الضوابط الأساسية للأمن السيبراني (ECC-2:2024) الصادرة عن الهيئة الوطنية للأمن السيبراني يشترط في مشاريع تطوير البرمجيات استخدام معايير التطوير الآمن للبرمجيات، واعتماد مصادر موثوقة ومرخّصة لأدوات التطوير ومكتباته، واختبار البرمجيات للتحقق من التزامها بمتطلبات الأمن السيبراني للجهة، وتأمين التكامل بين التطبيقات، ومراجعة الإعدادات والتحصين وحزم التحديثات قبل الإطلاق. ويضيف الضابط 1-6-2 تقييم الثغرات ومعالجتها في كل مشروع وكل تغيير.
ويشترط الإطار التنظيمي للأمن السيبراني من البنك المركزي السعودي (SAMA CSF) في القسم 3.3.6 الخاص بأمن التطبيقات أن يسير التطوير وفق منهجية معتمدة لدورة حياة تطوير الأنظمة الآمنة (Secure SDLC). ويجب أن يغطي معيار أمن التطبيقات: التطوير الآمن، وإعدادات الأمان والسجلات، وإدارة الهويات والصلاحيات، وفصل المهام بمصفوفة صلاحيات موثّقة، وحماية البيانات وفق تصنيفها، وإدارة الثغرات والتحديثات، والنسخ الاحتياطي والاستعادة، والمراجعة الدورية للالتزام.
وفي مدفوعات البطاقات يذهب المتطلب 6 من معيار أمن بيانات بطاقات الدفع (PCI DSS v4.0.1) أبعد من ذلك: تطوير آمن قائم على معايير الصناعة (6.2.1)، وتدريب المطورين على البرمجة الآمنة مرة كل 12 شهراً على الأقل (6.2.2)، ومراجعة الشفرة قبل الإطلاق (6.2.3)، وقائمة بالبرمجيات المطوّرة داخلياً ومكوّناتها الخارجية (6.3.2)، وحل آلي أمام تطبيقات الويب المتاحة للعموم يكشف الهجمات ويمنعها (6.4.2).
وتقدّم مؤسسة OWASP التفاصيل الهندسية. فقائمة OWASP Top 10:2025 حلّت محل إصدار 2021، وأبقت ضعف التحكم في الوصول (Broken Access Control) في المرتبة الأولى، وأضافت إخفاقات سلسلة إمداد البرمجيات (Software Supply Chain Failures) في المرتبة الثالثة. ويحوّل معيار التحقق من أمن التطبيقات (ASVS 5.0.0) الصادر في مايو 2025 المخاطر إلى متطلبات قابلة للاختبار على ثلاثة مستويات تحقق. ويقيس نموذج نضج ضمان البرمجيات (SAMM v2) البرنامج كاملاً عبر خمس وظائف: الحوكمة، والتصميم، والتنفيذ، والتحقق، والتشغيل.
الأمن داخل مسار التسليم
- نمذجة التهديدات
- تُجرى في مرحلة التصميم للأنظمة الجديدة والتغييرات الجوهرية. يرسم الفريق تدفقات البيانات وحدود الثقة وسيناريوهات إساءة الاستخدام، ثم يدرج المتطلبات الأمنية في قائمة الأعمال. وهذه مرحلة التصميم في دورة التطوير الآمن التي يتوقعها القسم 3.3.6 من إطار ساما.
- الفحص الساكن لأمن التطبيقات (SAST)
- يفحص الشفرة المصدرية مع كل طلب دمج بحثاً عن ثغرات الحقن وضعف التشفير وخلل التحكم في الوصول، وهي أنواع الهجمات التي يسمّيها المتطلب 6.2.4 في PCI DSS. وتظهر النتائج داخل طلب الدمج نفسه، حيث يعالجها المطوّر بأسرع ما يمكن.
- تحليل مكونات البرمجيات (SCA)
- يفحص المكتبات مفتوحة المصدر بحثاً عن الثغرات المعروفة ومخالفات التراخيص، ويُصدر قائمة مكونات البرمجيات (SBOM). وبذلك يلبّي شرط الضوابط الأساسية باعتماد مصادر موثوقة ومرخّصة، وقائمة البرمجيات التي يطلبها المتطلب 6.3.2 في PCI DSS.
- كشف الأسرار
- يمنع إيداع الشفرة التي تحتوي على مفاتيح أو رموز وصول أو كلمات مرور، ويفحص سجل المستودع بحثاً عن أسرار مكشوفة سابقاً. وتنتقل بيانات اعتماد المسار إلى خزنة، وتصبح قصيرة العمر.
- الفحص الديناميكي لأمن التطبيقات (DAST)
- يختبر التطبيق وواجهاته البرمجية أثناء التشغيل في بيئة ما قبل الإنتاج، ليكشف ما لا يظهر إلا وقت التشغيل: خلل المصادقة، وإدارة الجلسات، وترويسات الأمان الناقصة، وأخطاء إعداد الخوادم.
- فحص البنية التحتية كرمز (IaC)
- يطابق قوالب Terraform وملفات Kubernetes وقوالب السحابة مع معايير التحصين قبل النشر، فيُكتشف خطأ الإعداد في المراجعة لا في بيئة الإنتاج.
- فحص صور الحاويات
- يفحص الصور الأساسية والصور المبنية بحثاً عن حزم مصابة بثغرات، ويفرض استخدام صور أساسية معتمدة، ويوقّع الصور رقمياً ليقتصر النشر على المخرجات الموثّقة.
بوابات أمان لا تبطئ الإطلاق
البوابة التي توقف كل عملية بناء عند كل ملاحظة تُعطَّل خلال شهر. تنجح البوابات حين توقف ما يستحق الإيقاف فقط، وتعطي المطورين ملاحظات سريعة ودقيقة.
نصنّف التطبيقات حسب المخاطر: الأنظمة المتاحة عبر الإنترنت ومسارات الدفع والأنظمة التي تحفظ بيانات العملاء تخضع لبوابات صارمة، والأدوات الداخلية لبوابات أخف. وتوقف كل بوابة الإصدار في حالات محددة: ثغرة جديدة حرجة أو عالية في الشفرة المعدّلة، أو سر مكشوف، أو ثغرة معروفة الاستغلال في مكتبة مستخدمة، أو تغيير في قوالب البنية التحتية يفتح وصولاً عاماً. أما الملاحظات القائمة فتنتقل إلى قائمة متابعة لها مهلة محددة، دون أن توقف الإصدار.
تعمل الفحوص السريعة مع كل طلب دمج خلال دقائق، وتعمل الفحوص الكاملة والفحص الديناميكي ليلاً أو قبل الإطلاق. والاستثناء متاح، لكن لكل استثناء مالكاً وسبباً وضوابط تعويضية واعتماداً من الجهة المخوّلة وتاريخ انتهاء، ويُعاد فتحه تلقائياً عند انتهاء مدته.
والضبط الدقيق لا يقل أهمية عن الأداة. نعالج النتائج الخاطئة مركزياً، ونربط كل قاعدة بطريقة إصلاح مع مثال من الشفرة، ونتابع نسبة عمليات البناء المتوقفة لتحافظ البوابة على ثقة فرق الهندسة.
مهل معالجة الثغرات
- متطلبات الجهات التنظيمية
- يشترط الضابط 2-10-3 من الضوابط الأساسية تصنيف الثغرات حسب خطورتها ومعالجتها وفق هذا التصنيف والمخاطر المرتبطة بها. ويشترط القسم 3.3.17 من إطار ساما الخاص بإدارة الثغرات تحديد مهل للمعالجة لكل تصنيف، ووتيرة فحص مبنية على المخاطر.
- المرجع في PCI DSS
- يشترط المتطلب 6.3.3 تثبيت التحديثات الأمنية الحرجة والعالية خلال شهر واحد من صدورها. وهو سقف عملي للثغرات الحرجة في جميع الأنظمة، لا في بيئة بيانات حاملي البطاقات وحدها.
- تحديد المهل
- حدّد مهلة معالجة لكل مستوى خطورة، واجعلها أقصر للأنظمة المتاحة عبر الإنترنت والأنظمة الحرجة. واحسب المهلة من لحظة الاكتشاف، لا من فتح التذكرة. ثم ضع الجدول في معيار إدارة الثغرات واعتمده من إدارة الأمن السيبراني.
- المسؤولية
- تذهب كل ملاحظة إلى الفريق المالك للشفرة أو الأصل، مرفقة بإرشادات الإصلاح. يضع فريق الأمن السياسة ويتابع التقدم، ويتولى فريق الهندسة الإصلاح.
- الاستثناءات
- الملاحظة التي تتجاوز مهلتها تحتاج إلى قبول للمخاطر من مالك مخوّل، مع ضوابط تعويضية وتاريخ انتهاء. وتُرفع الملاحظات المتأخرة التي لم يُقبل خطرها في تقارير الإدارة.
- القياس
- تابِع متوسط زمن المعالجة لكل مستوى خطورة، ونسبة الملاحظات المغلقة ضمن مهلتها، والثغرات الحرجة المفتوحة لكل تطبيق، وعمر المخاطر المقبولة. هذه الأرقام تثبت للفاحص أن العملية فعّالة.
أدلة الامتثال للهيئة وساما
يطلب الفاحص دليلاً على أن الضوابط تعمل، ولا يكتفي بوجود الأدوات. والمسار المُدار جيداً ينتج هذه الأدلة تلقائياً أثناء العمل.
نماذج التهديدات والمتطلبات
مخرجات التصميم للأنظمة الجديدة والتغييرات الكبيرة، مع ربط كل متطلب أمني بمهمة في قائمة الأعمال.
سجل الفحوص
نتائج SAST وSCA وDAST وفحص البنية التحتية والحاويات لكل إصدار، مع قرار البوابة موثّقاً.
سجلات المعالجة
كل ملاحظة بخطورتها ومالكها وتاريخ اكتشافها وتاريخ إغلاقها ونتيجة إعادة الاختبار، مقيسةً على المهلة المحددة.
سجل الاستثناءات
كل خطر مقبول بمبرّره ومعتمِده وضوابطه التعويضية وتاريخ انتهائه.
سجلات التغيير والبيئات
دليل على مرور تغييرات الإنتاج بالمراجعة والاعتماد، وعلى فصل بيئة ما قبل الإنتاج عن بيئة الإنتاج بضوابط وصول مطبّقة (PCI DSS 6.5.3).
سجلات التدريب
تدريب المطورين على البرمجة الآمنة مرة كل 12 شهراً على الأقل، كما يشترط المتطلب 6.2.2 في PCI DSS.
مراحل التطبيق
نطبّق DevSecOps على مراحل، لتواصل فرق الهندسة الإطلاق طوال فترة التطبيق.
تقييم الوضع الحالي
نرسم مسارات النشر والمستودعات والبيئات وعملية الإطلاق كما هي، ونحصر التطبيقات ونرتّبها حسب المخاطر، ونقيس حجم الثغرات المتراكمة.
السياسات والمعايير
نكتب منهجية التطوير الآمن، ومعيار البرمجة الآمنة، ومعايير البوابات، وجدول المهل، وإجراء الاستثناءات، ثم نعتمدها لتكتسب صفة الإلزام.
التجربة الأولى
نفعّل الفحص على تطبيقين أو ثلاثة تمثّل بيئتك، في وضع الإبلاغ دون إيقاف. نضبط القواعد، ونزيل الضوضاء، ونتفق مع الفرق على عتبات البوابات.
التفعيل الإلزامي
نحوّل البوابات إلى وضع الإيقاف للثغرات الجديدة الحرجة والعالية، بدءاً بالتطبيقات الأعلى خطورة، وننقل أسرار المسار إلى خزنة.
التوسّع
نضم بقية المستودعات عبر قوالب مسار مشتركة، فيرث كل مشروع جديد الضوابط تلقائياً.
التشغيل والتحسين
نرفع تقريراً شهرياً عن الالتزام بالمهل والتغطية والاستثناءات، ونعيد الملاحظات المتكررة إلى التدريب ومعايير البرمجة، ونقيّم البرنامج وفق نموذج OWASP SAMM لتحديد الأهداف التالية.
فجوات شائعة نكتشفها
- أدوات فحص تعمل، ونتائجها في لوحة متابعة بلا مالك.
- فحص ساكن يغطي المستودع الرئيسي، بينما تبقى الخدمات المصغّرة وتطبيقات الجوال وقوالب البنية التحتية بلا فحص.
- غياب قائمة البرمجيات وقائمة المكونات (SBOM)، فتستغرق كل ثغرة جديدة في مكتبة أياماً من البحث اليدوي.
- أسرار في سجل المستودعات، ومتغيرات مسار يقرؤها كل مشروع، ومفاتيح سحابية طويلة العمر على خوادم البناء.
- بوابات مضبوطة لإيقاف كل شيء، ثم تُعطَّل مع أول ضغط على موعد إطلاق.
- مهل معالجة مكتوبة في السياسة دون متابعة، فتبقى الثغرات الحرجة المتأخرة خارج علم الإدارة.
- شفرة الموردين والجهات المتعاقدة تُطلق دون الفحص والمراجعة المطبّقين على الشفرة الداخلية.
- بيانات وحسابات اختبار باقية في بيئة الإنتاج، وهو ما يمنعه المتطلب 6.5.6 في PCI DSS.
خدمات أمنية ذات صلة
تنفيذ الضوابط الأمنية
تكاملات الأمن المؤسسي خارج مسار تسليم البرمجيات.
تطبيق IAM وPAM
الوصول، وهويات الخدمات، والحسابات المميّزة، ومسارات مراجعة الصلاحيات.
الجاهزية لشهادة ISO 27001
نربط أدلة التطوير الآمن بنظام إدارة أمن المعلومات (ISMS).
الجاهزية لمعيار PCI DSS
نؤمّن برمجيات الدفع وبيئة بيانات حاملي البطاقات.
أسئلة شائعة
منهجية DevSecOps تدمج الأمن في كل مرحلة من تسليم البرمجيات، بدلاً من اختبار واحد قبل الإطلاق. تبدأ المتطلبات الأمنية من التصميم عبر نمذجة التهديدات، ثم تعمل الفحوص الآلية داخل مسار التكامل والنشر المستمر (CI/CD): فحص الشفرة، وفحص المكتبات وتراخيصها، وكشف الأسرار، وفحص البنية التحتية والحاويات، والاختبار الديناميكي. وتصل النتائج مباشرة إلى المطورين المالكين للشفرة، مع مهل واضحة للإصلاح.
نعم. يشترط الضابط 1-6-3 من الضوابط الأساسية للأمن السيبراني (ECC-2:2024) استخدام معايير التطوير الآمن، واعتماد مصادر موثوقة ومرخّصة لأدوات التطوير ومكتباته، واختبار البرمجيات للتحقق من التزامها بمتطلبات الأمن السيبراني للجهة، وتأمين التكامل بين التطبيقات، ومراجعة الإعدادات والتحصين قبل الإطلاق. ويضيف المكوّن 2-15 ضوابط لتطبيقات الويب الخارجية، منها جدار حماية تطبيقات الويب، والمعمارية متعددة المستويات، والبروتوكولات الآمنة مثل HTTPS.
يشترط القسم 3.3.6 من الإطار التنظيمي للأمن السيبراني الصادر عن البنك المركزي السعودي أن تحدد الجهة معايير أمن التطبيقات وتعتمدها وتطبّقها، وأن تراقب الالتزام بها وتقيس فعاليتها. ويجب أن يسير التطوير وفق منهجية معتمدة لدورة حياة تطوير الأنظمة الآمنة، وأن يغطي المعيار البرمجة الآمنة، وإعدادات الأمان والسجلات، وإدارة الوصول، وفصل المهام بمصفوفة صلاحيات، وحماية البيانات وفق تصنيفها، وإدارة الثغرات والتحديثات، والنسخ الاحتياطي، والمراجعة الدورية.
الفحص الساكن (SAST) يقرأ الشفرة المصدرية قبل تشغيلها ليكشف ثغرات مثل الحقن وضعف التشفير. والفحص الديناميكي (DAST) يهاجم التطبيق أثناء تشغيله من الخارج ليكشف مشكلات وقت التشغيل مثل خلل المصادقة وأخطاء الإعداد. أما تحليل مكونات البرمجيات (SCA) فيفحص المكتبات مفتوحة المصدر التي يعتمد عليها التطبيق بحثاً عن الثغرات المعروفة ومخالفات التراخيص. والمسار الناضج يجمع الثلاثة، لأن كلاً منها يكشف ما يفوت غيره.
اعتمد قائمة OWASP Top 10:2025 للتوعية بالمخاطر، فهي تحل محل إصدار 2021 وتضيف فئتين جديدتين: إخفاقات سلسلة إمداد البرمجيات، وسوء التعامل مع الحالات الاستثنائية. واعتمد معيار ASVS 5.0.0 الصادر في مايو 2025 مرجعاً للمتطلبات القابلة للاختبار، مع اختيار مستوى التحقق حسب خطورة التطبيق. واستخدم نموذج OWASP SAMM v2 لقياس نضج البرنامج كاملاً وتخطيط خطوات التحسين التالية.
تشترط الضوابط الأساسية للأمن السيبراني معالجة الثغرات وفق تصنيف خطورتها والمخاطر المرتبطة بها، ويشترط القسم 3.3.17 من إطار ساما تحديد مهل للمعالجة لكل تصنيف. لذلك تضع كل جهة جدول مهلها وتلتزم به. ويقدّم المتطلب 6.3.3 في PCI DSS الرقم المحدد الوحيد: تثبيت التحديثات الأمنية الحرجة والعالية خلال شهر من صدورها. واجعل المهل أقصر للأنظمة المتاحة عبر الإنترنت والأنظمة الحرجة، وتابِع كل استثناء بتاريخ انتهاء.
البوابات المصمّمة جيداً تحافظ على وتيرة الإطلاق. تعمل الفحوص السريعة مع كل طلب دمج خلال دقائق، وتعمل الفحوص الكاملة ليلاً أو قبل الإطلاق. وتوقف البوابات الإصدار عند الثغرات الجديدة الحرجة والعالية والأسرار المكشوفة وأخطاء الإعداد الخطرة فقط، وتنتقل الملاحظات القائمة إلى قائمة متابعة. ويتسلّم المطور نتائج دقيقة داخل طلب الدمج، وهذا أسرع من معالجة تقرير اختبار اختراق بعد الإطلاق بأسابيع.
هل لديك متطلب تريد تنفيذه؟
شاركنا النظام أو الضابط أو المتطلب التنظيمي، وسنعود إليك بخطوة تالية واضحة.