أفضل الممارسات لتأمين SDLC الخاص بك

تطوير البرمجيات هو ممارسة يشارك فيها المزيد والمزيد من الناس حول العالم. هناك شركات وأفراد يقومون ببناء البرمجيات، بعضها مملوك، وبعضها مجاني أو مفتوح المصدر، وبعضها عبارة عن مزيج من الاثنين. نظرًا لأن التهديدات التي يتعرض لها أمان المستخدمين أو برامجهم لا تتجسد من الأثير بمجرد الإعلان عن اكتمال شيء ما وشحنه إلى الإنتاج، يبدو أن هذا هو الوقت المناسب للحديث عن الممارسات الأمنية التي من شأنها أن تساعد في إدارة المخاطر الأمنية التي قد تتسلل إلى برنامجك أثناء عملية التطوير. هناك العديد من أطر عمل SSDLC (دورة حياة تطوير البرمجيات الآمنة)، بما في ذلك أطر عمل من OWASP, CISAو نيست (قوات الدفاع الذاتي الخاصة). في هذه المقالة، سنقتبس قليلًا منها جميعًا لتسليط الضوء على بعض الممارسات التي تهدف إلى مساعدتك في إدارة المخاطر الكامنة في تطوير البرمجيات. لا تعيش مع شعور بالأمان الزائف معتقدًا أن هذا لا يمكن أن يحدث لك. يكشف تقرير الأمن السيبراني النصف سنوي Check Point 2023 عن ارتفاع بنسبة 8٪ في الهجمات الإلكترونية العالمية خلال عام 2022، ولا يبدو أن الاتجاه ينعكس. 

ما هي دورة حياة تطوير البرمجيات

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

  1. تحليل المتطلبات - ماذا سنبني ولماذا
  2. تخطيط الرحلة – كيف سنقوم ببنائه بشكل عام
  3. تصميم البرمجيات – كيف سنقوم ببنائه بمصطلحات محددة مثل التصميم المعماري
  4. تطوير البرمجيات – كتابة وتجميع البرمجيات
  5. الاختبار – تأكد من أنه يعمل كما هو مخطط له
  6. التنفيذ - شحنه أو نشره حتى يتمكن المستخدم النهائي من استخدامه

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

أهمية تأمين SDLC الخاص بك

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

هنا، يشير Shift-left إلى توزيع المخاوف الأمنية خلال عملية التطوير وإشراك المطورين في تصميم الأمان وتنفيذه واختباره.

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

كلما كانت المتطلبات محددة جيدًا، وكلما زادت الأتمتة والأدوات الشاملة التي يمكنك توظيفها، أصبحت المهام أسهل.

رسم بياني

أفضل ممارسات أمان SDLC

فيما يلي بعض أفضل الممارسات لمساعدتك على تأمين عملية التطوير الخاصة بك دون ترتيب معين:

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

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

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

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

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

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

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

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

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

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

يبدأ الأمان بعقليتك

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

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

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

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