Bug Bounty Program Setup

Bug bounty programs find what nobody else does. The setup.

Scope

A bug bounty program is a structured way to invite external security researchers to find vulnerabilities in your systems in exchange for monetary rewards. Done well, it is a high-leverage source of vulnerability discovery. Done poorly, it produces noise, frustration, and security debt. The first decision in setting up a program is what is in scope and what is out.

What good scope looks like:

• Public-facing assets first.: The program starts with assets that are already accessible to anyone on the internet. Customer-facing web applications, public APIs, marketing sites. These assets are already under attack from external actors; legitimizing the testing surfaces the same vulnerabilities through a friendly channel.
• Internal too risky for public bounty.: Internal systems, employee-only tools, and infrastructure that requires VPN access are typically out of scope for a public bounty program. The risk of researcher action causing operational impact is high; the reward of testing is lower because external attackers cannot reach these surfaces directly.
• Bounded; defensible.: The scope is explicit. Specific domains, specific subdomains, specific applications. Out-of-scope items are listed: third-party services, social engineering, physical attacks, denial of service. The boundary is clear so researchers know what they can test and what is off-limits.
• Excludes denial of service.: DoS testing is excluded universally. The risk-reward favors exclusion: a researcher can take down production by accident; the discovered vulnerability is rarely actionable.
• Excludes social engineering.: Testing employees, support staff, or third-party contractors via social engineering is excluded. The legal and HR implications are too complex for a bounty program.

The scope determines the program's risk profile. A well-bounded scope produces useful submissions; a sloppy scope produces drama.

Rates

The bounty rates determine which researchers participate. Too low, and serious researchers ignore the program; too high, and the budget breaks. Industry-competitive rates produce a steady flow of high-quality submissions.

• Critical: $5k or more.: Critical vulnerabilities (RCE, authentication bypass, mass data exposure) earn at least $5,000. The top end can go to $25,000 or more for the most impactful findings. The high rates attract the researchers who can find these.
• High: around $1k.: High-severity vulnerabilities (privilege escalation, significant data exposure, broken authentication) earn around $1,000. The rate is competitive with platforms like HackerOne and Bugcrowd standard tiers.
• Medium: around $250.: Medium-severity vulnerabilities (XSS without significant impact, CSRF on non-critical endpoints, IDOR with limited scope) earn around $250. The rate is enough to make submission worthwhile without breaking the budget on the high volume of medium-tier findings.
• Low: thanks plus credit.: Low-severity findings often earn no bounty but receive credit in the security hall of fame. Some researchers care about the credit; others do not. The credit-only tier filters submissions to those that meet the bar.
• Competitive with industry.: The rates are benchmarked against published programs (HackerOne, Bugcrowd, similar-sized companies). Below-market rates lose researchers to competitors; above-market rates inflate the budget without buying additional quality.

Rates are the lever that brings researcher attention. The right rates produce a steady supply of submissions; the wrong rates produce silence or budget overruns.

Triage

The triage process determines whether the program produces value. Researchers who submit good reports and get prompt, fair responses come back; researchers who get ignored or ghosted leave and tell others to leave too.

• Dedicated triage team.: The triage is owned by a specific team or person. Submissions do not sit in a shared queue with no owner. The triager has the security knowledge to assess severity and the engineering relationships to drive remediation.
• SLA on response.: Researchers know when to expect a response. First response within 1 to 3 business days; severity decision within 5 to 7; bounty payment on a defined schedule. The SLA is published; the program holds itself to it.
• Quality matters; reputation builds.: A program that pays fairly, communicates clearly, and respects researchers builds a reputation that attracts more submissions. A program that haggles, delays, and disputes builds the opposite reputation. Word travels fast in the researcher community.
• Severity disagreements handled professionally.: Sometimes the researcher and triage team disagree on severity. The disagreement is handled with technical evidence; the researcher can appeal; the program publishes its severity rubric so the basis for decisions is visible.
• Hall of fame for credit.: Researchers who submit accepted findings appear in a public hall of fame (with permission). The recognition is meaningful; many researchers value the credit alongside the bounty.

A bug bounty program is a long-term investment in external security capacity. Nova AI Ops integrates with bug bounty platforms, surfaces submission trends, and produces the metrics (mean time to triage, mean time to remediation, severity distribution) that show the program is working as intended.