A bounty table is the reward structure used to determine how findings are valued in a bug bounty program. It links the severity or quality of a report to a payment or recognition level, helping set expectations, support fairness, and encourage useful submissions rather than noisy ones.
Expanded Definition
A bounty table is the published reward rubric that converts a bug bounty submission into a payment or recognition outcome. It usually maps severity, exploitability, novelty, and report quality to tiers so researchers know what the programme values before they submit. The table is not the same as the programme rules, but it depends on them because eligibility, scope, and duplicate handling change how a report is paid.
The main boundary is that a bounty table describes valuation, not discovery. It should not be confused with vulnerability severity scoring, which ranks technical impact, or with programme policy, which decides whether a finding is in scope at all. In practice, the bounty table is partly a governance tool: it reduces ambiguity, discourages spam, and makes reward decisions more consistent across reviewers. Where programmes use discretionary awards, the table still acts as the baseline expectation and the public reference point for fairness.
Consensus is fairly strong that clear reward structures improve researcher experience, but there is less consensus on how granular the tiers should be. A very simple table is easier to understand, while a highly detailed one can better distinguish unusually valuable work.
Examples and Use Cases
Bounty tables appear in several common programme patterns, each shaping researcher behaviour differently:
- A simple four-tier table may pay fixed amounts for low, medium, high, and critical findings, giving researchers a fast way to estimate likely reward.
- A quality-weighted table may pay more for reports that include a working proof of concept, strong reproduction steps, or evidence of broader impact.
- A programme may use separate rows for web application flaws, mobile issues, and infrastructure findings because the same severity label does not always reflect the same investigative effort.
- A disclosure programme may combine cash and recognition tiers, where public credit or hall-of-fame placement matters alongside direct payment.
- A staged table may start with a minimum award and then increase payment after triage confirms severity, which helps manage uncertainty but can feel opaque if criteria are not explicit.
Well-written tables also help reduce noise from low-value submissions because researchers can see that trivial findings will not be rewarded at the same level as actionable, reproducible issues. In practice, the clearest tables are those that describe both the reward level and the evidence expected for each tier.
Security Implications
A poorly designed bounty table can create predictable failure modes in a bug bounty programme. If low-quality reports are over-rewarded, the programme attracts spam, duplicates, and speculative submissions that consume triage capacity. If the table is too harsh or too vague, researchers may stop reporting valuable findings, especially those that require more effort to prove. In both cases, the organisation loses signal quality.
Another common failure is reward mismatch. When the table does not distinguish between superficial defects and materially exploitable issues, reviewers may pay inconsistently, which undermines trust in the programme. That inconsistency can lead to researcher attrition and public criticism, even if the underlying security team is technically competent.
The practical symptom is often not a breach but a degraded intake pipeline: slower triage, more disputes, and a growing backlog of weak reports that obscure the findings that matter. The security consequence is that serious vulnerabilities can take longer to surface and validate because reviewer attention is spent on avoidable noise.
Domain and Governance Relevance
Bounty tables matter in the governance of disclosure programmes because they define how an organisation operationalises value, fairness, and scope. They are part of the control surface for crowdsourced security: the table influences researcher incentives just as much as the rules influence eligibility. A table that is transparent and aligned to risk helps the programme behave like a managed security process rather than an ad hoc reward scheme.
For identity and access-related programmes, the same structure can also affect how findings involving accounts, tokens, or automation are valued, but that is a consequence of the programme’s scope rather than the core meaning of the term. The central governance question remains whether the table creates reliable, defensible reward decisions that support sustained researcher participation.
NHIMG treats the bounty table as a practical trust mechanism: it is where policy becomes visible to the outside researcher community. If the structure is unclear, the programme may technically exist yet still fail to produce the quality of submissions it was designed to encourage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 14 — Security Awareness and Skills Training | Clear bounty criteria shape reporter behavior and reduce noisy submissions. |
| Recommendation — Use CIS Control 14 to define reward criteria that encourage high-quality vulnerability reporting. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Bounty tables operationalise how a programme values findings against risk. |
| GV.OV-01 — Organizational Context | Reward tiers should reflect the programme's scope, assets, and disclosure goals. | |
| DE.CM-08 — Vulnerability Disclosure | A bounty table sits inside the disclosure workflow that ingests and triages findings. | |
| Recommendation — Align the bounty table to risk tolerance so rewards reflect security impact. Tie reward tiers to programme scope and business context before publishing them. Use the disclosure process to route reports into the correct reward tier. | ||
| MITRE ATT&CK | T1595 — Active Scanning | Bounty programmes must distinguish useful findings from broad, low-signal probing. |
| Recommendation — Filter repetitive scanning-style submissions so only actionable findings are rewarded. | ||
Related resources from NHI Mgmt Group
- Should organisations use bug bounty programs as their only vulnerability disclosure channel?
- How should security teams handle leaked credentials reported outside bug bounty scope?
- What is the difference between a bug bounty program and a vulnerability disclosure policy?
- What breaks when identity controls stop at table-level permissions?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 10, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
