نوشتن یافته‌هایی که واقعاً وصله می‌شوند

پیداکردن باگ نیمی از کار است. نیمهٔ دیگر، قانع‌کردن یک تیم مهندسی پرمشغله برای رفع آن است. یک اکسپلویت درخشان که در گزارشی مبهم دفن شده کم‌اولویت می‌شود؛ یک یافتهٔ با شدت متوسطِ روشن‌نوشته‌شده در اسپرینت بعدی وصله می‌شود. گزارش‌نویسی یک مهارت است، و همان مهارتی است که تسترهایی را که دوباره استخدام می‌شوند از بقیه جدا می‌کند.

با تأثیر شروع کن، نه با مکانیزم

مهندس‌ها بر اساس ریسک کسب‌وکار اولویت‌بندی می‌کنند. هر یافته را با این‌که مهاجم چه کاری می‌تواند بکند شروع کن، بعد توضیح بده چطور. «یک کاربر احرازنشده می‌تواند فاکتور هر مشتری را بخواند» سریع‌تر از «IDOR در endpoint به‌اسم /invoice» حرکت می‌کند.

آن را تکرارپذیر کن

یافته‌ای که تکرار نشود قابل تأیید نیست، و یافته‌های تأییدنشده به‌عنوان «رفع نمی‌شود» بسته می‌شوند. مراحل دقیق بده:

GET /api/invoices/1002 HTTP/1.1
Host: app.example.com
Authorization: Bearer <token-for-user-A>

# User A receives user B's invoice — no authorization check on the object ID.

شدت را صادقانه ارزیابی کن

با یک راه‌حل تمام کن، نه فقط یک نقص

بهترین یافته‌ها یک مسیر رفع به تیم می‌دهند: اعمال بررسی احراز اختیار روی آبجکت، افزودن یک تست رگرسیون، و اشاره به این‌که احتمالاً کجای کدبیس جای آن است. تو فقط یک مشکل را گزارش نمی‌کنی — حلش را تا حد ممکن ارزان می‌کنی. همین است که دوباره دعوتت می‌کنند.