Assigning Severity to Bug Bounty Reports Without Starting a War

Severity is where triage gets political. A verdict of "valid" makes everyone happy. A verdict of "valid, but Medium, not Critical" starts a negotiation: with the researcher who wants a bigger bounty, with the engineer who wants a smaller backlog, and occasionally with a VP who read the word "injection" in a summary and wants to know why production isn't shut down.

Severity is a judgment call dressed up as a number, and the triager's job is to make that call defensible.

Why CVSS arithmetic breaks down in bug bounty

CVSS was designed to describe vulnerabilities in published software, where the scorer doesn't know how any particular organization deploys it. Bug bounty is the opposite situation: the report is about your deployment, your data, your controls. Ignoring that context to preserve the purity of the formula produces scores that are precise and wrong.

Some familiar failure modes:

• The 9.8 that isn't. An SQL injection in an internal admin panel that sits behind SSO, an IP allowlist, and an audit log scores like the end of the world in base CVSS. In context, exploitation requires an already-compromised employee account. Real, worth fixing, not a drop-everything Critical.
• The 4.3 that is. An IDOR that leaks one field (say, another user's email address) looks Low on paper. If the endpoint enumerates cleanly across your entire user base, you're one for loop away from a reportable data breach. Impact scales with iteration, and base CVSS doesn't iterate.
• Chained findings. A self-XSS is nothing. A self-XSS plus a login CSRF is an account takeover. Score the chain, not the links, and expect researchers to (correctly) submit the chain.

None of this means CVSS is useless. It's a decent shared vocabulary and a reasonable starting point. It just can't be the final answer, which is why platforms layer their own systems (Bugcrowd's VRT, HackerOne's severity guidelines) and why mature programs reserve the right to adjust for environmental context.

What we actually weigh

When our triagers propose a severity, the reasoning follows four questions, roughly in order:

1. What can an attacker actually get?

Not the vulnerability class, the outcome. "Stored XSS" isn't an impact; "session takeover of any user who views the shared dashboard" is. We push every finding to its realistic end state: data read, data modified, account compromised, money moved, availability lost. If the honest answer is "an alert box on their own screen," that's the answer that goes in the assessment.

2. Who can do it, and from where?

Pre-auth versus post-auth is often worth a full severity band. So is "any internet user" versus "a paying tenant" versus "an employee." Prerequisites matter too, but be careful: triagers love to discount for prerequisites that attackers don't find inconvenient at all. "Requires the victim to click a link" has never slowed a phishing campaign down.

3. How far does it scale?

One user's invoice is an incident. Every user's invoice is a headline. We explicitly test whether a finding enumerates: does the IDOR work across sequential IDs? Does the leak repeat across tenants? A vulnerability that scales linearly with attacker effort deserves to be scored at scale, because that's how it will be exploited.

4. What does the business around it look like?

The same bug is not the same severity everywhere. Account takeover on a meme generator and account takeover on a payroll platform are different events. This is the part a purely in-house or purely formulaic process tends to get wrong in opposite directions: outsiders miss business context, insiders normalize it ("oh, that internal tool, nobody cares," said of the internal tool with production database credentials in it).

Write the reasoning down, not just the rating

A bare "Severity: Medium" invites a fight. A paragraph explaining why (what the realistic impact is, what limits it, what would make it worse) usually prevents one. It gives the researcher something to engage with beyond a number, and most good-faith researchers will accept a downgrade that comes with visible reasoning, even when they disagree.

The same paragraph does double duty internally. Engineers prioritize better when they understand the impact story, and six months later, when someone asks why a finding was rated the way it was, the answer exists in writing instead of in a departed triager's head.

A format that has served us well:

Proposed severity: High

Impact: Authenticated user can read any tenant's invoices
(confirmed across 3 test tenants; IDs enumerate sequentially).
Exposed fields include line items, billing address, and last-4.

Limiting factors: Requires a valid account on any paid plan.
No write access. Access is logged, but alerts don't fire on volume.

Would escalate to Critical if: unauthenticated access, or if
full payment card data were exposed.

Handling the disagreements

Even with written reasoning, you'll get pushback. Some of it will be right. Researchers sometimes see an escalation path the triager missed, which is one reason reports that demonstrate impact clearly earn better outcomes. A few rules keep disagreements productive:

• Re-test before you re-argue. If the researcher claims the impact is bigger, verify the claim instead of defending the original rating. Being persuadable is cheaper than being wrong.
• Never negotiate the number directly. Negotiate the impact story. If you agree on what an attacker can do, the severity usually settles itself.
• Separate severity from bounty. Severity describes risk; bounty policy describes money. Programs that let bounty-budget pressure leak into severity ratings end up with a queue full of mysteriously Medium criticals. Researchers notice, and the good ones leave. Slow, opaque severity fights are one of the fastest ways to bleed talent, as we covered in our piece on triage metrics.
• Publish your deviations. If your program consistently rates certain classes below platform defaults (say, all clickjacking is Informative), put it in your policy. Every argument you have in public scope documentation is ten you don't have in the queue.

Severity inflation is a tax on everyone

A last word on the elephant: researchers are incentivized to argue severity up, and the rise of AI-assisted report writing has made inflated impact narratives cheaper to produce than ever. The counterweight isn't cynicism. It's reproduction. A triager who has actually exercised the finding knows exactly where the impact story ends and the creative writing begins, and can say so with specifics.

Severity calls are only as good as the reproduction behind them. TRIAGERS™ provides on-demand triage teams that validate, reproduce and severity-rate every report in your queue, with reasoning attached. If that sounds useful, get in touch.