للفرق التي تبني محللات أو مكتبات أو حزم SDK أو بروتوكولات أو مكونات تطبيق تعالج مدخلات غير موثوقة.

عندما يمكن لملفات أو رسائل أو مدخلات غير سليمة أن تكشف نقطة ضعف.

نطاق الفحص

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

بداية واضحة. نتيجة مفيدة.

أخبرني بالمشكلة

اذكر المنتج والتقنيات والهدف والموعد. يكفي وصف مختصر لبدء الحديث.

نتفق على العمل

تتلقى نطاقًا ومخرجات ومعايير قبول وسعرًا وجدولًا مكتوبًا قبل البدء.

نراجع العمل أثناء تقدمه

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

استفد من النتيجة

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

أحقق حتى أصل إلى السبب.

أبحاث في Facebook وInstagram، وأكثر من 300 تقرير ونتيجة فحص حققت فيها في نواة Linux، وثماني رقع وثغرتا CVE منشورتان. أربط السلوك المشبوه بالشيفرة وظروف حدوثه وأثره على منتجك.

اطّلع على نتائج النواة وإصلاحاتها

أسئلة قبل البدء

ما الذي يجعل المكوّن مناسباً لاختبارات Fuzzing؟

حدود إدخال واضحة وبيئة بناء أو تشغيل يمكننا اختبارها. المحللات والمكتبات ومعالجات البروتوكولات أمثلة مناسبة. نتحقق من الملاءمة قبل الالتزام باختبارات أوسع.

هل يمكن البدء بتجربة صغيرة؟

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

هل تسلّم برنامج تشغيل للاختبار أو إعداداً يمكن مواصلة استخدامه؟

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

هل يمثل كل تعطل ثغرة أمنية؟

لا. حالات الفشل تحتاج إلى تحقيق. يميز التقرير بين السلوك الملحوظ والأثر الأمني المؤكد والأسئلة التي لم تُحسم؛ ولا يعد بعدد محدد من الثغرات أو سجلات CVE.

اختبارات Fuzzing موجهة