تساعد عمليات التطوير الرشيقة الشركات على إصدار البرامج بشكل أسرع بكثير مما يمكن أن يكون ممكنًا في حالة استخدام التصميم الكلاسيكي ودورات التطوير مثل تلك القائمة على نموذج الشلال. تتطلب معظم تطبيقات الويب منهجية رشيقة لأنها تحتاج إلى التحديث كثيرًا وبسرعة كبيرة لتلبية احتياجات العملاء.
ومع ذلك ، فإن العديد من الشركات تكافح من أجل تضمين الأمان في دورة حياة تطوير البرامج الخاصة بهم وبسبب ذلك ، قد يصبح اختبار أمان التطبيق عنق الزجاجة الرئيسي ويقوض تمامًا الجهود المستثمرة في الممارسات الرشيقة.
دعنا نلقي نظرة على بعض أفضل ممارسات SLDC الآمنة التي ستساعد فرق التطوير لديك على أن تصبح مرنة حقًا.
المحتويات
أغلق فجوة الفريق
لدى معظم الشركات التي تطور تطبيقات الويب الخاصة بها فرق تطوير برامج وفرق أمان منفصلة. تتعاون هذه الفرق من خلال القضايا المقدمة وربما بمساعدة مديري المشروع. ومع ذلك ، نادرًا ما يكون هناك اتصال أو تعاون مباشر.
إذا تم إجراء اختبارات الأمان خارج دورة أجايل ، في مراحل النشر النهائية (مثل التدريج) ، فإن هذا يؤدي أيضًا إلى توترات. قد تجد فرق الأمان مشكلات في الحظر قبل الإصدار المخطط له مباشرةً ، مما قد يتسبب في تأخيرات غير متوقعة ويمارس الكثير من الضغط على المطورين لإصلاح هذه المشكلات بسرعة. في بعض الأحيان ، قد يؤدي ذلك إلى العداء بين الفرق وتعريض المشروع بأكمله للخطر.
لذلك فإن أهم ممارسة لمنهجيات التطوير السريع هي سد فجوة الفريق بين فرق التطوير وفرق الأمان. بينما يحتاج العمل إلى فريق أمان مخصص لتطوير السياسات الأمنية ومعالجة المشكلات الأمنية خارج SDLC ، يجب أيضًا أن تضم فرق أجايل (بشكل مثالي) خبراء أمنيين.
على سبيل المثال ، في العديد من الشركات التي تتبع منهجيات Scrum ، لا يشمل فريق Agile المطورين وأصحاب المصلحة التجاريين فحسب ، بل يشمل أيضًا الكتاب التقنيين ومحللي تجربة المستخدم. لذلك ، لا يوجد سبب يمنع مثل هذه الفرق من تضمين خبير أمني أيضًا.
اجعل الأمان جزءًا من جودة التعليمات البرمجية
من المتوقع أن يعرف مطورو البرمجيات كيفية ضمان جودة كود المصدر. من الممارسات المعتادة أن يخضع كل جزء من التعليمات البرمجية المكتوبة أو المعدلة لمراجعة الكود بواسطة مطور آخر.
ومع ذلك ، عادةً لا تتضمن مراجعة الكود هذه اكتشاف الثغرات الأمنية والقضاء عليها. هذا لأنه لا منشئ الكود ولا المراجعين مدربون بشكل صحيح على التعرف على هذه الثغرات وليس لديهم أدوات آلية للتعرف عليها.
يجب أن يبدأ الوعي الأمني هنا ، مع العملية الأولية لإنشاء الكود. يجب أن يُنظر إلى ثغرة إدخال SQL في التعليمات البرمجية على أنها خطأ أساسي لا يختلف عن استخدام ملف فقاعة الفرز خوارزمية متى فرز سريع متاح.
لذلك ، تتمثل أفضل الممارسات في اختبار كل مطور في الشركة لمعرفة معرفته بالثغرات الأمنية التي قد يتم إدخالها في التعليمات البرمجية. إذا تم العثور على نقص في هذا الصدد ، فيجب أن يتلقوا تدريبًا متخصصًا لتعليمهم كيفية التعرف على نقاط الضعف المحتملة وتجنبها وكذلك إصلاحها في التعليمات البرمجية للأشخاص الآخرين. يجب أن تختبر عمليات التوظيف التي تتضمن اختبارًا لقدرات المطور على كتابة برامج عالية الجودة المعرفة بنقاط الضعف الأمنية.
لم يترك أي تطبيق وراء
غالبًا ما تتعامل المنظمات الكبيرة مع الآلاف من مشاريع التطوير المختلفة في نفس الوقت. يتم تنفيذ هذه المشاريع الكبيرة من قبل وحدات تنظيمية مختلفة ، في كثير من الأحيان في بلدان مختلفة. في مثل هذه البيئات ، من الشائع أن تعمل فرق DevOps بشكل مستقل وهناك مساحة صغيرة لنموذج SDLC موحد. يؤدي هذا إلى قيام بعض الفرق بتبني ممارسات آمنة طوال دورة حياة تطوير البرامج بالكامل بينما يقوم البعض الآخر بإصدار تطبيقاتهم بدون اختبار أمان على الإطلاق ، مما يترك بعض التطبيقات معرضة للخطر بشدة.
حتى إذا أرادت إحدى المؤسسات توحيد عملية تطوير التطبيقات واختبارها ونشرها على مستوى العالم ، فغالبًا ما يتم إعاقتها من خلال الاختلافات في الأساليب التي تتبعها فرق معينة. على سبيل المثال ، يمكن كتابة التطبيقات باستخدام لغات وأطر عمل و IDE مختلفة تمامًا ، وإدارتها باستخدام أدوات CI / CD مختلفة وتتبع المشكلات. قد يقوم فريق واحد في بلد ما بتطوير تطبيقات Java باستخدام Jira و Jenkins بينما قد يقوم فريق آخر بالبرمجة بلغة PHP ويستخدم GitHub لكل من تتبع المشكلات و CI / CD.
في مثل هذه الظروف ، قد يكون من الصعب للغاية إدخال اختبار أمان آلي مشترك في مرحلة اختبار SDLC. لا يتطلب هذا فقط العديد من الأساليب المختلفة ، ولكن إذا أرادت المنظمة استخدام SAST و SCA ، فقد يكون من المستحيل ببساطة استخدام نفس الأدوات لكل فريق. وهذا بدوره يتطلب تدفقات عمل إدارية منفصلة ، مما يعرض المزيد من المشاكل المحتملة.
الحل الوحيد القابل للتطبيق في مثل هذه الحالات هو استخدام اختبار أمان التطبيق الديناميكي (DAST) ، وهو اختبار مستقل عن اللغة ويسهل دمجه في خطوط أنابيب CI / CD. هذا هو السبب في أننا نوصي ببدء جهود SDLC الآمنة الخاصة بك من DAST ، وليس من SAST أو SCA. وعند اختيار حل DAST الخاص بك ، تأكد من اختيار حل مصمم ليتم تضمينه في SDLC – مثل Acunetix.
احصل على أحدث محتوى حول أمان الويب
في بريدك الوارد كل أسبوع.
المؤلف
كاتب المحتوى الفني
ينكدين
Tomasz Andrzej Nidecki (المعروف أيضًا باسم tonid) هو كاتب محتوى تقني يعمل في Acunetix. صحفي ومترجم وكاتب تقني يتمتع بخبرة 25 عامًا في مجال تكنولوجيا المعلومات ، وكان توماسز مدير التحرير لمجلة hakin9 IT Security في سنواتها الأولى ، وكان يستخدم لتشغيل مدونة تقنية كبرى مخصصة لأمن البريد الإلكتروني.
