Disclaimer: This guide provides general recommendations for creating program descriptions and scopes based on industry observations. The content, including bounty ranges, vulnerability classifications, and legal terms, should be treated as reference points rather than definitive standards. Each organization should evaluate their specific security needs, industry regulations, legal requirements, and risk profiles when creating their program documentation. Bugbop does not guarantee any specific results or outcomes based on following these guidelines. We recommend consulting with security and legal professionals before finalizing your program terms.
An effective program description is essential for setting clear expectations with Bug Hunters. A
well-crafted description communicates your organization's commitment to security and helps researchers
understand what you're looking for.
Elements of a Great Program Description
Your program description should include:
Welcoming introduction: Make researchers feel invited and valued
Brief company overview: Help researchers understand what your organization does
Security commitment: Express your dedication to security and vulnerability remediation
Researcher value: Explain how researcher contributions help your organization
Clear expectations: Set the tone for professional interactions
Example Introduction
"We're excited to invite security researchers from all backgrounds to help us make BugBop a more secure
platform for everyone. Our commitment to security is a core value, and we believe that working with the
security community is essential to maintaining the trust of our users."
Defining Scope
A well-defined scope helps researchers focus on the right assets and prevents misunderstandings about
what's acceptable to test.
In-Scope Assets
Clearly define the systems and applications researchers are permitted to test:
Be specific about domains and subdomains
Include IP ranges if applicable
Specify mobile applications if they're included
List API endpoints if they're part of your scope
Include version information for testable software
Out-of-Scope Assets
Explicitly state what researchers should NOT test, such as:
Third-party services and providers
Physical locations and social engineering
Non-production environments (unless specified)
Legacy systems scheduled for retirement
Recently acquired systems not fully integrated
Important: Being explicit about out-of-scope assets prevents unnecessary testing and potential disruptions to your services or third-party relationships.
Example Scope Definition
In-Scope Assets:
Main Web Application: https://bugbop.com
Publicly Accessible Subdomains: *.bugbop.com
Mobile Applications: iOS and Android apps (latest release versions)
Public API: api.bugbop.com
Out-of-Scope Assets:
Any services hosted by third parties, unless they impact the security of our primary assets
Marketing pages (e.g., blog, landing pages)
Physical offices and social engineering
Third-party plugins that we use but do not develop
Vulnerability Types
Help researchers understand what types of vulnerabilities are valuable to your program and which ones
aren't worth reporting.
In-Scope Vulnerabilities
List the types of vulnerabilities you're most interested in receiving:
Prioritize based on your technology stack and business risks
Consider including severity guidelines for each vulnerability type
Focus on vulnerabilities that present actual security risks
Out-of-Scope Vulnerabilities
Specify vulnerabilities that you don't want reported:
Low-impact issues that create noise in your program
Known issues that you've accepted the risk for
Theoretical vulnerabilities without practical exploit paths
Issues that require unlikely user interaction
Example Vulnerability Classification
Vulnerabilities We're Interested In:
Cross-Site Scripting (XSS)
SQL Injection
Authentication bypass
Privilege escalation
Remote Code Execution (RCE)
Security misconfigurations
Server-side request forgery (SSRF)
Vulnerabilities Out-of-Scope:
Issues solely affecting outdated browsers
Missing HTTP security headers (unless they lead to a proven vulnerability)
Vulnerabilities requiring physical access
Self-XSS requiring significant user interaction
Reports from automated tools without clear evidence of impact
Theoretical vulnerabilities without proof of exploitation
Reward Structure
A clear reward structure helps researchers understand the value of different findings and incentivizes
quality reports.
Setting Appropriate Rewards
Consider these factors when determining your reward structure:
Program budget: Align rewards with your available budget
Asset criticality: Offer higher rewards for critical systems
Vulnerability impact: Base rewards on potential damage
Industry standards: Research what similar programs offer
Example Reward Structure
We offer bounties based on the severity and impact of the vulnerability:
Critical: Full system compromise or large-scale breach
E.g. Remote Code Execution (RCE), database access
High: Access to sensitive data or elevated privileges without full compromise
E.g. Privilege escalation, significant data exposure, authentication bypass
Medium: Abuses that require some user interaction or unusual conditions
E.g. Cross-Site Scripting (XSS), CSRF, minor API issues
Low: Mostly informational or minor misconfigurations
E.g. Information disclosure without direct impact, missing security headers
Note: Reports without clear security implications or that require unrealistic attack
scenarios will not be rewarded.
Suggested Bounty Ranges
The bounty amounts you offer directly impact the level of testing interest and researcher engagement your
program will receive. Below is a guide to industry norms and what to expect at different reward tiers:
No Bounties, Disclosure Only
Bounty Ranges:
None - Thanks only
What to Expect:
Your existing users that find a security bug and decide to raise it. Beginners wishing to raise their reputation on platforms.
Note: By using Bugbop, the Bug Hunters can showcase their success via their public profile page which can be valuable despite no bounty being paid.
Entry Level Programs
Bounty Ranges:
Critical: $100-$500
High: $50-$350
Medium: $25-$200
Low: Thanks ($0)-$50
What to Expect:
Low to moderate testing interest, primarily from beginners and
hobbyists. Best for small startups and initial programs.
Note: Even modest bounties significantly increase engagement, as they provide enough incentive for researchers to run automated tooling, conduct basic manual testing, and raise bug reports.
Growing Programs
Bounty Ranges:
Critical: $500-$2,000
High: $350-$1,400
Medium: $200-$800
Low: $50-$200
What to Expect:
Moderate testing interest from a mix of hobbyists and
part-time researchers. Suitable for growing startups and medium-risk applications.
Established Programs
Bounty Ranges:
Critical: $2,000-$5,000
High: $1,400-$3,500
Medium: $800-$2,000
Low: $200-$600
What to Expect:
Substantial testing interest from experienced researchers and
some full-time hunters. Ideal for established companies with high-value applications.
Premium Programs
Bounty Ranges:
Critical: $5,000-$15,000
High: $3,500-$10,000
Medium: $2,000-$6,000
Low: $600-$2,000
What to Expect:
High testing interest from professional researchers and
security specialists. Appropriate for large enterprises, financial services, and healthcare
organizations.
Elite Programs
Bounty Ranges:
Critical: $15,000+
High: $10,000+
Medium: $6,000+
Low: $2,000+
What to Expect:
Very high testing interest from elite researchers and
specialized security teams. Suitable for critical infrastructure and major tech companies.
Note: These ranges reflect industry averages across all
severity levels. Actual bounties should be tailored to your organization's specific security needs, risk
profile, and budget.
Consider additional rewards for exceptional reports, such as clear documentation, creative exploit chains, or suggestions for effective mitigations.
Submission Guidelines
Clear submission guidelines help researchers provide the information you need to validate and fix
vulnerabilities efficiently.
What to Include
Request that researchers include these elements in their reports:
Impact description: How the vulnerability could affect your system or users
Supporting evidence: Screenshots, videos, or code snippets
Suggested fix: Potential solutions (optional but appreciated)
Attack scenario: Real-world exploitation examples
Testing Rate Limits
To ensure the stability of your systems and prevent unintended disruptions, include clear rate limit guidelines:
API requests: Maximum number of requests per minute/hour
Authentication attempts: Limits on login/signup attempts
Email/SMS triggers: Restrictions on actions that generate notifications
Form submissions: Limits on submission frequency
Resource-intensive operations: Guidelines for testing heavy operations
Updating Program Scope and Bounties
As your program matures, you may need to update your scope or bounty structure. Here are some best
practices for making these changes:
When to Update Your Program
Scope expansion: When adding new products, services, or domains to your organization
Scope reduction: When retiring systems or moving assets out of scope
Clarity: If a class of bug is repeatedly closed as "Won't fix" or "N/A", be more explicit in your scope to exclude it
Bounty increases: When you have budget available and want to attract more researchers
Focusing research: When you want to direct attention to specific parts of your
application
Subscribers of your program will receive a notification that your program scope has been updated with an AI summary of your changes.
When decreasing bounties or removing scope, honor the previous terms for any findings that were already in progress.
Template
Below is a comprehensive template for your program description and scope document. Feel free to customize
it to fit your specific needs.
[YOUR ORGANIZATION NAME] Bug Bounty Program
Welcome
We're excited to invite security researchers from all backgrounds to help us make [YOUR ORGANIZATION NAME] a
more secure platform for everyone. Your expertise helps us identify vulnerabilities before they can be
exploited, and we value your contributions to our security efforts.
Program Scope
We appreciate reports that can help us improve our security posture. Please review the
following details carefully before submitting your findings.
In-Scope Assets
Main Web Application: https://YOURTESTED_DOMAIN.COM
Any services hosted by third parties, unless they impact the security of our primary assets.
Marketing pages (e.g., blog, landing pages).
Physical offices and infrastructure.
Employee social media accounts.
Vulnerabilities We're Interested In
Cross-Site Scripting (XSS)
SQL Injection
Authentication bypass
Privilege escalation
Misconfigured access controls
Remote Code Execution (RCE)
Security misconfigurations
Server-side request forgery (SSRF)
[LIST ANY OTHER TYPE OF VULNERABILITIES]
Vulnerabilities Out-of-Scope
Issues solely affecting outdated browsers
Missing HTTP security headers (unless they lead to a proven vulnerability)
Vulnerabilities requiring physical access
Self-XSS requiring significant user interaction
Reports from automated tools without clear evidence of impact
Theoretical vulnerabilities without proof of exploitation
Rewards
We offer bounties based on the severity and impact of the vulnerability:
Critical: Full system compromise or large-scale breach E.g. Remote Code Execution (RCE), database access, admin panel access
High: Access to sensitive data or elevated privileges without full compromise E.g. Privilege escalation, significant data exposure, authentication bypass
Medium: Abuses that require some user interaction or unusual conditions E.g.: Cross-Site Scripting (XSS), CSRF, minor API issues
Low: Minor misconfigurations or information disclosure E.g.: Information disclosure without direct impact, missing security headers
Note: Reports without clear security implications or that require unrealistic attack scenarios will
not be rewarded.
Submission Guidelines
Provide clear, step-by-step instructions to reproduce the vulnerability
Include screenshots, videos, or code snippets where possible
Test only on your own accounts; do not access others' data
Describe the potential impact and attack scenario
Be respectful of our users' privacy and our systems' stability
Rate Limits & Testing Constraints
Limit requests to no more than 10 requests per minute
Avoid testing that triggers excessive emails or notifications (max 5 per hour)
Limit login/authentication attempts to 10 per hour
Avoid any testing that could impact system availability or other users
Our Commitment
We will acknowledge your report within [AMOUNT OF TIME] hours/business days
A resolution or update will be provided within [AMOUNT OF TIME] business days
We will keep you informed about the status of your report
We will recognize your contribution if you wish to be acknowledged
Legal Safe Harbor
This program follows a "safe harbor" approach. As long as your research is conducted responsibly and
within the program's scope, we consider it authorized. If legal questions arise, we'll work with you to
understand and resolve them.
Need help with your Program scope?
Our security experts can guide you through creating an effective bug bounty program tailored to your organization's needs.
