التطوير الآمن للبرمجيات Lifecycle (SSDLC)

ليس SSDLC مشروعًا إضافيًا، بل انضباطًا في العمليات: تُحدَّد المتطلبات والأنشطة والمسؤوليات الأمنية عبر جميع مراحل تطوير البرمجيات – من المتطلبات مرورًا بالتصميم والتنفيذ والاختبار والإصدار حتى التشغيل. والفكرة الأساسية هي منع الثغرات الأمنية أو اكتشافها في أبكر وقت ممكن، لأن معالجتها تصبح أكثر كلفة مع كل مرحلة لاحقة («Shift Left»). تبقى الاختبارات الأمنية المتفرقة قبيل الإصدار مهمة، لكنها لا تفحص سوى النتيجة؛ بينما يعالج SSDLC أيضًا الأسباب في العملية. والنهج مستقل عن نموذج التطوير ويمكن دمجه في المؤسسات التقليدية وكذلك في مؤسسات Agile أو DevOps.

يصف Secure Software Development Framework الصادر عن NIST (SP ⁦800-218⁩، الإصدار 1.1، النهائي منذ فبراير 2022) 19 ممارسة مع 42 مهمة في أربع مجموعات: «Prepare the Organization» (PO) و«Protect the Software» (PS) و«Produce Well-Secured Software» (PW) و«Respond to Vulnerabilities» (RV). تتضمّن كل ممارسة أمثلة تنفيذ ومراجع إلى معايير أخرى، لكنها مصاغة عمدًا بشكل محايد تجاه التقنيات والمنهجيات – وبذلك يصلح SSDF لغةً مشتركة بين التطوير والأمن والمشتريات. ومنذ 17 ديسمبر 2025 تتوفّر أيضًا مسودة الإصدار 1.2 (SP 800-218r1، Initial Public Draft؛ انتهت مهلة التعليق في 30 يناير 2026)؛ وهي ليست نهائية بعد ويجب بالتالي التعامل معها كنظرة مستقبلية فقط.

لتطوير الذكاء الاصطناعي التوليدي وما يُسمّى Dual-Use Foundation Models نشرت NIST في يوليو 2024 الملحق SP 800-218A («Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile»). يوسّع ملف Community Profile ممارسات SSDF بمهام وتوصيات ومراجع خاصة بالذكاء الاصطناعي لكامل دورة حياة تطوير النماذج – مثلًا للتعامل مع بيانات التدريب ومخرجات النماذج. ويستهدف المؤسسات التي تطوّر نماذج الذكاء الاصطناعي أو تدمجها في الأنظمة أو تشتريها، وقد صُمّم صراحةً للاستخدام المشترك مع SP 800-218.

بينما يصف SSDF ما يجب فعله، يجيب OWASP Software Assurance Maturity Model (SAMM، الإصدار 2 منذ يناير 2020، والإصدار الحالي 2.2 من يوليو 2024) عن مدى جودة قيام المؤسسة بذلك فعلًا. ينقسم النموذج إلى خمس وظائف أعمال – Governance وDesign وImplementation وVerification وOperations – لكلّ منها ثلاث ممارسات أمنية (15 إجمالًا)، تُقيَّم كلٌّ منها عبر مسارين (Streams) وثلاثة مستويات نضج. صُمّم SAMM صراحةً كنموذج قابل للقياس ويرصد جودة الأنشطة إلى جانب مدى تغطيتها؛ ويمكن من النتيجة استخلاص خارطة طريق تحسين مرتّبة حسب الأولوية. توفّر VamiSec تقييمًا ذاتيًا وفق SAMM على ssdlc-assessment.com.

البوابات الأمنية (Security Gates) هي معايير محدّدة مسبقًا يجب أن يستوفيها المشروع قبل الانتقال إلى المرحلة التالية – وهذا تحديدًا ما تشترطه ممارسة SSDF رقم PO.4 («Define and Use Criteria for Software Security Checks»). ومن البوابات النموذجية: متطلبات أمنية موثّقة في مرحلة المتطلبات (PO.1)، ونموذج تهديدات في التصميم (PW.1)، وإرشادات البرمجة الآمنة وفحوص مؤتمتة مثل SAST وSoftware Composition Analysis في التنفيذ (PW.5، PO.3)، ومراجعات الشيفرة والاختبارات الأمنية قبل الإصدار (PW.7، PW.8)، إضافة إلى مخرجات بناء وإصدار محمية بسلامة قابلة للإثبات (PS.1، PS.2). وفي التشغيل يُغلق الدائرةَ التحديدُ المستمر للثغرات الأمنية وترتيبها حسب الأولوية وتحليل أسبابها الجذرية (RV.1–RV.3). وتُصاغ معايير البوابات الفعّالة بشكل قابل للقياس – مثلًا عبر نسبة البوابات المجتازة، أو الوقت حتى معالجة الثغرات المكتشفة، أو تكرار ظهور فئات الثغرات نفسها؛ ويرسّخ SAMM هذا التوجيه في ممارسة «Strategy & Metrics».

يجعل قانون المرونة السيبرانية (Cyber Resilience Act) (اللائحة (EU) 2024/2847، السارية منذ ديسمبر 2024) من SSDLC فعّال التزامًا على الشركات المصنِّعة للمنتجات ذات العناصر الرقمية: يحدّد الملحق I الجزء I متطلبات خصائص المنتج (من بينها Security by Design والإعدادات الافتراضية الآمنة استنادًا إلى تقييم للمخاطر)، ويحدّد الجزء II متطلبات معالجة الثغرات الأمنية – بما في ذلك إعداد Software Bill of Materials (SBOM). وتخضع الثغرات الأمنية المستغلّة فعليًا والحوادث الجسيمة لالتزام الإبلاغ اعتبارًا من 11 سبتمبر 2026 (إنذار مبكر خلال 24 ساعة، ومعلومات إضافية خلال 72 ساعة، وتقرير نهائي بعد 14 يومًا أو شهر واحد)؛ وتصبح اللائحة سارية بالكامل اعتبارًا من 11 ديسمبر 2027. ويجب توفير التحديثات الأمنية على مدى فترة دعم مدتها خمس سنوات في العادة – ويصعب إثبات ذلك بشكل موثوق دون عمليات موثّقة للتطوير ومعالجة الثغرات.