استلمنا الكود الذي تركه الوكالة — كيف يجب إجراء مراجعة أمنية للكود ومن أين نبدأ؟

خطوتكم العاجلة الأولى يجب أن تكون تنظيف سجل Git. حتى لو حذفتم كلمة المرور من ملف الكود وأضفتم commit جديداً، تبقى تلك الكلمات مكشوفة في سجل Git إلى الأبد. افحصوا كل سجل الـ commit بأدوات فحص الأسرار مفتوحة المصدر، ونظفوا المفاتيح بإعادة كتابة السجل، وغيّروا تلك الكلمات فوراً على السيرفرات.

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

نحن أيضاً شغّلنا تحليل الكود الساكن في مشروع من 30 ألف سطر استلمناه العام الماضي. أعطى النظام 142 تحذيراً محتملاً، وعندما فحصها مطوّرنا رأى أن 8 منها ثغرات حقيقية قد تؤدي مباشرة إلى تسرب قاعدة البيانات. إغلاق هذه الثغرات الثمانية استغرقنا ثلاثة أيام فقط.

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

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

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

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

كيف تقوم أدوات مراجعة الكود الثابت بفحص الأكواد دون تشغيلها؟ كيف تفهم هذه الأدوات تحديدًا أن هناك دالة معينة تحتوي على ثغرة دون تثبيتها على خادم حي ودون الاتصال بقاعدة البيانات؟

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

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

أنا أيضًا متحمس لمعرفة ذلك.

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

اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.

كنت أفكر في نفس الشيء. تقرير الفحص الآلي ليس نفس اختبار الاختراق.

لو كنت مكانك، لسلك هذا المسار.

عانيت من نفس الشيء. عندما نتخذ قرارات دون قياس، نعود لنفس النقطة دائماً.

هذا كل شيء، أرجو المعذرة إذا أطالت.

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

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

هناك ثلاثة أمور يجب مراعاتها أثناء القيام بذلك لكن الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

أنا في نفس الوضع، لذلك أسأل. إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار.

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

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

إذا كانت قناة الإشعارات طويلة، فلن تصل الإشعارات؛ والإشعار غير الواصل يعني حدثًا يُكتشف متأخرًا.

زالت حيرتي، شكراً لكم. وقت اكتشاف المشكلة يحدد تكلفتها بشكل مباشر.

اكتبوا إذا كانت لديكم أسئلة، سأجيب قدر استطاعتي.