«باگ بانتی چیست» را می‌توان در یک جمله پاسخ داد: یک سازمان بهصورت عمومی و مکتوب به پژوهشگران مستقل اجازه میدهد در محدوده‌ای مشخص به‌دنبال آسیبپذیری بگردند و برای هر گزارش معتبر و تازه پاداش میپردازد. تمام معنای فنی و حقوقی این موضوع در همان کلمه‌ی «اجازه» جمع شده است: آزمون داخل محدودهی منتشرشده یک فعالیت مجاز و حرفه‌ای است، و همان آزمون بیرون از آن محدوده یا روی سامانهای که برنامهای ندارد، دسترسی غیرمجاز و جرم است. این مقاله سازوکار واقعی برنامه‌های باگ بانتی، تفاوت دقیق آن با تست نفوذ و با VDP، و پاسخ صریح به این پرسش را میدهد که چرا باگ بانتی جای تست نفوذ را نمی‌گیرد.
در یک نگاه
- باگ بانتی یک مجوز آزمون محدود و مشروط است، نه اجازه‌ی عمومی برای تست هر سامانهای. هر چیزی بیرون از اسکوپ منتشرشده، بدون مجوز است.
- پرداخت در باگ بانتی نتیجه‌محور است (بهازای یافته‌ی معتبر)، در تست نفوذ تلاش‌محور و قراردادی. این تفاوت، همه‌ی تفاوت‌های دیگر را توضیح میدهد.
- باگ بانتی هیچ تضمین پوششی ندارد؛ ممکن است هیچ‌کس به بخش حساس سامانه‌ی شما نگاه نکند.
- VDP کانال گزارشدهی امن با تعهد عدم پیگرد است و پاداش نمی‌دهد؛ هر سازمانی باید VDP داشته باشد، اما هر سازمانی نباید باگ بانتی باز کند.
- ترتیب درست: ابتدا تست نفوذ و رفع، سپس VDP، سپس برنامهی خصوصی، و در نهایت برنامهی عمومی.
باگ بانتی چیست؟ تعریف دقیق و سه جزء سازنده‌ی آن
برنامهی باگ بانتی (Bug Bounty Program) یک دعوت‌نامه‌ی دائمی و منتشرشده است: سازمان اعلام میکند که پژوهشگران مستقل مجازند داراییهای مشخصی از آن را با روش‌های مشخصی آزمون کنند، و برای هر آسیبپذیری معتبر، تازه و داخل محدوده پاداش میپردازد. هر برنامهی سالم از سه جزء ساخته شده و اگر یکی از آن‌ها نباشد، آن چیز باگ بانتی نیست:
- مجوز (Authorisation): متنی صریح که میگوید چه کسی، چه چیزی را، با چه روش‌هایی مجاز است آزمون کند. این جزء، مبنای حقوقی کل فعالیت است.
- محدوده (Scope): فهرست دقیق داراییهای مجاز — دامنه‌ها، زیردامنه‌ها، APIها، اپلیکیشن‌ها — و فهرست صریح موارد خارج از محدوده.
- پاداش مشروط به نتیجه: ساختار پرداخت بر پایه‌ی شدت و اثر یافته، بدون هیچ تعهدی برای پرداخت در قبال زمان صرف‌شده.
به همین دلیل باگ بانتی از منظر حقوقی، «هک قانونی» نیست؛ آزمون امنیتی مجاز است. تفاوت این دو عبارت جدی است: مجوز از یک سند مشخص با دامنه‌ی مشخص می‌آید و به‌همان اندازه هم محدود است. اگر یک برنامه فقط app.example.com را در اسکوپ گذاشته باشد، آزمون mail.example.com — حتی متعلق به همان سازمان — بدون مجوز است.
«باگ بانتی یعنی می‌توانم روی هر سایتی برای تمرین تست کنم و اگر باگ پیدا کردم گزارش بدهم.» این کاملاً غلط و از منظر قانونی خطرناک است. نبود برنامه یعنی نبود مجوز. بر پایه‌ی قانون جرائم رایانهای، دسترسی غیرمجاز به داده یا سامانه‌ی رایانهای جرم است و «قصد خوب» یا «گزارش دادم» رافع مسئولیت نیست. برای تمرین باید از محیط‌های آزمایشگاهی مجاز استفاده کنید که در مسیر یادگیری باگ بانتی معرفی شده‌اند.
چهار نقش در یک برنامه و کاری که هرکدام انجام میدهد
درک این چهار نقش، رفتار عملی یک برنامه را توضیح میدهد.
پژوهشگر امنیتی (Researcher / Hunter)
کسی که اسکوپ را می‌خواند، آزمون میکند و گزارش می‌نویسد. درآمدش نه با تعداد ساعت، بلکه با تعداد یافته‌های معتبر و تازه و کیفیت مستندسازی تعیین میشود.
مالک برنامه (Program Owner)
تیم امنیت سازمان که اسکوپ را تعریف میکند، بودجه‌ی پاداش را می‌بندد، شدت نهایی را تأیید میکند و یافته را به تیم توسعه می‌سپارد. مالک برنامه با یک محدودیت واقعی روبروست: هر گزارش تأییدشده به ظرفیت مهندسی برای رفع نیاز دارد. برنامهای که سرعت رفعش کمتر از سرعت ورود گزارش باشد، خودش را خفه میکند.
تیم تریاژ (Triage)
حلقه‌ی واسط و مهم‌ترین مخاطب گزارش شما. کار تریاژ چهار چیز است: بازتولید یافته، اعتبارسنجی آن، تشخیص تکراری‌بودن در برابر گزارش‌های پیشین، و پیشنهاد شدت. تریاژر ممکن است ده‌ها گزارش در صف داشته باشد؛ هر ابهامی در مراحل بازتولید، گزارش شما را به انتهای صف می‌فرستد. این دقیقاً همان‌جایی است که کیفیت نوشتن گزارش باگ بانتی به پول تبدیل میشود.
پلتفرم
بستری که اسکوپ را منتشر میکند، گزارش‌ها را شماره‌گذاری و وضعیتشان را مدیریت میکند و مسیر پرداخت را فراهم می‌آورد. برخی سازمان‌ها بدون پلتفرم و با یک صندوق ایمیل اختصاصی برنامه اجرا می‌کنند. سازوکار پلتفرم‌های باگ بانتی و فهرست به‌روز برنامه‌های داخلی را در صفحه‌ی باگ‌بانتی ایران آورده‌ایم.
اسکوپ و قواعد تعامل: نخستین کار فنی، خواندن است
قواعد تعامل (Rules of Engagement) سندی است که مرز مجاز را تعیین میکند. یک اسکوپ حرفه‌ای معمولاً این بخش‌ها را دارد:
- داراییهای داخل محدوده: دامنه‌ها و زیردامنه‌ها، اندپوینت‌های API، اپلیکیشن موبایل، و اینکه آیا الگوی
*.example.comپذیرفته است یا فقط میزبان‌های نام‌برده‌شده. - داراییهای خارج از محدوده: معمولاً سرویس‌های ثالث (ارائه‌دهنده‌ی ایمیل، درگاه پرداخت، CDN)، محیط‌های عملیاتی حساس، و دامنه‌های مشتریان سازمان.
- روش‌های ممنوع: منع سرویس و آزمون بار، مهندسی اجتماعی روی کارکنان، آزمون فیزیکی، ارسال انبوه ایمیل، اسکن خودکار پرحجم، و آزمون روی حساب کاربران واقعی.
- حساب آزمون: برنامه‌های خوب حساب‌های تستی می‌دهند تا برای آزمون کنترل دسترسی نیازی به لمس داده‌ی واقعی نباشد.
- قواعد داده: حداقل داده‌ی لازم برای اثبات، ممنوعیت استخراج انبوه، و الزام به حذف داده پس از گزارش.
- شناسایی ترافیک: بعضی برنامه‌ها هدر یا رشته‌ی User-Agent مشخصی می‌خواهند تا ترافیک شما از حمله‌ی واقعی تفکیک شود.
سه رفتار حرفه‌ای: اسکوپ را پیش از نخستین درخواست بخوانید؛ در صورت شک درباره‌ی مجاز بودن یک دارایی از پلتفرم بپرسید و منتظر پاسخ بمانید؛ و اگر ناخواسته به داده‌ی واقعی رسیدید، آزمون را متوقف کنید و همان لحظه گزارش دهید.
وقتی دارایی‌ای خارج از محدوده اعلام میشود، معنایش این نیست که امن است؛ معنایش این است که سازمان اجازه‌ی آزمون آن را نداده. آن دارایی هم به آزمون نیاز دارد، اما در قالب یک تست نفوذ قراردادی با قرارداد و مجوز کتبی، نه در قالب باگ بانتی.
Safe Harbour و مجوز قانونی: چه چیزی را پوشش میدهد و چه چیزی را نه
بند «بندر امن» (Safe Harbour) تعهد مکتوب سازمان است به این مضمون: تا زمانی که پژوهشگر داخل سیاست منتشرشده عمل کند، سازمان علیه او اقدام حقوقی نمی‌کند و فعالیتش را نقض شرایط استفاده تلقی نخواهد کرد. این بند مهم‌ترین جمله‌ی هر سیاست افشا است و نبودش یک هشدار جدی است.
اما محدودیت‌هایش را باید دقیق فهمید:
- Safe Harbour فقط همان سازمان را متعهد میکند. اگر آزمون شما به زیرساخت ارائه‌دهنده‌ی ابری یا سرویس ثالثی برخورد کند، آن‌ها طرف این تعهد نیستند.
- Safe Harbour قانون را کنار نمی‌گذارد؛ فقط میگوید مالک دارایی شکایتی نخواهد داشت.
- هر خروجی از سیاست — یک اسکن پرحجم، یک آزمون منع سرویس، یا یک دارایی خارج از محدوده — پوشش را باطل میکند.
نمونه‌ی عملی چنین سندی را می‌توانید در سیاست افشای مسئولانه‌ی پی‌هانتر ببینید: دامنه‌ی مجاز، روش گزارش، قواعد آزمون امن و فرایند پاسخ. توجه کنید که آن سند پاداشی وعده نمی‌دهد — و همین آن را در دسته‌ی VDP قرار میدهد، نه باگ بانتی.
سازمان‌ها محل این سند را معمولاً با فایل security.txt در مسیر /.well-known/security.txt اعلام می‌کنند — قالبی که در RFC 9116 استاندارد شده و نخستین جایی است که یک پژوهشگر حرفه‌ای برای یافتن کانال گزارش نگاه میکند.
تفاوت باگ بانتی با تست نفوذ و با VDP — جدول مقایسه
این سه چیز اغلب با هم اشتباه گرفته می‌شوند، در حالی که سه ابزار متفاوت با سه هدف متفاوت‌اند.
| ویژگی | تست نفوذ | باگ بانتی | VDP |
|---|---|---|---|
| مدل زمانی | مقطعی و زمان‌بندی‌شده (نقطه‌ای در زمان) | پیوسته و بدون تاریخ پایان | پیوسته و منفعل (منتظر گزارش) |
| هدف اصلی | عمق — پوشش سیستماتیک همه‌ی کلاس‌های آسیبپذیری | گستره — نگاه‌های متنوع و موازی | ایجاد کانال امن برای یابندهی اتفاقی |
| مدل پرداخت | قراردادی، بر پایه‌ی تلاش و روزـنفر | بهازای هر یافته‌ی معتبر و تازه | بدون پرداخت |
| تضمین پوشش | دارد — چک‌لیست و متدولوژی مشخص | ندارد — کسی موظف به نگاه‌کردن نیست | ندارد |
| خروجی | گزارش یکجا با خلاصه‌ی مدیریتی، شدت و اولویت رفع | گزارش‌های پراکنده و موردی در طول زمان | گزارش‌های موردی |
| دانش زمینه | مستندات، حساب‌های چندسطحی، و در صورت توافق کد منبع | معمولاً جعبه‌سیاه و بدون مستندات داخلی | هیچ |
| آزمون مجدد پس از رفع | بخشی از تعهد قرارداد | معمولاً به‌عهده‌ی خود پژوهشگر و اختیاری | ندارد |
| استفاده در انطباق | قابل استناد (مثلاً الزام تست نفوذ در PCI DSS) | به‌تنهایی کافی نیست | نه |
| Safe Harbour | در قرارداد و مجوز کتبی | در سیاست برنامه | هدف اصلی همین است |
مهم‌ترین سطر این جدول، «تضمین پوشش» است. یک متدولوژی تست نفوذ بر پایه‌ی WSTG مشخص میکند که کدام آزمون‌ها اجرا شده‌اند و کدام‌ها نه؛ یعنی پس از پایان کار می‌دانید چه چیزی بررسی شده است. در باگ بانتی چنین چیزی وجود ندارد: نبود گزارش برای یک ماژول، هم می‌تواند به معنی امن‌بودن آن باشد و هم به معنی اینکه هیچ‌کس سراغش نرفته. به همین دلیل الزاماتی مانند بند ۱۱٫۴ در PCI DSS که متدولوژی مدون، پوشش کل محدوده و آزمون مجدد پس از رفع را می‌خواهند، با یک برنامهی باگ بانتی برآورده نمی‌شوند.
VDP چیست و چرا هر سازمانی به آن نیاز دارد؟
برنامهی افشای آسیبپذیری (Vulnerability Disclosure Program) پاداش نمی‌دهد؛ چیزی که میدهد مسیر و مصونیت مشروط است. باگ بانتی برای جذب فعالانه‌ی توجه پژوهشگران است، VDP برای مدیریت درست توجهی که خودش می‌آید.
سناریوی واقعی: یک توسعه‌دهنده اتفاقی می‌بیند که اندپوینتی از سایت شما فاکتور کاربران دیگر را برمی‌گرداند — یک IDOR کلاسیک. اگر VDP نداشته باشید سه سرنوشت ممکن است: سکوت، انتشار عمومی، یا فروش به دیگری. VDP گزینه‌ی چهارم و بهترین را می‌سازد.
حداقل‌های یک VDP قابل‌قبول: آدرس گزارش پایدار اعلام‌شده در security.txt؛ بند Safe Harbour صریح؛ دامنه‌ی مجاز و قواعد آزمون امن (منع منع‌سرویس، منع دسترسی به داده‌ی واقعی، منع ماندگاری)؛ تعهد به تأیید دریافت و به‌روزرسانی وضعیت؛ و سیاست افشا با زمان‌بندی مشخص.
«VDP همان باگ بانتی است، فقط بدون پول.» تفاوت ساختاری‌تر است: VDP یک تعهد فرایندی است و حجم ورودی آن کم و غیرقابل پیش‌بینی است. باگ بانتی یک سرمایه‌گذاری بازارمحور است که فعالانه حجم بالایی از آزمون را به سمت شما هدایت میکند و به همان نسبت ظرفیت تریاژ و رفع می‌خواهد. سازمانی که VDP را نتوانسته اداره کند، آماده‌ی باگ بانتی نیست.
شدت، پاداش و سرنوشت گزارش‌ها
پاداش، تابعی از چند متغیر است و نه فقط یکی: شدت فنی یافته، اهمیت دارایی برای کسب‌وکار، کیفیت گزارش (چقدر کار تریاژ را کم میکند)، و تازگی آن. زبان مشترک بیان شدت، CVSS است. نسخه‌ی جاری این استاندارد CVSS v4.0 است که از سال ۲۰۲۳ منتشر شده، اما در داده‌ی واقعی آسیب‌پذیری‌ها همچنان v3.1 غالب است؛ بنابراین قاعده‌ی حرفه‌ای این است که همیشه بردار کامل و نسخه را بنویسید، نه فقط یک عدد. v4.0 برای همین منظور نام‌گذاری CVSS-B، CVSS-BT و CVSS-BE را معرفی کرد تا مشخص باشد امتیاز شما بر پایه‌ی کدام گروه از سنجه‌ها محاسبه شده است.
| وضعیت گزارش | معنا | پاداش؟ |
|---|---|---|
| Triaged / Accepted | بازتولید و تأیید شد و برای رفع ارجاع شده است. | بله |
| Duplicate | پیش‌تر پژوهشگر دیگری همان مسئله را گزارش کرده بود. | خیر |
| Informative | یافته درست است اما اثر امنیتی قابل اتکایی ندارد. | معمولاً خیر |
| Out of scope | دارایی یا کلاس آسیبپذیری در محدوده نبوده است. | خیر |
| Not applicable | یافته اشتباه است یا بازتولید نشد. | خیر |
| Won't fix / Accepted risk | تأیید شد اما سازمان تصمیم گرفته ریسک را بپذیرد. | بستگی به سیاست برنامه |
نرخ تکراری بزرگ‌ترین عامل ناامیدی تازه‌واردان است و منطق روشنی دارد: یافته‌های سطحی در یک برنامهی عمومی توسط ده‌ها نفر به‌طور موازی و با ابزارهای مشابه پیدا می‌شوند.
«اگر شدت CVSS بالا بنویسم، پاداش بیشتری می‌گیرم.» بزرگ‌نمایی شدت سریع‌ترین راه از دست دادن اعتبار نزد تیم تریاژ است. امتیاز پایه‌ی CVSS (یعنی CVSS-B) عمداً مستقل از محیط محاسبه میشود؛ زمینه‌ی سازمانی در گروه سنجه‌های محیطی وارد میشود که در اختیار مالک برنامه است، نه شما. کار شما نوشتن بردار درست و توضیح اثر واقعی کسب‌وکاری است — همان چیزی که واقعاً پاداش را بالا می‌برد.
چرا باگ بانتی جانشین تست نفوذ نیست؟
این بخش را صریح می‌نویسیم، چون اشتباه در آن پرهزینه است. باگ بانتی مکمل تست نفوذ است، نه جانشین آن، و چهار دلیل ساختاری دارد:
- نبود تضمین پوشش. هیچ‌کس متعهد نیست ماژول مدیریت مالی شما را آزمون کند. بخش‌هایی که راه‌اندازی حساب پیچیده یا جریان کاری چندمرحله‌ای لازم دارند از دید شکارچیان کم‌بازده‌اند و نادیده می‌مانند — در حالی که دقیقاً همان‌جا باگ‌های منطق کسب‌وکار زندگی می‌کنند.
- اقتصاد معکوس در آغاز کار. اگر برنامه را پیش از رفع مشکلات آشکار باز کنید، برای یافته‌هایی پاداش می‌دهید که یک ارزیابی امنیتی ساده هم آن‌ها را پیدا می‌کرد: هدرهای امنیتی، پیکربندی نادرست و نسخه‌های افشاشده. هزینه‌ی هر یافته در بازار باگ بانتی چند برابر هزینه‌ی رفع پیشگیرانه‌ی آن است.
- نبود خروجی قابل استناد. جریان گزارش‌های پراکنده جایگزین یک گزارش تست نفوذ با خلاصه‌ی مدیریتی و برنامهی اولویت‌دار رفع نمی‌شود؛ برای ممیز و مشتری سازمانی، سند دوم لازم است.
- سرریز تریاژ. برنامهی عمومی بدون آمادگی، حجمی از گزارش‌های کم‌ارزش تولید میکند که ظرفیت تیم امنیت را می‌بلعد و گزارش‌های جدی را در صف گم میکند.
ترتیب درستی که توصیه می‌کنیم
- موجودی دارایی: فهرست کامل دامنه‌ها، زیردامنه‌ها و APIها؛ چیزی که نمی‌دانید وجود دارد را نمی‌توانید در اسکوپ بگذارید.
- تست نفوذ وب با پوشش متدولوژیک و گزارش قابل اقدام.
- رفع و آزمون مجدد — بیشترین بازگشت سرمایه‌ی امنیتی همین‌جاست.
- VDP برای ساختن کانال و تمرین فرایند پاسخ.
- برنامهی خصوصی با تعداد محدودی پژوهشگر دعوت‌شده، برای سنجش ظرفیت تریاژ.
- برنامهی عمومی، فقط وقتی سه مرحلهی قبل پایدار شده‌اند.
اگر نمی‌دانید سازمان شما در کدام پله از این نردبان است، جلسه‌ی مشاوره نقطه‌ی شروع درستی است؛ و اگر پژوهشگرید، پیش از شروع اقتصاد واقعی درآمد باگ بانتی را بخوانید.
پرسش‌های متداول
باگ بانتی چیست و چطور کار میکند؟
برنامهای که در آن یک سازمان بهصورت عمومی به پژوهشگران مستقل اجازه میدهد داراییهای مشخصی از آن را با قواعد مشخص آزمون کنند و برای هر آسیبپذیری معتبر و تازه پاداش میپردازد. چرخهی کار این است: خواندن اسکوپ ← آزمون داخل محدوده ← ارسال گزارش ← تریاژ و بازتولید ← تعیین شدت ← پرداخت ← رفع.
آیا باگ بانتی قانونی است؟
داخل محدودهی منتشرشدهی یک برنامه، بله — چون سازمان صریحاً مجوز داده است. بیرون از آن محدوده یا روی سامانهای که هیچ برنامه و مجوزی ندارد، خیر؛ این دسترسی غیرمجاز است و در قانون جرائم رایانهای جرم محسوب میشود. مجوز شما بهاندازهی متن سیاست برنامه است، نه بیشتر.
تفاوت باگ بانتی و تست نفوذ در یک جمله چیست؟
تست نفوذ پوشش تضمینشده را در بازهی زمانی مشخص و با پرداخت قراردادی میخرد؛ باگ بانتی تنوع نگاه را در طول زمان و با پرداخت بهازای نتیجه میخرد. اولی به شما میگوید چه چیزی بررسی شد، دومی فقط میگوید چه چیزی پیدا شد.
اگر سایتی برنامهی باگ بانتی نداشته باشد می‌توانم تستش کنم؟
خیر. نبود برنامه یعنی نبود مجوز، و هیچ استدلالی — از جمله «فقط اسکن کردم» یا «قصد کمک داشتم» — این را تغییر نمی‌دهد. اگر سازمانی سیاست افشای مسئولانه دارد، می‌توانید یافته‌ای که اتفاقی دیده‌اید را از همان کانال گزارش کنید، اما جست‌وجوی فعال نیازمند مجوز است. برای تمرین از آزمایشگاه‌های عمداً آسیب‌پذیر استفاده کنید.
گزارش تکراری یا Duplicate یعنی چه و پاداش دارد؟
یعنی پیش از شما پژوهشگر دیگری همان مسئله را گزارش کرده و برنامه آن را ثبت کرده است. معمولاً پاداشی به گزارش تکراری تعلق نمی‌گیرد. راه کاهش نرخ تکراری، دور شدن از یافته‌های سطحی و ابزارمحور و نزدیک شدن به منطق اختصاصی کسب‌وکار است.
VDP چیست و آیا پاداش میدهد؟
VDP یا برنامهی افشای آسیبپذیری، یک کانال رسمی گزارشدهی همراه با تعهد عدم پیگرد قانونی (Safe Harbour) است و پاداش نمیپردازد. هدفش این است که یابندهی صادق یک مسیر امن داشته باشد. هر سازمانی باید VDP داشته باشد؛ باگ بانتی مرحلهی بعد و پرهزینهتر است.
منابع
امیر پیامنی
شکارچی ضعف‌های زیرساخت؛ از نقشه‌برداری سطح حمله تا بهره‌برداری از سرویس‌های شبکه و حرکت جانبی داخل دامنه.