DevSecOps هي ممارسة تدمج العمل الذي تقوم به فرق التطوير (Dev) ، والأمن (Sec) ، وفرق عمليات تكنولوجيا المعلومات (Ops) لتقديم ممارسات تطوير البرامج الأكثر كفاءة وفعالية. لكن لماذا لا يزال نادرًا جدًا؟ دعونا نلقي نظرة على الصعوبات التي تواجه تنفيذ DevSecOps وطرق القضاء عليها.
المحتويات
لماذا DevOps وليس DevSecOps؟
DevOps هي ممارسة تهدف في الغالب إلى مواكبة الممارسات المرنة لدورة حياة تطوير البرامج (SDLC). الهدف الرئيسي هو تقديم البرامج في دورات قصيرة وفعالة وأتمتة أكبر قدر ممكن من عملية التطوير وعملية تسليم البرامج. من الصعب تخيل تطوير برمجيات رشيقة بدون أتمتة شاملة لعمليات البناء والاختبار ، أي بدون خطوط أنابيب التكامل / التسليم المستمر (CI / CD) التي تشكل أساس DevSecOps.
لن يكون من الممكن الحصول على DevOps إذا ظلت عمليات الإنشاء والاختبار التي تشكل جزءًا من دورة التطوير يدوية. ومع ذلك ، في النهج الأصلي لـ DevOps ، يبدو أن لا أحد قد فكر في التحقق تلقائيًا من أمان التطبيق كجزء من الاختبار. ماذا قد يكون السبب؟
يتضمن خط أنابيب DevOps CI / CD النموذجي الخطوات التالية:
- توفير بيئة معدة مسبقًا (مثل حاوية Docker)
- بناء التطبيق
- نشر التطبيق في بيئة معدة مسبقًا
- إجراء اختبارات آلية على التطبيق المترجم للتأكد من أنه يفي بالمتطلبات (على سبيل المثال ، اختبارات السيلينيوم UI)
يبدو من المنطقي فقط إضافة خطوة إضافية إلى خط الأنابيب هذا:
- إجراء اختبارات أمان آلية على التطبيق المترجم للتأكد من أنه يلبي متطلبات الأمان.
ولكن ليس هذا هو الحال في معظم بيئات DevOps – وهذا هو السبب في أنها ليست عمليات DevSecOps.
أسباب عدم وجود DevSecOps
دعونا نفحص الأسباب التي تجعل المؤسسات التي تنفذ عمليات DevOps بنجاح غالبًا لا تتضمن أي ممارسات أمنية في عمليات DevOps الخاصة بها.
السبب 1. نقص الوعي الأمني
إنها فكرة مخيفة ، لكننا نعتقد أن العديد من المؤسسات لا تُدرج ضوابط أمنية في عمليات DevOps الخاصة بها لمجرد أنها لا تعتقد أن أمان التطبيق مهم بدرجة كافية.
تمتلك العديد من المنظمات وعيًا محدودًا بالأمن السيبراني وتدركه من خلال منظور الضجيج الإعلامي حول برامج الفدية والتصيد الاحتيالي. في حين أنه من الصحيح أن برامج الفدية والتصيد الاحتيالي يمثلان تهديدات أمنية كبيرة ولا يوجد شيء يمكنك القيام به في مسارات التطوير للتخفيف من هذه المخاطر الأمنية ، فإن هذا ليس كل ما يتعلق بالأمان.
لا تدرك المؤسسات أحيانًا أنه بالإضافة إلى الهندسة الاجتماعية ، يمكن للقراصنة ذوي القبعات السوداء بسهولة استغلال ثغرة أمنية في أحد التطبيقات للوصول إلى البيانات الحساسة أو حتى التحكم في التطبيق أو الخادم بأكمله. يمكن أن يؤدي هذا إلى مزيد من الهجمات ، بما في ذلك برامج الفدية المخيفة. إذا كان مخترق القبعة السوداء قادرًا ، على سبيل المثال ، على تنفيذ تعليمات برمجية عن بُعد باستخدام التطبيق الخاص بك وتثبيت غلاف عكسي ، فسيكون قادرًا على تنفيذ الأوامر على الخادم ، ولنقل ، نشر برامج الفدية التي ستنتشر في بيئتك بأكملها وتحدث الخراب التام. وفي مثل هذه الحالة ، يكون السبب الأساسي هو الافتقار إلى أمان التطبيق ولن تساعدك أي حماية من برامج الفدية والتصيد الاحتيالي.
لذلك ، فإن الخطوة الأولى والأكثر أهمية نحو DevSecOps هي إشراك الجميع وتعزيز المسؤولية المشتركة ، خاصة بين صانعي القرار. يجب أن يدركوا أن الكود الآمن له أهمية قصوى. يجب أن يدعموك في رحلة DevSecOps الخاصة بك.
السبب 2. عدم وجود فهم أمني
غالبًا ما تعمل فرق الأمن في صوامع لأن عملها غير مفهوم على الإطلاق. المصطلح الأمان يشمل نطاقًا واسعًا بشكل لا يصدق. يختلف تأمين مؤسستك من خلال تنفيذ إجراءات مراقبة الامتثال ونشر الوعي اختلافًا كبيرًا عن تأمين تطبيقاتك من خلال اختبار الاختراق العميق. يتطلب مهارات مختلفة تمامًا. وحتى المجالات التي تبدو ذات صلة مثل أمان الشبكة وأمن التطبيقات مختلفة تمامًا وتتطلب مهارات وأدوات مختلفة ونهجًا مختلفًا في سياسات الأمان.
يؤدي عدم الفهم إلى اعتبار المهام الأمنية “ذلك الشيء الذي نتحقق منه في النهاية” بدلاً من “ذلك الشيء الذي نتحقق منه أثناء تطويرنا وتقديمه”. يأتي العديد من المتخصصين في مجال الأمن في المؤسسات الحالية من خلفية أمان الشبكة ولا يفهمون حقًا مفهوم أمان التطبيق. إنهم لا يرون أن DevSecOps يمكن تحقيقه لمجرد أنهم يفكرون أساسًا في أمان الشبكة – وليس شيئًا تحتاج إلى مراعاته أثناء تطوير التطبيق.
مرة أخرى ، إنها فكرة مخيفة أن العديد من المنظمات تفضل البقاء في الظلام بشأن الأمن ، دون التفكير في السبب الرئيسي للعديد من الانتهاكات الأمنية الكبيرة. خذ فقط اختراق Capital One الشهير لعام 2019 كمثال.
السبب 3. نقص معرفة أتمتة الأمان
لا يزال يُنظر إلى أمن المعلومات على أنه عملية يدوية. تعتقد العديد من المؤسسات أن الجزء الأساسي من اختبار أمان التطبيق هو اختبار الاختراق اليدوي. غالبًا ما يرتبط عمل مختبري الاختراق بأدوات يدوية بحتة تساعدهم ، على سبيل المثال ، طلبات التخزين المؤقت وإرسال الحمولات.
ومع ذلك ، فقد تجاوزت خدمات أمان البرامج الاختبار اليدوي. تمامًا مثل مهندسي أمان الشبكات ، لا يرسلون أوامر يدوية عبر Telnet ولكنهم يستخدمون الماسحات الضوئية الآلية ، يستخدم مهندسو أمان التطبيقات الحديثة أدوات آلية لاكتشاف المشكلات الأكثر شيوعًا. إنه الخيار المنطقي بالنسبة لهم ، لأنهم بعد ذلك يمكنهم التركيز على التعمق أكثر في الثغرات الأمنية المتقدمة – وهو الأمر أيضًا بالنسبة لمعظم مهندسي الأمن أكثر إرضاءً من التحقق من إدخال SQL أساسي آخر.
تمامًا كما استبدل اختبار واجهة المستخدم الآلي الاختبار اليدوي بالكامل تقريبًا باستثناء الحالات الخاصة ، فقد حل المسح الآلي للثغرات الأمنية محل غالبية اختبارات الاختراق اليدوي – ولكن لا تزال اختبارات الاختراق تُجرى للمشكلات التي لا يمكن اكتشافها تلقائيًا. يعد اختبار الأمان يدويًا في الصومعة حديثًا مثل النقر يدويًا عبر واجهة المستخدم للتطبيق بدلاً من استخدام السيلينيوم.
السبب 4. عدم الثقة في أدوات الأمن
حتى إذا كانت إحدى المؤسسات تقدر أهمية أمان التطبيق وكان صانعو القرار على أتم الاستعداد ، فلا تزال هناك مشكلة واحدة تعيق DevSecOps: القدرات المحدودة للعديد من الأدوات.
تخيل خط أنابيب DevOps مع الاختبارات الآلية التي غالبًا ما تفشل على الرغم من أن التطبيق الذي تم اختباره صحيح بالفعل. تخيل كم من الوقت سيستغرقه المطورون للعودة إلى كود التطبيق ، ومراجعته ، والتأكد من أن كل شيء على ما يرام ، ثم اتصل بفريق تطوير الاختبار لتصحيح الاختبارات الآلية حتى لا يفشلوا (أو ببساطة ، إن أمكن) ، ضع علامة على الاختبارات يدويًا كما تم اجتيازها). وتخيلوا الإحباط إذا استمر هذا يحدث.
بالنسبة لاختبار الوحدة الآلي ، هذا ليس موقفًا شائعًا. ومع ذلك ، في عالم أمان التطبيقات ، حيث يتم إجراء الاختبار غالبًا باستخدام أدوات تحليل الكود (SAST – اختبار أمان التطبيق الثابت) ، يحدث هذا النوع من الأشياء كل يوم. ولا يمكن للمطور الذي يعاني من نتيجة إيجابية خاطئة أن يطلب ببساطة تصحيح الأداة من قبل فريق تطوير الاختبار لأن الأداة عادةً ما تكون تطبيقًا تابعًا لجهة خارجية.
هذا هو السبب في أن محاولات تقديم ممارسات DevSecOps تميل إلى الفشل كثيرًا. قد يكون أعضاء فريق DevOps متحمسين في البداية لتقديم اختبار أمان آلي في خطوط الأنابيب ، ولكنهم ينفذه بعد ذلك باستخدام واحدة من العديد من أدوات التحليل الثابتة التي يتم تسويقها على أنها أفضل خيار لـ DevSecOps ويكتشفون أنها لا تعمل بسبب العدد الخاطئ الإيجابيات ببساطة غير مقبولة. وكلما كبرت المنظمة ، زادت خيبة الأمل – وزادت مخاطر عدم إعادة النظر في DevSecOps مرة أخرى.
السبب 5. عدم فهم الأدوات
جزئيًا من خلال نقص الوعي (انظر السبب 3) ، غالبًا ما تركز فرق DevOps على SAST كأداة DevSecOps المفضلة ولا تعتبر DAST شيئًا يمكن تضمينه في خطوط أنابيب CI / CD. والسبب في ذلك بسيط: معظم أدوات DAST غير مناسبة لـ DevSecOps لمجرد أنها لا تقدم أتمتة كافية.
لا يزال يُنظر إلى أدوات DAST على أنها ماسحات ضوئية بسيطة يتم تشغيلها مرة واحدة كما كانت قبل عامين فقط. كان الاستخدام التقليدي لأداة DAST هو إجراء فحص أمني على تطبيق تم نشره في بيئة مرحلية – وهذا ، من الواضح ، ليس رشيقًا على الإطلاق. فقط تخيل ما يحدث عندما يعثر الفحص على ثغرة أمنية خطيرة – يجب أن يعود التطبيق إلى لوحة الرسم ويجب تكرار دورة المرونة الكاملة التي مرت بها.
ومع ذلك ، ليست كل أدوات DAST عبارة عن ماسحات ضوئية بسيطة. يتم الآن دمج العديد ، مثل Acunetix ، بشكل مباشر في خطوط أنابيب CI / CD. يمكنهم العمل مباشرة مع أدوات مثل Jenkins ، يمكنك إعدادها للنجاح أو الفشل اعتمادًا على نوع الثغرة الأمنية المكتشفة ، والأهم من ذلك أنها تفوق SAST بكثير من حيث الدقة والأداء ونطاق الثغرات المكتشفة.
هناك جانب سلبي بسيط لـ DAST عند مقارنته بـ SAST: يمكن لأدوات تحليل التعليمات البرمجية تحديد سطر التعليمات البرمجية حيث تم العثور على مشكلة أمنية ، بينما لا يمكن لـ DAST القيام بذلك. ومع ذلك ، في بيئة رشيقة نموذجية ، تكون التغييرات والإضافات في التعليمات البرمجية في كل بناء صغيرة جدًا ، وبالتالي يكون من السهل جدًا على المطور تحديد مكان المشكلة في الكود المصدري. في كثير من الأحيان ، يكون المطور الذي يحصل على تقرير يفيد بأن أحد المباني قد فشل في فحص أمان DAST هو نفس المطور الذي أدخل التغييرات في المقام الأول. وإذا لم يكن ذلك كافيًا ، فإن بعض أدوات DAST مثل Acunetix لديها خيار IAST (AcuSensor) الذي يجمع بين أفضل ما في العالمين بتكلفة نشر أكثر تعقيدًا.
الطريق إلى الأمام من أجل أمان التطبيق
كيف يمكنك التغلب على صعوبات تقديم اختبار الأمان مباشرة في تطوير تطبيقك؟
- تثقيف الجميع في مؤسستك حول أهمية أمان التطبيق. تأكد من إدراكهم أنه يجب منحه نفس الاهتمام مثل المزيد من التهديدات المضطربة مثل برامج الفدية والتصيد الاحتيالي.
- علّم الجميع في مؤسستك أن أمان الشبكة وأمن التطبيقات هما شيئان مختلفان تمامًا ، وبينما لا مكان لأمن الشبكة كجزء من DevOps ، يجب أن يكون أمان التطبيقات جزءًا من DevOps حتى تكون مؤسستك مرنة حقًا.
- علم الجميع في مؤسستك أن أدوات DAST لم تعد مجرد ماسحات أمان بسيطة كما كانت قبل عامين فقط. تأكد من إدراكهم أن أدوات DAST مصممة حاليًا ليتم تضمينها في خطوط أنابيب CI / CD – ويمكنهم القيام بعمل أفضل بكثير من أدوات SAST في هذا الدور.
احصل على أحدث محتوى حول أمان الويب
في بريدك الوارد كل أسبوع.
المؤلف
كاتب المحتوى الفني
Tomasz Andrzej Nidecki (المعروف أيضًا باسم tonid) هو كاتب محتوى تقني يعمل في Acunetix. صحفي ومترجم وكاتب تقني يتمتع بخبرة 25 عامًا في مجال تكنولوجيا المعلومات ، وكان توماسز مدير التحرير لمجلة hakin9 IT Security في سنواتها الأولى ، وكان يستخدم لتشغيل مدونة تقنية كبرى مخصصة لأمن البريد الإلكتروني.
