إطار عمل OPSWAT Secure : التزام بالمرونة والأمن متعدد الطبقات

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

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

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

OPSWAT دورة حياة Software المرنة (Agile). ومن أجل الامتثال التام العملاء قمنا بتكييف إطار عمل Secure مع المتطلبات التنظيمية والمعايير الدولية. ويُعزز هذا النهج التزامنا بالتحسين المستمر والمرونة في بيئة الأمن السيبراني المتغيرة باستمرار.

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

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

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

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

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

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

انظر المزيد من التفاصيل حول الامتثال الاعتمادات.

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

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

انظر المزيد من التفاصيل حول الامتثال الاعتمادات.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

يتم تفصيل عملية دورة حياة تطوير البرمجيات Secure ) في الأقسام التالية:

• Secure وتقييم المخاطر
• Secure والتطوير، والنشر
• اختبار أمان التطبيقات والتحقق منها
• Secure
• Secure والصيانة Secure

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

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

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

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

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

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

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

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

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

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

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

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

يهدف «عملية Secure » ( Secure )، التي تشمل مراحل التنفيذ والتجميع والنشر، إلى منع الثغرات والعيوب، استنادًا إلى Secure » و«تقييم المخاطر». وتتضمن مجموعة المتطلبات توقعات بشأن متطلبات الأمان الوظيفية وغير الوظيفية المستندة إلى معيار ASVS، ومنهجية التطوير والاختبار الآمنة التي تعتمد على «بيئة Secure ».  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

كجزء من عملية Secure ، تفرض عملية الإصدار معايير الإصدار التي تضمن الالتزام بعملية 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 ) OPSWAT. 

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