كيف نبدأ مع فريقنا بمراجعة الكود أمنيًا قبل الإطلاق؟

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

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

ملاحظة: سُئل هذا أدناه، وكتبت الإجابة في الرسالة الثانية.

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

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

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

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

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

باختصار خارطة الطريق واضحة: 1) ادمجوا أدوات آلية مجانية في المستودع وافحصوا التبعيات والثغرات الأساسية، 2) ضعوا شرط مراجعة من 5 بنود في طلبات السحب يركز على الصلاحيات والتحقق من البيانات، 3) اتركوا فحوصات منطق العمل للمراجعة اليدوية من المطورين. لا حاجة لميزانيات ضخمة، الانضباط يكفي.

عانيت من نفس الشيء.

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

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

شكرًا جزيلاً، سأجربها اليوم.

تم الحفظ.

أوافقك الرأي تمامًا. الإجراء المتخذ دون جرد المخزون يترك باباً لا تراه مفتوحاً.

أكثر ما أهدر وقتنا كان عدم وضوح من يتخذ القرار.

أكتب هذا حتى لا تكرروا نفس الخطأ. نسخة احتياطية غير مختبرة ليست نسخة احتياطية.

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

هناك خطأ شائع جداً يقع فيه الكثيرون أثناء فعل هذا. معظم إضاعة الوقت تتراكم في المهام المنتظرة للموافقة.

هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

أنا مشروع صغير، دعوني أشرح من منظوري. فعل الجميع لشيء ما لا يعني أنه صحيح.

لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً.

زالت حيرتي، شكراً لكم.

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

نسخة احتياطية غير مختبرة ليست نسخة احتياطية. لو كنت مكانك، لسلك هذا المسار.