إطار عمل دورة حياة افتراضية Secure لـ OPSWAT:التزام بالمرونة والأمان الدفاعي المتعمق

تستهدف الجهات الفاعلة الخبيثة الأنظمة من أجل الربح أو التعطيل، مما يؤدي إلى تكبد المؤسسات تكاليف ومخاطر في الأعمال التجارية وتضرر سمعتها. 

ووفقًا لدراسة استقصائية حديثة، فإن تكلفة إصلاح الخلل الأمني تكون أعلى بـ 30 ضعفًا عند اكتشافه في مرحلة الإنتاج مقارنةً بمرحلة التحليل والمتطلبات.

يحدد إطار عمل دورة حياة البرمجيات Secure SDLC الخاص بـ OPSWATالمنهجيات المنظمة والمبادئ الأمنية التي توجه تطوير البرمجيات الآمنة. 

تتبع OPSWAT دورة حياة تطوير Software الرشيقة. ولكي نكون متوافقين تمامًا مع متطلبات عملائنا، اعتمدنا إطار عمل دورة حياة تطوير البرمجيات Secure SDLC وفقًا للمتطلبات التنظيمية والمعايير الدولية. ويعزز هذا النهج التزامنا بالتحسين المستمر والمرونة في مجال الأمن السيبراني المتطور.

يعتمد إطار عمل دورة حياة البرمجيات Secure SDLC الخاص OPSWATعلى إطار عمل تطويرSoftware Secure NIST SP 800-218 SSDF)، مما يضمن أن يكون الأمن منظمًا وقابلًا للقياس ومطبقًا بشكل متسق في جميع مراحل عملية تطوير البرمجيات.  

ومن خلال دمج أفضل الممارسات في مجال تطوير البرمجيات الأمنية الخاصة بأفضل الممارسات في مجال تطوير البرمجيات، يحافظ OPSWAT على وضع أمني استباقي، حيث يدمج الأمن في كل مرحلة من مراحل تطوير البرمجيات - بدءاً من التخطيط والتصميم إلى التنفيذ والتحقق والمراقبة المستمرة. 

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

مع استمرار تطور لوائح الأمن السيبراني، تظل OPSWAT ملتزمة بمواءمة إطار عمل SDLC Secure الخاص بها مع المتطلبات التنظيمية العالمية، بدءًا من قانون المرونة الإلكترونية للاتحاد الأوروبي وتوجيه NIS2. من خلال التكيف بشكل استباقي مع المعايير الناشئة، تضمن OPSWAT أن تظل دورة حياة Secure SDLC شاملة ومتوافقة ومرنة في مشهد تنظيمي متزايد التعقيد.

الحفاظ على أمن المعلومات القوي أمر بالغ الأهمية لكل من النزاهة التشغيلية والامتثال التنظيمي. يدمج إطار عمل OPSWAT الخاص بـ OPSWAT لإطار عمل SDLC Secure مبادئ نظام إدارة أمن المعلومات ISO 27001، مما يضمن دمج الضوابط الأمنية واستراتيجيات إدارة المخاطر وتدابير الامتثال بسلاسة في تشغيل منتجاتنا السحابية. 

وباعتبارها مزودًا ومستهلكًا لحلولنا الأمنية، تطبق OPSWAT سياسات أمنية مطبقة داخليًا في الشركة، مما يضمن التزام منتجاتنا المعتمدة بتوقعات الأمان على مستوى المؤسسات قبل نشرها.  

اطلع على مزيد من التفاصيل حول الامتثال والشهادات.

ولضمان أعلى معايير جودة البرمجيات، تم دمج إطار عمل دورة حياة البرمجيات Secure SDLC الخاص بشركة OPSWATفي نظام إدارة الجودة ISO 9001 (نظام إدارة الجودة). وينشئ نظام إدارة الجودة ضوابط جودة مدققة للحوكمة وإدارة التغيير والعمليات متعددة الوظائف، مما يدعم تعريف وتصميم وتطوير وإنتاج وصيانة المنتج وعروض الدعم، ويمتد إلى ما وراء البحث والتطوير ليشمل مجالات مثل المبيعات ودعم العملاء وتكنولوجيا المعلومات والموارد البشرية.  

يعزز هذا النهج التزامنا بنهج منظم قائم على المخاطر في إدارة الجودة، مما يضمن أن يظل أمن التطبيقات جزءاً لا يتجزأ من جميع وظائف الأعمال.

اطلع على مزيد من التفاصيل حول الامتثال والشهادات.

نموذج نضج ضمان أمن Software (SAMM) من OWASP هو إطار عمل شامل مصمم لمساعدة المؤسسات على تقييم وصياغة وتنفيذ استراتيجيات فعالة لأمن البرمجيات ضمن دورة حياة البرمجيات SDLC الحالية.

وباعتبارها إطار عمل مفتوح المصدر، تستفيد SAMM من المساهمات العالمية، مما يضمن نهجًا تعاونيًا ومتطورًا باستمرار لأمن التطبيقات. تتيح منهجيته المنظمة للمؤسسات طريقة فعالة وقابلة للقياس لتحليل دورة حياة التطوير وتحسينها. تدعم منهجية SAMM دورة حياة التطوير الكاملة. لا تعتمد منهجية SAMM على التكنولوجيا والعمليات. كما أن SAMM متطور وقائم على المخاطر. ومن خلال الاستفادة من منهجية SAMM، تكتسب الفرق رؤى قابلة للتنفيذ حول الثغرات الأمنية ويمكنها تحسين الوضع الأمني بشكل منهجي طوال دورة حياة التطوير.

إن معيار التحقق من أمان التطبيقات (ASVS) من OWASP هو إطار عمل معترف به عالميًا مصمم لوضع نهج منظم وقابل للقياس وقابل للتنفيذ لأمن تطبيقات الويب. وهو يزود المطورين وفرق الأمن بمجموعة شاملة من متطلبات الأمان وإرشادات التحقق لضمان تلبية التطبيقات لأفضل الممارسات في هذا المجال. 

وباعتبارها إطار عمل مفتوح المصدر، تستفيد ASVS من المساهمات الواسعة من مجتمع الأمن العالمي، مما يضمن مواكبتها للتهديدات الناشئة والمعايير الأمنية المتطورة.

يترجم برنامج دورة حياة البرمجة Secure SDLC الخاص OPSWAT برنامج دورة حياة البرمجة Secure SDLC إلى حوكمة منظمة، مما يضمن توثيق المتطلبات الأمنية والحفاظ عليها وقياسها وتحسينها باستمرار، مع ضمان حصول جميع الأطراف المعنية على التدريب المناسب. ويحدد البرنامج الأدوار والمسؤوليات والتدابير الأمنية لبيئات التطوير والاختبار والإنتاج، بالإضافة إلى أمن خطوط الأنابيب، وتحديد بيئة التطوير Secure وتفويض تطبيق السياسات الأمنية ضمن عملية دورة حياة التطوير Secure .

الإدارة رفيعة المستوى - كبير مسؤولي المنتجات (CPO)

يتولى كبير مسؤولي المنتجات (CPO) مسؤولية الإشراف الاستراتيجي على برنامج دورة حياة البرمجيات Secure SDLC وتطبيقه في جميع فرق المنتجات، بالإضافة إلى برامج البحث والتطوير الأخرى مثل برنامج ضمان الجودة (QA) وبرنامج تجربة المستخدم (UX)، مما يضمن اتباع نهج متماسك لتطوير البرمجيات الآمنة وعالية الجودة والتي تركز على المستخدم.

بصفته المالك الرئيسي للمخاطر لجميع المنتجات وعمليات البحث والتطوير، يكلف رئيس العمليات عمليات البحث والتطوير بامتلاك برنامج دورة حياة البرمجة Secure لبرمجيات التطوير المستدام الآمنة ويضمن أن قادة المنتجات يطبقون برنامج دورة حياة البرمجة Secure لبرمجيات التطوير المستدام الآمنة ويطبقون عملية دورة حياة البرمجة Secure لبرمجيات التطوير المستدام بفعالية في فرق المنتج. في هذا الدور، يوافق رئيس العمليات المركزية على تعديل برنامج دورة حياة البرمجة Secure للبرمجيات المسندة الآمنة والانحرافات عن عملية دورة حياة البرمجة Secure للبرمجيات المسندة الآمنة.

كما يراقب مسؤول حماية العملاء أيضًا نتائج برنامج SDLC Secure ويتتبع النضج الأمني، ونقاط الضعف، والامتثال، وأنشطة التطوير للحفاظ على وضع أمني قوي للمنتجات.

بالإضافة إلى ذلك، فإن رئيس العمليات المركزية مسؤول عن تخصيص ميزانية أمن البحث والتطوير والموافقة عليها، مما يضمن تخصيص الموارد الكافية لبرنامج SDLC Secure .

الأولويات الاستراتيجية

تتماشى خطة OPSWATالاستراتيجية لأمن التطبيقات مع أولويات العمل ورغبته في تحمل المخاطر، مع الأخذ في الاعتبار مستوى نضج كل منتج ومدى تعرضه للتهديدات الأمنية. ينصب التركيز الأساسي على حماية المنتجات ذات المخاطر العالية، لا سيما تلك التي لها قاعدة عملاء كبيرة أو عمليات نشر عامة أو مدمجة في البنية التحتية الحيوية.

كجزء من برنامج Secure SDLC، بالإضافة إلى تدريبات التوعية الأمنية العامة للشركة، يتم إلزام جميع الموظفين المشاركين في التطوير الآمن بتدريبات أمنية خاصة بأدوار محددة. يتم تتبع جميع التدريبات في أدوات التدريب الخاصة بالشركة. تتم مراجعة برامج التدريب والتوعية بشكل دوري لدمج الاتجاهات الأمنية الجديدة وضمان الامتثال المستمر للمعايير الأمنية.

يلتزم OPSWAT عزيز برنامج دورة حياة Secure البرمجيات SDLC بشكل مستمر من خلال قياس الأداء المنظم وتقييمات النضج والتحديثات المنتظمة لضمان الفعالية الأمنية المستمرة.  

للحفاظ على وضع أمني قوي، يستخدم OPSWAT نهجاً منهجياً لتتبع الأداء الأمني وتحسينه. ويشمل ذلك تقييمات ربع سنوية لنضج أمن المنتجات، والمراجعات الأمنية الداخلية للتحقق من الالتزام بأفضل الممارسات، وتحديد مؤشرات الأداء الرئيسية السنوية التي يتم قياسها كل ثلاثة أشهر.  

لقياس الوضع الأمني للتطبيقات بفعالية، يقيّم OPSWAT الفرق باستخدام مقاييس منظمة. يتم تقييم نضج أمن المنتج لكل فريق استناداً إلى إطار عمل إدارة أمن التطبيقات، مما يوفر مقياساً قابلاً للقياس الكمي للتقدم الأمني. وبالإضافة إلى ذلك، تخضع المنتجات لتقييم الامتثال لـ ASVS لضمان الالتزام بمتطلبات التحقق الأمني. تتم مراقبة الامتثال لعملية SDLC Secure عن كثب وتقييمها وتحقيق أهداف مؤشرات الأداء الرئيسية استنادًا إلى الأدلة، مما يضمن أن الوضع الأمني والتحسينات الأمنية قابلة للقياس وقابلة للتنفيذ. يُطلب من جميع فرق المنتجات تحقيق أهداف النضج الأمني كجزء من تقييم أدائها السنوي. 

كجزء من جهود التحسين المستمر، يقدم OPSWAT مبادرات أمنية جديدة للمنتجات بشكل دوري لزيادة مستويات النضج وتعزيز أمن التطبيقات. وتشمل هذه المبادرات تحديث السياسات الأمنية لمعالجة التهديدات الناشئة، ودمج أدوات أمنية جديدة لتعزيز الكشف والوقاية، وتوسيع أهداف مؤشرات الأداء الرئيسية لدفع عجلة التقدم المستمر. 

ولتعزيز الحوكمة الأمنية، يجري OPSWAT مراجعة سنوية لإطار عمل دورة حياة Secure للتطوير والتحليل Secure SDLC، مع دمج الرؤى المستقاة من تحليلات الأسباب الجذرية للحوادث الأمنية السابقة، وتقييمات اتجاهات الثغرات الأمنية، وتحسينات العمليات والسياسات الحالية.  

يضمن هذا النهج المنظم للتحسين المستمر أن يحافظ OPSWAT على وضع أمني استباقي ومرن للمنتجات، والتكيف بفعالية مع تحديات الأمن السيبراني المتطورة مع تلبية الأهداف الأمنية التنظيمية والتشغيلية.

تعمل عملية دورة حياة البرمجيات Secure SDLC على تفعيل برنامج دورة حياة البرمجيات Secure SDLC من خلال تحديد الضوابط الأمنية التي يجب على الفرق اتباعها، بما في ذلك أنشطة محددة مثل الفحوصات الأمنية الآلية وآليات التحقق في كل مرحلة من مراحل التطوير. تتماشى هذه العملية مع برامج البحث والتطوير الرئيسية الأخرى، مثل برنامج ضمان الجودة وبرنامج تجربة المستخدم، مما يضمن اتباع نهج متماسك لتطوير البرمجيات الآمنة وعالية الجودة التي تركز على العملاء. 

يتم تفصيل عملية SDLC Secure SDLC في الأقسام التالية:

• التصميم Secure وتقييم المخاطر
• التنفيذ والبناء والنشر Secure
• اختبار أمان التطبيقات والتحقق منها
• الإصدار Secure
• Secure العمليات والصيانة

إن عملية SDLC Secure هي عملية عالية المستوى، ويجوز للفرق تنفيذها بطريقة موسعة ومخصصة بشرط الحفاظ على أمن العملية على نفس المستوى كحد أدنى. يجب توثيق الانحراف عن عملية SDLC Secure والموافقة عليها.

يشتمل برنامج SDLC Secure على العديد من السياسات التي يجب أن تتم الموافقة عليها رسميًا والاعتراف بها من قبل فرق المنتج لضمان الامتثال لمتطلباتها. الالتزام بهذه السياسات إلزامي داخليًا، وكل فريق مسؤول عن مراجعتها والتوقيع عليها وتنفيذها كجزء من عمليات التطوير الخاصة به. 

فيما يلي قائمة بالسياسات الرئيسية إلى جانب أغراض كل منها. أما بالنسبة للسياسات ذات الأهمية الخارجية، فقد أُدرجت تفاصيل إضافية في هذه الوثيقة.

كجزء من عملية SDLC Secure يتم تتبع متطلبات الأمان وتوثيقها والحفاظ عليها طوال دورة حياة التطوير. يُطلب من البائعين الخارجيين الإقرار بمتطلبات الأمان والوفاء بها، مما يضمن الاتساق في التوقعات الأمنية والالتزام بسياسة الامتثال لخصوصية المنتج في جميع مكونات البرمجيات. 

يتم دمج الأمن في كل مرحلة من مراحل دورة حياة التطوير. تقع على عاتق أبطال الأمن مسؤولية وضع توقعات عملية دورة حياة التطوير Secure SDLC في الاعتبار وتمثيلها داخل فرقهم. 

تتضمن مجموعة متطلبات التصميم Secure متطلبات الأمان الوظيفية وغير الوظيفية المستندة إلى ASVS. يتم توفير النماذج المرجعية من قبل عمليات البحث والتطوير لدعم قرارات التصميم، إلى جانب تعديلات موثقة لمتطلبات ASVS إذا لزم الأمر (على سبيل المثال، متطلبات تشفير أقوى).

نمذجة التهديدات هي عملية منظمة لتحديد التهديدات ونقاط الضعف في المراحل الأولى من دورة حياة التطوير. وهي جزء لا يتجزأ من عملية دورة حياة التطوير Secure SDLC، ويتم إجراؤها بانتظام - مرة واحدة على الأقل في السنة أو كلما تم إدخال ميزات أو تغييرات معمارية جديدة. تقوم فرق المنتج بنمذجة التهديدات من خلال تحديد الأهداف الأمنية، وتحديد الأصول والتبعيات، وتحليل سيناريوهات الهجوم المحتملة، والتخفيف من التهديدات التي تم تحديدها.  

ويتضمن النهج المحسّن تحليل تدفق البيانات وممارسات نمذجة التهديدات الراسخة (مثل نموذج STRIDE)، مما يضمن إجراء تقييم شامل عبر المنتجات. عند الضرورة، يتم بدء مراجعات الأمان للتحقق من الامتثال لمتطلبات الأمان ومعالجة المخاطر المحتملة بشكل استباقي. يتم توثيق قرارات التصميم بعناية، ويتم تتبع أي مخاطر متبقية باستمرار طوال دورة حياة المنتج.

يتم تقييم المخاطر الأمنية للتطبيقات باستخدام مصادر متعددة، بما في ذلك التهديدات المتبقية التي تم تحديدها أثناء نمذجة التهديدات، والثغرات الأمنية المعترف بها على نطاق واسع مثل تلك الموجودة في قائمة أفضل 10 تطبيقات في OWASP وSANS Top 25، وضوابط الأمان المفقودة بناءً على إرشادات ASVS. تشمل عوامل الخطر الإضافية نقاط الضعف في إدارة الأسرار خلال عمليات الإنشاء والنشر والإصدار، بالإضافة إلى نقاط الضعف في المكونات مفتوحة المصدر ومكونات الطرف الثالث. 

بعد تقييم المخاطر، يتم وضع خطط للتخفيف من حدة المخاطر التي تم تحديدها، مع مراعاة كل من التأثير والاحتمالية. يتم توثيق هذه الخطط، إلى جانب المخاطر المقابلة وخطوات التخفيف من حدة المخاطر، توثيقًا دقيقًا. 

يتم تعقب المخاطر المتبقية طوال دورة حياة المنتج، وتخضع للمراجعة الدورية ويجب الاعتراف بها رسمياً من قبل أصحاب المخاطر. كما يتم دمجها في تقارير الإصدار الداخلي للحفاظ على الوضوح والمساءلة. 

عند الضرورة، يتم البدء في إجراء مراجعات أمنية لضمان الامتثال للمتطلبات الأمنية ومعالجة المخاطر المحتملة بشكل استباقي، مما يعزز الوضع الأمني العام للمنتج.

كجزء من عملية SDLC Secure بما في ذلك التنفيذ والبناء والنشر تهدف إلى منع الثغرات والعيوب، استنادًا إلى التصميم Secure وتقييم المخاطر. تحتوي مجموعة المتطلبات على توقعات بشأن المتطلبات الأمنية الوظيفية وغير الوظيفية القائمة على ASVS، ومنهجية التطوير والاختبار الآمنين بالاعتماد على بيئة التطوير Secure .  

أثناء التنفيذ، يجب تطبيق أفضل ممارسات الترميز Secure ومراجعة التعليمات البرمجية Secure والكشف المبكر عن الثغرات الأمنية. يجب أن تلتزم فرق العمل بسياسة أمن Supply Chain (بما في ذلك مواضيع تأهيل البائعين والبرمجيات مفتوحة المصدر) وسياسة استخدام الذكاء الاصطناعي وسياسة التعامل مع عينات البرمجيات الخبيثة. أثناء الإنشاء والنشر يجب البناء والنشر Secure مع استخدام خط أنابيب CI/CD المركزي والفصل بين الواجبات.

يجب على فرق المنتج اتباع أفضل ممارسات الترميز الآمن المستقل عن اللغة أثناء التنفيذ. ويتعين عليهم التحقق من صحة بيانات الإدخال، وتعقيم البيانات المرسلة إلى أنظمة أخرى، وإزالة تحذيرات المترجم، وتعيين رسائل الخطأ الآمنة، وتطبيق ترميز الإخراج حيثما أمكن، وتنفيذ تسجيل آمن دون تعريض البيانات الحساسة، واتباع إرشادات معالجة الأخطاء وإدارة الاستثناءات بشكل صحيح. يجب على الفرق أيضًا التأكد من أن التشفير، في حالة استخدامه، يعتمد على خوارزميات معتمدة وتوليد أرقام عشوائية آمنة، وإدارة موارد النظام بشكل آمن من خلال التعامل الآمن مع الذاكرة ومنع حالات السباق وتجنب حالات الجمود من خلال المزامنة المناسبة. 

يُنصح فرق المنتج أيضًا باتباع إرشادات الترميز الآمن الخاصة باللغة، والتي تفرضها أدوات SAST، كما هو موضح أدناه: 

بالنسبة ل Java، يجب على الفرق التأكد من أن المفاتيح المستخدمة في عمليات المقارنة غير قابلة للتغيير، واستخدام SecureRandom بدلاً من Random، وتجنب إلغاء التسلسل غير الآمن عن طريق التحقق من صحة فئات الإدخال أو تقييدها.

في لغة C++C، يوصى باكتشاف أخطاء تخصيص الذاكرة ومعالجتها، ومنع تجاوزات المخزن المؤقت من خلال التحقق من الحدود واستخدام المؤشرات الذكية مثل std::unique_ptr()، وتجنب الدوال غير الآمنة مثل strcpy() و sprintf(). 

بالنسبة إلى Python، يجب على المطورين تجنب استخدام دوال مثل eval() أو exec() للتخفيف من مخاطر حقن التعليمات البرمجية، وتفضيل صيغ التسلسل الآمنة مثل وحدة json على المخلل عند معالجة البيانات غير الموثوق بها.

كجزء من مراجعات الأمان التي تتطلبها سياسة التحقق من أمان التطبيق، تعتبر مراجعة التعليمات البرمجية الآمنة مهمة ويتم تنفيذها اعتمادًا على تقنية التطوير مع تطبيق قوائم مراجعة التعليمات البرمجية Secure المختلفة استنادًا إلى سلسلةأوراق الغش OWASP.

وفقًا لما تقتضيه سياسة التحقق من أمن التطبيقات، يعد الاكتشاف المبكر للعيوب الأمنية عنصرًا حاسمًا في عملية التطوير. ولتقليل المشاكل الأمنية المحتملة إلى أدنى حد ممكن، فإن نهج "عدم الإنشاء" إلزامي، مما يضمن عدم مرور التعليمات البرمجية غير الآمنة عبر خط الإنتاج. بالإضافة إلى ذلك، يتم تطبيق نهج "الفشل في الدمج"، مما يتطلب من الفرق معالجة أي مشكلات تم اكتشافها قبل دمج التغييرات. يعد حل العيوب المكتشفة أمرًا ضروريًا لتلبية معايير الإصدار.

كجزء من عملية SDLC Secure فإن استخدام خط أنابيب CI/CD المنسق والمركزي إلزامي لفرض عمليات الإنشاء الآمنة وتجنب هجمات سلسلة التوريد. يتم إنشاء سجلات التدقيق والبناء والنشر وحفظها ومراجعتها على النحو المحدد في سياسات أمان الشركة. 

كل فريق منتج مسؤول عن اتباع تكوينات آمنة للبناء والمترجم حيثما أمكن. يجب أن يستخدموا خيارات المحول البرمجي الآمنة، وتعطيل التعليمات البرمجية للتصحيح، وتقوية أوقات تشغيل اللغات المترجمة، وتثبيت الإصدارات التبعية، وضمان إنشاءات قابلة للتكرار، وتقوية صور الحاويات. يجب توثيق التكوينات المستخدمة ومراجعتها بشكل دوري. 

تماشياً مع مبدأ الفصل بين الواجبات، لا يمكن للمطورين وأعضاء الفريق الآخرين الذين لديهم إمكانية الوصول إلى التعليمات البرمجية أو الإنشاء الوصول إلى بيئة الإنتاج. في حالة المنتجات السحابية، يُسمح فقط لمهندسي موثوقية موقع المنتج بالنشر في بيئة الإنتاج.

وفقًا لسياسة التحقق من أمن التطبيقات لدينا، نقوم بتنفيذ التوثيق الرسمي وتتبع المشكلات المكتشفة وتعيين أدوات آلية للتحقق المستمر. كجزء من عملية SDLC Secure يتم فرض عمليات التحقق الأمني وتتبعها في كل مرحلة من مراحل SDLC لتلبية متطلبات الامتثال. والغرض منها هو العثور بكفاءة على الثغرات الأمنية المحتملة. يتم التحقيق في القضايا الأمنية الناشئة من قبل الفرق ومعالجتها ضمن الإطار الزمني. الأطر الزمنية هي جزء من مؤشرات الأداء الرئيسية الأمنية المحددة.

• مراجعات الهندسة المعمارية والتصميم: يقوم كبار المهندسين وأعضاء الفريق الافتراضي لأمن التطبيقات بتقييم الجوانب الأمنية في تغييرات التصميم، بما في ذلك التشفير والمصادقة والترخيص والتدقيق وتقوية النظام وبنية النظام والشبكة. 
• مراجعات التعليمات البرمجية: بالإضافة إلى المراجعات المنتظمة للتعليمات البرمجية من قبل المهندسين الأقران وكبار المهندسين، يقوم أعضاء الفريق الافتراضي لأمن التطبيقات بمراجعة التغييرات لمنع العيوب الشائعة مثل الحقن ومعالجة الأخطاء والتكوينات غير الآمنة.

• المسح السري لتجنب تسريب الأسرار وضمان التصميم الجيد والتنفيذ الآمن للتعامل مع الأسرار.
• أدوات SAST (اختبار أمان التطبيقات الثابتة) للكشف عن الثغرات الأمنية (مثل حقن SQL، وتجاوزات المخزن المؤقت).
• يُستخدم SCA (تحليل تكوينSoftware ) للكشف عن الثغرات البرمجية مفتوحة المصدر.
• يُستخدم اختبار أمان التطبيق الديناميكي (DAST ) للعثور على مشاكل وقت التشغيل (مثل عيوب الذاكرة) ومشاكل البيئة

الأدوات المحددة في قسم الاكتشاف المبكر للمشكلات الأمنية إلزامية للاستخدام في خط أنابيب CI/CD. يجب إصلاح جميع الثغرات الأمنية المحددة باتباع سياسة Vulnerability Management للمنتج.

يتم استخدام منهجيات اختبار الأمان المؤتمتة واليدوية على حد سواء بما يتوافق مع برنامج ضمان الجودة الذي ينفذ خطة اختبار الأمان.

• تُستخدم أدوات DAST للكشف عن الثغرات الأمنية في وقت التشغيل، واختبار التكوينات الافتراضية، واختبار مرونة النظام بعد تطبيق اقتراحات التقوية. تستهدف الاختبارات كلاً من البرمجيات والبنية التحتية الأساسية. 
• لتجنب التراجع في متطلبات وميزات الأمان، نستخدم أدوات الاختبار الآلي للتحقق باستمرار من سلامة ميزات وضوابط الأمان. 
• يتم تطبيق الاختبار اليدوي في الحالات التي تقصر فيها الأدوات المؤتمتة عن تحقيق ذلك، كما هو الحال في التحقق من ضوابط تسرب المعلومات، وتحديد عيوب منطق العمل، والثغرات السياقية. 
• يعد الفحص الآلي للبرمجيات الخبيثة للبرمجيات الخبيثة في دورة حياة التطوير جزءًا من الخطوات التي تركز على الوقاية من المشكلات الأمنية.

كجزء من عملية SDLC Secure تفرض عملية الإصدار معايير الإصدار التي تضمن الالتزام بعملية SDLC Secure وأمن المنتج بشكل عام، بناءً على النتائج التي تم التوصل إليها وفقًا لاختبار أمن التطبيقات والتحقق منها. تلعب عملية إصدار المنتج دورًا حاسمًا في الحفاظ على التحسينات الأمنية عبر الإصدارات، ومنع التراجع المتعلق بالأمن، والحفاظ على الوضع الأمني المحقق، كمتطلب أساسي لكل إصدار. 

تتضمن عملية الإصدار إصدار تقارير الإصدار الداخلية التي توثق المخاطر المتبقية وأي مشاكل أمنية عالقة. يجب أن تتم الموافقة على هذه التقارير رسمياً من قبل قائد المنتج. بالإضافة إلى ذلك، تنقل ملاحظات الإصدار الخارجي التغييرات والإصلاحات المتعلقة بالأمان كجزء من الإصدار الرسمي للمنتج. 

بالنسبة للمنتجات السحابية، يتبع النشر نهج أتمتة "فشل النشر"، مما يضمن إصدار الإصدارات الآمنة فقط. يتم دمج اختبار أمان التطبيقات والتحقق من أمانها في خط أنابيب النشر، مع استراتيجية سحب تشغيلية بدلاً من الدفع، مما يعزز التحقق من الأمان قبل نشر الإنتاج. 

وفقًا لسياسة إدارة SBOM، يتضمن كل إصدارBill of Materials (SBOM) Software Bill of Materials (SBOM) للحفاظ على إمكانية تتبع مصدر المكونات، ودعم الشفافية وأمن سلسلة التوريد. تتم أرشفة جميع ملفات الإصدارات الضرورية بشكل آمن لضمان إمكانية الوصول إليها على المدى الطويل.

ووفقًا لسياسة سلامة الإصدار، ولتعزيز سلامة وأمن إصدارات المنتجات، يتم تطبيق نظام إصدار منظم (مثل الإصدار الدلالي)، مما يضمن إمكانية تتبع واضح للتغييرات وفترة احتفاظ محددة لجميع القطع الأثرية التي تم إصدارها، بما في ذلك الوثائق. ولتعزيز الأمان بشكل أكبر، يتم توقيع القطع الأثرية للبرمجيات رقمياً باسم الشركة، مع نشر بصمات SHA التي تسمح للمستخدمين بالتحقق من صحة الإصدارات واكتشاف أي محاولات تلاعب. 

ترافق الوثائق المصدرة كل إصدار، وتوفر إرشادات مفصلة حول طرق التحقق من السلامة وإجراءات التثبيت الآمنة وأفضل ممارسات التكوين وإجراءات تقوية النظام. وتساعد هذه الموارد المستخدمين على تنفيذ ضوابط الأمان بفعالية، مما يقلل من احتمالية تعرضهم للهجوم. وبالإضافة إلى ذلك، يتم تضمين اتفاقية ترخيص المستخدم النهائي (EULA) لتحديد التزامات الامتثال والحفاظ على الشفافية القانونية. 

يتم توفير SBOM للمنتجات الفردية لعملائنا عند الطلب. اتصل بنا.

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

كجزء من حماية نقطة النهاية تتم مراقبة جميع الأجهزة المملوكة OPSWAT بحثًا عن الثغرات الأمنية والبرامج المثبتة والتصحيحات المثبتة والامتثال لسياسات الشركة الأمنية. وفي حالة عدم الامتثال، يتم اتخاذ إجراءات تقييدية للحد من الوصول إلى موارد الشركة. 

الموارد المصنفة ضمن فئة المخاطر العالية، لا يمكن الوصول إليها إلا عبر مسارات وصول محكومة (VPN). الأجهزة خارج شبكة الشركة مجبرة على استخدام قنوات آمنة للوصول إلى موارد البحث والتطوير.

يلتزم أمن خط أنابيب CI/CD بالتوجيهات الأمنية الصارمة للتخفيف من التهديدات المتطورة. قد يكون مصدر التهديدات هو عناصر البنية التحتية القديمة (مثل أنظمة التشغيل، وأدوات التحليل، وما إلى ذلك)، والوصول غير المصرح به بسبب ضعف ضوابط الامتيازات والبيئات المعزولة بشكل سيئ. إن الحفاظ على تحديث البنية التحتية لعملية CI/CD محدثة ومدققة بدقة ومحكومة بإحكام هو حجر الزاوية في دورة حياة SDLC الآمنة. 

على الصعيد الإقليمي، تُستخدم الخوادم الموجودة في الولايات المتحدة لجميع الخدمات المركزية، بما في ذلك تخزين التعليمات البرمجية، وخط أنابيب CI/CD، وأدوات التحليل والاختبار، والتوقيع الآمن على القطع الأثرية. يخضع تكوين جميع الأدوات المركزية لسيطرة عمليات البحث والتطوير. 

نحن نطبق آليات مصادقة قوية (مصادقة متعددة العوامل - MFA) وعناصر تحكم في التفويض (التحكم في الوصول المستند إلى الدور - RBAC). يتم إجراء مراجعات الوصول الأقل امتيازاً ومراجعات الوصول المنتظمة. 

تتضمن خطوط أنابيبنا العديد من أدوات التحليل وأتمتة الاختبار، بما في ذلك اختبار أمان التطبيقات الثابتة (SAST)، وتحليل تكوين Software (SCA)، واختبار أمان التطبيقات الديناميكية (DAST)، والمسح السري، ومسح البرمجيات الخبيثة. 

في حل توقيع الكود الآمن الخاص بنا، نستخدم وحدات أمان Hardware (HSMs) لحماية المواد الرئيسية من الوصول غير المصرح به وإنشاء التوقيع. ويُعد حل التوقيع جزءًا من البنية التحتية للتوقيع CI/CD، ولكن يتم تجزئة الشبكة. لا يُسمح إلا لعمليات البحث والتطوير بالوصول إلى HSMs لفترات قصيرة. يتم تسجيل كل إجراء توقيع ويمكن مراجعته من خلال سجل تدقيق. 

يجب أن تحتوي مجموعة الأدوات المستخدمة لبناء البرنامج أو تجميعه أو اختباره على معلومات عن المصدر وأن تأتي من مصدر معتمد. الأدوات المستخدمة في خط أنابيب CI/CD محدودة العدد، ويتم تثبيت الأدوات الضرورية فقط. يُسمح فقط ببرامج LTS لتجميع وبناء الخطوات في خط الأنابيب. في تشغيل الخدمات المركزية، يتم تحديد فترات الصيانة الدورية وتناوب المفاتيح. تندرج الأدوات المطورة داخلياً ضمن عملية SDLC Secure .

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

تعد حماية التعليمات البرمجية المصدرية جزءًا مهمًا من تطوير البرمجيات لضمان سرية وسلامة التعليمات البرمجية المصدرية داخل الشركة. 

يتم تخزين التعليمات البرمجية المصدرية وفقًا لمبدأ الامتيازات الأقل، مما يسمح بالوصول إلى الموظفين والأدوات المصرح لهم فقط. وتخضع الشفرة المصدرية للتحكم في الإصدار. يضمن نظام إدارة التحكم في الإصدار إمكانية تتبع تغييرات التعليمات البرمجية والمساءلة عنها. يتم تشفير مخازن التعليمات البرمجية المصدرية باستخدام تشفير متوافق مع معيار FIPS 140-3 ومحمية بمفتاح مناسب.

الامتثال لهذه السياسة إلزامي لجميع الفرق الداخلية. هذه الوثيقة تابعة لسياسات الشركة، مما يعني أنه في حالة وجود أي تعارض، تكون الأولوية لسياسات الشركة ويجب اتباعها. 

عملية التصعيد في حالة حدوث انتهاكات لسياسة تطوير البرمجيات Secure : يتم التعامل مع أي انتهاكات لهذه السياسة داخليًا، بدءًا من عمليات البحث والتطوير وتصعيدها إلى كبير مسؤولي المنتجات (CPO) حسب الضرورة.

من المتوقع أن يمتثل الموردون الذين يقدمون مكونات أو خدمات للمنتجات في نطاق ISO 27001 وSOC2 وNIST SSDF للمتطلبات الموضحة أدناه من إطار عمل SDLC Secure . يخضع الامتثال للتدقيق الأمني الدوري وتقييمات الجهات الخارجية والتزامات كل طرف بموجب العقود المنفذة. 

يُطلب من جميع البائعين تقديم معلومات المصدر والتكامل، إلى جانب الوثائق الداعمة، على النحو المحدد في قسم سلامة الإصدار. 

يجب على بائعي مكونات المنتجات والمكتبات إنشاء بيئات تطوير تتماشى مع ممارساتنا كما هو موضح في قسم بيئة التطوير Secure . يجب عليهم تطبيق اختبار الأمان على مكوناتهم ومكتباتهم، كما هو موضح في قسم اختبار أمان التطبيقات والتحقق منها. 

كما يجب على بائعي مكونات خط الأنابيب إنشاء بيئات تطوير تتماشى مع ممارساتنا كما هو موضح في قسم بيئة التطوير Secure . وبالإضافة إلى ذلك، يجب أن تتماشى عمليات التطوير الخاصة بهم مع عملية التطوير Secure SDLC الخاصة OPSWAT. 

من المتوقع أن يستخدم بائعو الخدمات بيئات مقرها الولايات المتحدة توفر وضعاً أمنياً مماثلاً لخدمات OPSWATخدمات OPSWAT. ويجب أن تشتمل دورة حياة البرمجيات الخاصة Secure الخاصة بهم على برنامج دورة حياة Secure للبرمجيات الخاصة الآمنة وعملية دورة حياة Secure للبرمجيات الخاصة الآمنة التي تعكس توقعات OPSWAT.