توصيات لتأمين دورة حياة التطوير

ينطبق على توصية قائمة التحقق من أمان Azure Well-Architected Framework هذه:

SE:02 الحفاظ على دورة حياة تطوير آمنة باستخدام سلسلة توريد برامج متصلبة، ومعظمها آلية، وقابلة للتدقيق. دمج تصميم آمن باستخدام نمذجة المخاطر للحماية من عمليات التنفيذ التي تهزم الأمان.

الدليل ذو الصلة: تحليل التهديدات

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

رسم تخطيطي لدورة الأمان.

يدمج DevSecOps الأمان في عمليات DevOps من خلال:

  • أتمتة اختبار الأمان والتحقق من الصحة.

  • تنفيذ أدوات مثل مسارات الأمان لفحص التعليمات البرمجية والبنية الأساسية كتعليق برمجي (IaC) بحثا عن الثغرات الأمنية.

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

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

التعريفات

المصطلح التعريف
دورة حياة تطوير الأمان (SDL) مجموعة من الممارسات التي توفرها Microsoft تدعم متطلبات ضمان الأمان والتوافق.
دورة حياة تطوير البرامج (SDLC) عملية منهجية متعددة المستويات لتطوير أنظمة البرامج.

استراتيجيات التصميم الرئيسية

يجب دمج تدابير الأمان في نقاط متعددة في دورة حياة تطوير البرامج الحالية (SDLC) لضمان:

  • لا تؤدي اختيارات التصميم إلى فجوات أمنية.

  • لا تنشئ التعليمات البرمجية للتطبيق وتكوينه ثغرات أمنية بسبب التنفيذ القابل للاستغلال وممارسات الترميز غير السليمة.

  • لا تقدم البرامج التي يتم الحصول عليها عبر سلسلة التوريد تهديدات أمنية.

  • لا يتم العبث بعمليات التعليمات البرمجية للتطبيق والبناء والتوزيع.

  • يتم تخفيف الثغرات الأمنية التي تم الكشف عنها من خلال الحوادث.

  • يتم إيقاف تشغيل الأصول غير المستخدمة بشكل صحيح.

  • لا يتم اختراق متطلبات التوافق أو تقليلها.

  • يتم تنفيذ تسجيل التدقيق في بيئات المطور.

توفر الأقسام التالية استراتيجيات أمان للمراحلك شائعة الممارسات من SDLC.

مرحلة المتطلبات

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

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

يجب أن تؤدي جميع هذه القرارات إلى تعريف جيد لوضع الأمان للتطبيق. توثيق المتطلبات الأمنية في مواصفات متفق عليها وتعكسها في التراكم. يجب أن يوضح صراحة الاستثمارات الأمنية والمفاضلات والمخاطر التي ترغب الشركة في اتخاذها إذا لم يوافق أصحاب المصلحة في الأعمال على الاستثمارات. على سبيل المثال، قد توثق الحاجة إلى استخدام جدار حماية تطبيق ويب (WAF) أمام التطبيق الخاص بك، مثل Azure Front Door أو بوابة تطبيق Azure. إذا لم يكن أصحاب المصلحة في الأعمال مستعدين لقبول التكلفة الإضافية لتشغيل WAF، فإنهم بحاجة إلى قبول خطر توجيه هجمات طبقة التطبيق نحو التطبيق.

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

مرحلة التصميم

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

تحديد البعد الأمني لبنية النظام

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

تقييم التكاليف التي يوفرها النظام الأساسي

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

على سبيل المثال، إذا كان تصميمك يستدعي جدار حماية تطبيق ويب عند الدخول، يمكنك إلغاء تحميل هذه المسؤولية إلى موازن تحميل مثل Application Gateway أو Azure Front Door. تجنب النسخ المتماثل للميزات كتعليق برمجي مخصص في التطبيق الخاص بك.

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

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

حدد أنماط تصميم الأمان التي يجب أن تنفذها التعليمات البرمجية للتطبيق.

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

لمزيد من المعلومات، راجع أنماط تصميم السحابة التي تدعم الأمان.

تخزين أسرار التطبيق بأمان

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

تحديد خطط الاختبار

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

ملاحظة

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

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

لمزيد من المعلومات، راجع توصيات لتحليل التهديدات.

مرحلة التطوير والاختبار

خلال هذه المرحلة، يتمثل الهدف في منع العيوب الأمنية والعبث في التعليمات البرمجية والبناء والبنية الأساسية لبرنامج ربط العمليات التجارية للتوزيع.

كن مدربا جيدا في ممارسات التعليمات البرمجية الآمنة

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

يجب أن يطلب من المطورين إكمال هذا التدريب قبل أن يتمكنوا من الوصول إلى التعليمات البرمجية لمصدر الإنتاج.

يجب عليك أيضا إجراء مراجعات التعليمات البرمجية الداخلية للنظر لتعزيز التعلم المستمر.

استخدام أدوات اختبار الأمان

قم بإجراء نمذجة المخاطر لتقييم أمان بنية التطبيق.

استخدم اختبار أمان التطبيق الثابت (SAST) لتحليل التعليمات البرمجية للثغرات الأمنية. دمج هذه المنهجية في بيئة المطور للكشف عن الثغرات الأمنية في الوقت الفعلي.

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

اتبع معايير الصناعة لممارسات الترميز الآمنة. لمزيد من المعلومات، راجع قسم موارد المجتمع في هذه المقالة.

استخدم linters وأداة تحليل التعليمات البرمجية لمنع دفع بيانات الاعتماد إلى مستودع التعليمات البرمجية المصدر. على سبيل المثال، يفحص محللات .NET Compiler Platform (Roslyn) التعليمات البرمجية للتطبيق الخاص بك.

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

استخدم مجموعة من الاختبارات. للحصول على معلومات حول اختبار الأمان بشكل عام، راجع توصيات اختبار الأمان.

كتابة تعليمات برمجية كافية فقط

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

يعد الاستفادة من ميزات Azure طريقة أخرى لمنع التعليمات البرمجية غير الضرورية. إحدى الطرق هي استخدام الخدمات المدارة. لمزيد من المعلومات، راجع استخدام خيارات النظام الأساسي كخدمة (PaaS).

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

حماية بيئات المطور

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

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

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

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

عمليات النشر الآمنة للتعليمات البرمجية

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

الاحتفاظ بمخزون محدث لكل مكون مدمج في تطبيقك

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

مهام المسار

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

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

الاحتفاظ ببيئات مختلفة منفصلة

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

التعرض التدريجي

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

مرحلة الإنتاج

تقدم مرحلة الإنتاج آخر فرصة مسؤولة لإصلاح الثغرات الأمنية. احتفظ بسجل للصورة الذهبية التي تم إصدارها في الإنتاج.

الاحتفاظ بالأدوات التي تم إصدارها

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

إصلاحات الطوارئ

يجب أن يتمتع تصميم البنية الأساسية لبرنامج ربط العمليات التجارية التلقائي بالمرونة لدعم كل من عمليات التوزيع العادية والطوارئ. هذه المرونة مهمة لدعم إصلاحات الأمان السريعة والمسؤولة.

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

ملاحظة

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

مرحلة الصيانة

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

إدارة التصحيح. حافظ على تحديث البرامج والمكتبات ومكونات البنية الأساسية مع تصحيحات الأمان والتحديثات.

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

إيقاف تشغيل الأصول القديمة التي لا معنى لها أو التي لم تعد قيد الاستخدام. يؤدي القيام بذلك إلى تقليل مساحة سطح التطبيق.

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

تحسين ممارسات الترميز الآمنة باستمرار لمواكبة مشهد التهديد.

تسهيل Azure

توصي دورة حياة تطوير الأمان من Microsoft (SDL) بالممارسات الآمنة التي يمكنك تطبيقها على دورة حياة التطوير الخاصة بك. لمزيد من المعلومات، راجع دورة حياة تطوير الأمان من Microsoft.

يتم تضمين Defender for DevOps وأدوات SAST كجزء من GitHub Advanced Security أو Azure DevOps. يمكن أن تساعدك هذه الأدوات في تعقب درجة أمان لمؤسستك.

اتبع توصيات أمان Azure الموضحة في هذه الموارد:

للعثور على بيانات الاعتماد في التعليمات البرمجية المصدر، ضع في اعتبارك استخدام أدوات مثل أدوات تحليل التعليمات البرمجية المصدرGitHub Advanced Security وOWASP.

تحقق من صحة أمان أي تعليمة برمجية مفتوحة المصدر في التطبيق الخاص بك. يمكن أن تساعدك هذه الأدوات والموارد المجانية في تقييمك:

قائمة التحقق من الأمان

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من الأمان

  • Last updated on