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

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

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

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

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

يعتمد إطار عمل دورة حياة البرمجيات 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 بالإضافة إلى تدريبات التوعية الأمنية العامة التي تقدمها الشركة، يتم فرض تدريب أمني خاص بالوظيفة على جميع الموظفين المشاركين في التطوير الآمن. يتم تتبع جميع التدريبات في أدوات التدريب الخاصة بالشركة. تتم مراجعة برامج التدريب والتوعية بشكل دوري لدمج الاتجاهات الأمنية الجديدة وضمان الامتثال المستمر لمعايير الأمان.

يلتزم 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 المنسق والمركزي إلزامي لفرض عمليات الإنشاء الآمنة وتجنب هجمات سلسلة التوريد. يتم إنشاء سجلات التدقيق والبناء والنشر وحفظها ومراجعتها على النحو المحدد في سياسات أمان الشركة. 

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

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

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

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

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

يجب استخدام أدوات في قسم الكشف المبكر عن المشكلات الأمنية بشكل إلزامي في خط أنابيب CI/CD. يجب إصلاح جميع الثغرات Vulnerability Management المحددة وفقًا 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 في خطوات التجميع والبناء في خط الأنابيب. في تشغيل الخدمات المركزية، يتم تحديد فترات الصيانة الدورية وتناوب المفاتيح. أدوات المطورة داخليًا لعملية Secure .

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

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

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

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

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

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

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

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

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

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