از آنجایی که آسیب‌پذیری‌ها همچنان در مرکز قرار می‌گیرند و سازمان‌ها به دنبال راه‌اندازی هستند فضل اشکال و برنامه های تضمین امنیت، رقابت برای محققان خوب شدید است. اما ارزیابی این برنامه ها برای محققان آینده نگر می تواند دشوار باشد. برخی از سوالات رایج عبارتند از: نرخ فعلی آسیب پذیری های رایج چیست؟ تیمی که کار تریاژ گزارش را انجام می دهد چقدر با تجربه است؟ آیا یک تیم امنیتی یا متخصص در مورد آنچه به عنوان آسیب پذیری طبقه بندی می شود تصمیم می گیرد؟
محققان عموماً تردید دارند که یک تیم محصول و توسعه بتواند گزارش اشکال را به‌عنوان آسیب‌پذیری امنیتی طبقه‌بندی کند، زیرا به‌دلیل عدم برخورداری از تخصص امنیتی محسوس است. در عوض، اگر یک تیم امنیتی اختصاصی (مانند ProdSec، AppSec، PSIRT و غیره) در مورد آسیب‌پذیری امنیتی بودن یک گزارش تصمیم بگیرند، تمایل بیشتری به اعتماد به برنامه دارند.
محققان امنیتی همچنین دوست دارند آمار برنامه را بررسی کنند، که اغلب شامل کل پرداخت ها برای سال قبل است. مجموع پرداخت‌های بالاتر اغلب نشان می‌دهد که اشکالات بیشتری وجود دارد، جایی که پرداخت‌های کمتر ممکن است به معنای باگ‌ها و/یا پاداش‌های کمتر باشد. آنها همچنین به میانگین زمان تریاژ یا زمان بین ارسال و تایید یک آسیب پذیری معتبر یا نامعتبر اهمیت می دهند. این می تواند به محققان بگوید که آیا این برنامه با تجربه است و به اندازه کافی پشتیبانی می شود.
زمان بین ارسال و پرداخت، یا زمان متوسط تا جایزه نیز مهم است. باز هم، کوتاهتر بهتر است و اغلب به این معنی است که برنامه مسائل مالی ندارد و برای زمان محقق ارزش قائل است. چرخش های طولانی تر فضل می تواند باعث عدم اطمینان شود.
این هیچ راز که فروشندگان جوایز با شدت کمتر را ترجیح می دهند و پرداخت های کمتر، در حالی که محققین پرداخت های بالاتر را دوست دارند. میانگین پرداخت کمتر ممکن است منجر به این باور شود که آسیب‌پذیری‌ها کم‌اهمیت می‌شوند و مسائل با شدت بالاتر ممکن است توجهی را که شایسته آنها هستند جلب نکنند. پرداخت های بالا ممکن است به محققان نشان دهد که میوه کم آویزان وجود ندارد، که می تواند محققان جدید را از پیوستن به برنامه منصرف کند. همچنین می تواند نشان دهد که سرمایه گذاری زمانی برای یافتن یک آسیب پذیری بسیار زیاد است. اغلب یک میانگین پرداخت متوسط بهترین است.
زمینه دیگری که می تواند محققان را منصرف کند، قانونی بودن گزارش آسیب پذیری است. زمانی که یکی از طرفین احساس ارزشمندی نمی‌کند، رعایت سیاست‌های افشای آسیب‌پذیری هماهنگ می‌تواند دشوار باشد. بندرگاه امن یک وعده است اما می تواند به عنوان یک تهدید نیز ظاهر شود.
بندر امن بند اضافه شده به خط مشی برنامه افشای آسیب پذیری است که بیان می کند که محقق امنیتی نباید از عواقب قانونی بترسد (و حتی ممکن است حفاظت های اضافی) توسط هدف تحقیقات امنیتی خود در صورتی که آن تحقیق با حسن نیت و انجام شود. در همکاری با هدف این منجر به این می‌شود که محققان بخواهند بدانند فروشندگان چگونه با تخلفات برخورد می‌کنند یا وقتی فروشنده از سیاست‌های اعلام‌شده خود پیروی نمی‌کند، چگونه می‌توانند پشتیبانی دریافت کنند. اینها فرآیندهای مهمی هستند که باید تعریف شوند.
محققان در یک برنامه به چه چیزی اهمیت می دهند؟ در تجربه من، شش حوزه اصلی وجود دارد.
سرعت
همانطور که قبلا ذکر شد، سریعتر بهتر است. محققان می‌خواهند تصمیم‌گیری، پاسخ‌ها، افشای آسیب‌پذیری‌ها و پاداش‌ها به سرعت توزیع شود.
بشریت
محققان می خواهند از مردم بشنوند، نه یک شرکت یا وکلای آن. آنها می خواهند مانند یک انسان با آنها رفتار شود و با آنها صحبت شود، نه به عنوان روبات های محقق.
شفافیت و دسترسی
هنگام ارسال گزارش اشکال باید تا حد امکان موانع کمتری وجود داشته باشد. آیا محققان به شناسه مالیاتی، آدرس ایمیل یا نرم افزار رمزگذاری نیاز دارند؟ چگونه یک محقق می تواند به بهترین شکل با یک فروشنده و برنامه تعامل داشته باشد؟ محققان باید روی چه ابزار، نرم افزار، سخت افزار، آموزش سرمایه گذاری کنند؟ و چگونه فروشنده روی جمعیت محقق خود سرمایه گذاری می کند یا خواهد کرد؟ به این سوالات پاسخ دهید و شفاف باشید.
تخصص
محققان قبل از اینکه بتوانند راهی برای شکستن آن یا وادار کردن آن به انجام کارهایی که برای آن طراحی نشده است بیابند، زمانی را صرف یادگیری در مورد یک محصول و نحوه عملکرد آن می کنند. در نتیجه، آنها انتظار دارند افرادی که گزارش های آنها را می خوانند، حداقل همان سطح تخصص را داشته باشند.
دفاع
محققان برای فروشنده کار نمی کنند. این یکی از دلایلی است که آنها از طریق یک برنامه جایزه اشکال ارسال می کنند. آنها نمی توانند در تمام گفتگوها شرکت کنند، بنابراین به یک وکیل در داخل شرکت نیاز دارند.
شناخت / پاداش
برنامه‌های پاداش باگ جهشی از یک برنامه افشای آسیب‌پذیری (VDP) هستند که کاملاً مبتنی بر مفهوم «چیزی ببینید، چیزی بگویید» است، اما به جای انجام دادن آن به سادگی یک انگیزه پاداش ارائه می‌کند، زیرا کار درستی است. . اطمینان از اینکه مشوق های ارائه شده با اهداف محقق مطابقت دارد بسیار مهم است. آیا آنها می خواهند شناخته شوند یا پنهان بمانند؟ آیا آنها پرداخت می خواهند؟ آیا آنها حتی مجاز به دریافت پاداش هستند؟
برای فروشندگان، هنگام جذب محققان با استعداد، موارد زیادی باید در نظر گرفته شود. آمار برنامه را حداقل سالیانه (اگر نه در زمان واقعی) ارائه دهید. ماتریس تصمیم گیری برای پاداش و به رسمیت شناختن را منتشر کنید تا محققان بدانند برای دریافت جایزه برتر چه چیزی لازم است. اسنادی را در دسترس قرار دهید که فرآیندی را که گزارش اشکال پس از خروج از دست محقق انجام می‌دهد، توضیح دهد. توافق نامه های سطح خدمات را برای مراحل کلیدی فرآیند تنظیم کنید و آماری را در مورد اینکه تیم چقدر به آنها پاسخ می دهد منتشر کنید. از زبان انسانی استفاده کنید و درک کنید که همه در این فرآیند اشتباه می کنند، اما به ندرت بدخواه هستند. قبل از قضاوت ابتدا به دنبال درک باشید.
در نهایت، اگر می‌خواهید درباره پاداش‌های باگ بیشتر بدانید، این سازمان‌ها را در نظر بگیرید: انجمن مورد علاقه Bug Bounty, اولو OWSP. همانطور که برنامه‌های پاداش باگ بالغ می‌شوند و انسانی‌تر می‌شوند، فروشندگان و محققان می‌توانند با هم همکاری کنند تا خط‌مشی‌ها و فرآیندهایی را ایجاد کنند که برای همه افراد درگیر پاداش باشد.
