Bug Bounty FAQ: Scope, Duplicates, Disclosure

Bug bounty hunting is the practice of finding security vulnerabilities in software and reporting them to the vendor for a reward. This article answers the most common questions about scope, duplicate reports, disclosure policies, and other practical concerns, helping you understand how the process works before you start hunting.

Background: How Bug Bounties Started

Bug bounty programs grew out of the need for companies to get outside help finding flaws in their products. Early examples include Netscape’s 1995 “Bugs Bounty” program and later large-scale efforts by Google, Microsoft, and others. Today, platforms like HackerOne, Bugcrowd, and Intigriti host hundreds of programs from small startups to government agencies. The core idea is simple: instead of waiting for a malicious hacker to exploit a bug, a company invites ethical hackers to find and report it first, paying them for their time and skill.

Scope: What Is and Isn’t Allowed

Scope defines which assets, domains, applications, and types of vulnerabilities are eligible for a reward. Every program has a clearly stated scope, usually found in its policy page. It may include specific domains, mobile apps, APIs, or even hardware. Out-of-scope assets are off-limits; testing them can lead to legal action or a ban from the platform. Scope also lists vulnerability types—for example, some programs only accept remote code execution or SQL injection, while others include low-severity issues like missing security headers. Always read the scope carefully before you start testing. If you are unsure whether a target is in scope, contact the program’s security team through the platform’s messaging system.

How Duplicate Reports Are Handled

A duplicate is a report that describes the same vulnerability that another researcher has already submitted. Most programs use a “first come, first served” rule: the first researcher to report a unique vulnerability gets credit and the bounty. Duplicates are usually marked as such and do not earn a reward. To avoid wasting effort, check if the program has a public disclosure list or a status page that shows known issues. Also, be as specific as possible in your report—include the exact URL, parameters, and steps to reproduce. A well-written report can help the triager see that your finding is distinct from an existing one. If you believe your report is not a duplicate, you can politely ask the program to re-evaluate, but the decision is final.

Severity: How Bounties Are Determined

Severity is the measure of how serious a vulnerability is, usually rated using the Common Vulnerability Scoring System (CVSS) or a similar framework. The CVSS score ranges from 0.0 to 10.0, with categories: Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0). Programs often set bounty amounts based on severity: a critical remote code execution might pay $10,000, while a low-severity information disclosure might pay $100. However, the actual payout depends on the program’s budget and the impact on the company. When you submit a report, you can suggest a severity, but the program’s triager makes the final call. To increase your chances of a higher bounty, demonstrate real-world impact—show how an attacker could exploit the bug to steal data, take over accounts, or disrupt service.

Disclosure: Coordinated vs. Full

Disclosure refers to when and how a vulnerability is made public. Most bug bounty programs follow a coordinated disclosure policy: they ask researchers to keep the report private until the fix is released, typically within 90 days. After the fix, the researcher may publish a write-up. Some programs allow immediate public disclosure after the fix, while others require a longer wait. Full disclosure—publishing the vulnerability details without giving the vendor time to fix—is generally discouraged in bug bounty because it can put users at risk. Always follow the program’s disclosure rules; violating them can result in losing your bounty or being banned.

How to Choose a Program to Hunt

When you are starting out, pick a program that matches your skill level and interests. Look for programs with a broad scope, clear rules, and a history of paying bounties. Many platforms show the average time to first response and the number of resolved reports. Also, consider the program’s reputation: some have a reputation for being slow or unfair. Start with smaller companies or those that offer “safe harbor”—a promise not to take legal action against researchers who follow the rules. As you gain experience, you can move to higher-paying programs with stricter requirements.

Common Mistakes and Misconceptions

One common mistake is testing out-of-scope assets, which can get you in trouble. Another is submitting a report without enough detail, making it hard for triagers to verify. Many beginners also think that any bug is worth a bounty, but programs often reject low-impact issues like self-XSS or missing HTTP headers. A widespread misconception is that you need to be an expert to start; in reality, many bugs are found by using automated scanners and basic manual testing. However, you should never rely solely on scanners—they generate many false positives. Finally, do not expect to get rich quickly; bug bounty is competitive, and most researchers earn modest amounts. Treat it as a learning opportunity and a way to contribute to security.

Costs and Safety Considerations

Bug bounty hunting has minimal financial costs—you need a computer, an internet connection, and possibly a virtual machine for testing. The real cost is time, as finding valid bugs can take hours or days. Safety is a major concern: always stay within the program’s scope and rules. Never use techniques that could harm the target or other users, such as denial-of-service attacks or social engineering. Also, be careful with data you encounter during testing; do not download or access more data than necessary. If you accidentally stumble upon a critical issue, stop and report it immediately.

Alternatives to Bug Bounty

If bug bounty hunting is not for you, there are other ways to get involved in security. You can participate in open-source security audits, contribute to vulnerability databases, or join a security research group. Some companies hire full-time penetration testers or security engineers. You can also practice on intentionally vulnerable platforms like OWASP WebGoat or Hack The Box. These alternatives provide structured learning and can be less stressful than competing for bounties.

Frequently Asked Questions

What should I do if I find a bug that is out of scope?

Do not test it. Report it to the program’s security team anyway, but clearly state that it is out of scope. Many programs appreciate the heads-up and may offer a small reward or a thank you, but they are not obligated to.

How long does it take to get paid?

It varies. Some programs pay within a week after the report is validated, while others may take a month or more. The platform usually holds the bounty until the issue is resolved and the researcher provides payment details. Be patient and follow up politely if it takes longer than the program’s stated average.

Can I use automated tools for bug bounty?

Yes, but use them responsibly. Automated scanners can help you find common issues quickly, but they can also cause noise and false positives. Many programs have rules about scanning frequency and volume; check the policy. It is best to combine automated scanning with manual verification.

What if the program does not respond to my report?

If you do not get a response within a few weeks, you can send a polite reminder. If there is still no response, you can escalate to the platform’s support team. However, some programs are slow due to high volume, so be patient. Do not publicly disclose the issue until you have exhausted all options.

Is bug bounty legal?

Yes, as long as you follow the program’s rules and the laws of your country. Bug bounty programs provide a legal framework for testing, but you must stay within the defined scope. Unauthorized testing outside that scope can be illegal, even if you have good intentions.

Related

• Hermes Agent: Run It Locally or on a VPS?
• How to Use AI at Work Without Replacing Your Judgment
• LiteLLM vs OpenRouter: Which Is Safer for Production?