اختبار الاختراق كشف 40 ثغرة — هل نحتاج لشراء أداة لمتابعة إغلاقها كلها؟

ارفضوا عرض الترخيص هذا فوراً. لا تدعوا رقم 40 يخيفكم؛ ركزوا أولاً على الثغرات الحرجة والعالية فقط. على الأرجح ستحلون 80% من المخاطر بعمل أسبوع واحد للمطورين. أما البنود المنخفضة المتبقية فوزعوها مهمة أو اثنتين في دورات الـ sprint القادمة وانتهى الأمر.

استلمنا العام الماضي تقريراً بـ 38 ثغرة في فريقنا المكون من 20 شخصاً. حاول المستشار بيع برنامج مماثل لنا ورفضنا. أنشأنا وسمًا خاصاً في نظام التذاكر الحالي لدينا، وأغلقنا 34 منها خلال 45 يوماً، واعتبرنا الثغرات الـ 4 المنخفضة المتبقية قبولاً للمخاطر (risk acceptance). واجتزنا التدقيق بدون أي تكلفة إضافية.

اقتراح الشركة التي أجرت الاختبار لأداة بـ6000 دولار مباشرة بعده هو حركة بيع إضافي كلاسيكية. غالبًا هم شركاء أو وكلاء ذلك البرنامج ويأخذون عمولة على كل عملية بيع. تخصيص شركة من 14 شخصًا ميزانية لأداة كهذه هدر كامل للموارد.

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

هل يوجد بند "re-test" أي إعادة الاختبار في عقد الاختبار؟ وإن وُجد فما مدته؟ معظم العقود تتضمن فترة تحقق مجانية 30 أو 60 يومًا للإصلاحات. إن وُجد فيمكنكم أصلًا تكليف المستشار بمهمة التأكيد التي ستقوم بها الأداة ضمن نطاق العقد.

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

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

الرأي العام واضح تمامًا: 1) لا تشتروا الأداة بـ6000 دولار، 2) افتحوا مهامًا بوسم الأمان في أداة تتبع المشاريع الحالية لديكم، 3) تحققوا من حق إعادة الاختبار المجاني في عقدكم واستخدموه للتحقق. البرمجيات الإضافية تزيد عبئكم فقط.

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

بالطبع يختلف الأمر إذا كانت حالتك مختلفة.

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

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

صححوا لي إن أخطأت.

دعني أترك تنبيهًا. تقرير الفحص الآلي ليس نفس اختبار الاختراق.

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

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

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

فعل الجميع لشيء ما لا يعني أنه صحيح. صححوا لي إن أخطأت.

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

إذا كتبت النتيجة هنا، فستفيد الآخرين أيضاً.

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

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

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

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

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

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