گزارش باگ ثبت شده در برنامه باگ بانتی توسط چه کسانی ارزیابی می‌شود

گزارش باگ ثبت شده در برنامه باگ بانتی توسط چه کسانی ارزیابی می‌شود

گزارش های باگ و کار تریاژ

قسمت اعظم کارهایی که با برنامه‌های باگ بانتی کارهای مدیریتی هستند. دراین متن هک‌کردن نیازمند کاغذبازی است. نوشتن گزارش باگ، ثبت کردنشان در صف تیکت‌ها، جواب گرفتن از مدیران میان‌رده ، ثبت دوباره گزارش با جزئیات بیشتر(این قسمت از کار تاحدودی شبیه به هک‌کردن است). دراین راستا، یکی از کارهای اصلی که درتمام برنامه های باگ بانتی، خواه عمومی یا خصوصیِ باشند، چه یک برنامه برگزارشده در پلتفرم یا یک برنامه داخلی باشد، بررسی و تریاژ گزارش های دریافت شده باید انجام شود. در برنامه های باگ بانتی از کارمندان بخش تریاژ برای بررسی جزبه جز و عمیق  گزارش های باگ ثبت شده کمک گرفته می‌شود. برنامه های باگ بانتی روتین ثبت و تریاژ گزارش باگ را بسیار آسان تر کرده است.

نمونه گزارش باگ بانتی برای گوگل کرومیوم
شکل1. نمونه گزارش باگ بانتی برای گوگل کرومیوم

درحالت ایداه‌آل گزارش های باگ دربرگیرنده تمام اطلاعات موردنیاز برای درک آسیب پذیری کشف شده است، این اطلاعات شامل متن فنی ای که به دست شخص یابنده نقص نوشته شده است، گام های موردنیاز برای بازتولید نقص و تخمین سطح اثر یا میزان خطر آسیب‌پذیری، است. بااستفاده از سیستم ردیابی باگ، افراد فعال در قسمت تریاژ تصمیم می‌گیرند که آیا یک باگ گزارش شده است یا مشکل آن رفع شده است. همچنین تعیین می‌کنند که آیا نقص گزارش شده داخل اسکوپ تعریف شده از سمت شرکت است و برای دریافت پاداش “معتبر” است یا نه. برای مثال، برنامه باگ بانتی تسلا لیستی از “اهداف” را تعیین کرده است که داخل اسکوپ تعیین شده از طرف این شرکت هستند، مثلا اپلیکیشن iOS تسلا، شماری از وب سایت هایی که در دسترس عموم هستند و تسلایی که شما صاحب آن هستید. مواردی هم هستند که خارج از اسکوپ تعیین شده هستند، مثلا برخی از وب سایت ها مثل feedback.tesla.com. همچنین فهرستی از انواع نقص ها یا مشکلاتی که اماکن دارد خارج از اسکوپ یا واجد شرایط دریافت جایزه نیستند (دزدین کلیک، فیشینگ و حملات مهندسی اجتماعی، افشای IP آدرس های داخلی و…) را فراهم آورده است. درآخر افرادیکه در قسمت تریاژ کار می‌کنند تعیین می‌کنند که آیا گزارش ثبت شده و باگ کشف شده قابل بازیابی است یا نه.

دلایل متعددی برای رد شدن یک گزارش باگ و عدم تایید پرداخت پاداش وجود دارد، و کارمندان تریاژ مهارت خاصی در تصمیم گیری دراین زمینه دارند. ممکن است گزارش ارائه شده نگارش ضعیفی داشته باشد یا ازنظر تیم تریاژ برای تایید مشکل اطلاعات کافی درآن داده نشده است. ممکن نقصی که از قبل گزارش آن در صف انتظار تریاژ وجود داشت را افشا کند. ممکن است گزارش حاوی باگی باشد که مشکل آن رفع شده ولیکن گزارش آن هنوز منتشر نشده است. امکان دارد میزان خطر باگ زیاد واضح نباشد. ممکن است آسیب‌پذیری کشف شده یک خطر امنیتی قابل قبول یاشد یا حتی ممکن است یک ویژگی طراحی باشد.

کار تیم تریاژ در برنامه های بانتی مختلف میتواند متفاوت باشد. در برنامه های بانتی داخلی معمولا این تیم کلا وظیفه ارزیابی و بازبینی گزارش ها را دارد. اما در پلتفرم‎های باگ بانتی، کار تریاژ توسط کارمندان تریاژ از نرم افزار یا سرویس مورد نظر در چندگام حذف می‌شود. در پلتفرم های بانتی اغلب کار تریاژ به صورت پیمانی مدیریت می‌شود، یعنی افرادیکه دراین قسمت کار می‌کنند کارمندان تمام وقت نیستند. اکثر این پیمانکاران، هکرهای کلاه سفیدی هستند که ازقسمت ثبت باگ در برنامه های باگ بانتی به قسمت بررسی گزارش های ثبت شده در پلتفرم ها آمده‌اند. درتمام موارد، تک تک افرادیکه در قسمت تریاژ مسئولیت بررسی گزارش ها را به عهده دارند، نقش مهمی در امر تصمیم‌گیری درمورداینکه آیا گزارش باگ ثبت شده کامل و درست نوشته شده یا واقعا نقص کشف شده را می توان به عناون آسیب‌پذیری که ارزش پاسخگویی، رفع و پرداخت پاداش را دارد یانه، ایفا می‌کنند. اما بحث های موجود برسر تریاژ یکی از تنش های اصلی و همیشگی برای شکارچیان باگ بانتی است.

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *