Bug Triage Isn't About Severity: Why 'Priority' Is the Only Number That Matters

You think you're triaging bugs correctly, but you're not. You're assigning severity levels and calling it a day. That's a mistake. Severity measures how bad a bug is; priority measures how urgent it is to fix. They're not the same thing, and conflating them leads to wasted effort and missed deadlines.

Atlassian's own guidance is explicit: priority measures urgency, severity measures impact. Yet most teams treat them as synonyms. A bug that crashes the app on a rarely used screen gets flagged as critical, while a login bug that affects every user waits in the queue. That's backwards.

Here's the truth: severity is a starting point, not a verdict. Priority is what actually matters for triage. And the only way to set priority correctly is to ask one question: Is this bug being exploited right now?

That's the mindset of security engineers. And it's the mindset you need.

What's the difference between severity and priority?

Severity is about the technical impact: does it crash the system, corrupt data, or just annoy a user? Priority is about business urgency: how quickly must it be fixed? Atlassian defines severity as how much the bug affects functionality or user experience, while priority is how urgent the fix is. A bug can be high severity and low priority—a rare crash on an outdated browser. Or low severity and high priority—a typo in a legal disclaimer that could trigger a lawsuit.

Stop using severity as a proxy for priority. It's lazy and it's wrong.

Why is severity the wrong lens for triage?

Severity is static. It describes the bug's worst-case impact, but it doesn't change with context. Priority is dynamic. It should shift as the threat landscape changes. A bug that's exploited in the wild is urgent regardless of its severity score. That's why CISA maintains the Known Exploited Vulnerabilities (KEV) catalog—it lists vulnerabilities that are actually being exploited, and CISA directs organizations to use it as an input to their vulnerability management prioritization framework. The KEV catalog doesn't rank by CVSS severity; it ranks by real-world exploitation. That's the model.

So what should drive priority?

Exploitation status. If a bug is being actively exploited, it's a blocker. If it's not, you can schedule it based on risk and impact. CISA's KEV catalog includes a remediation due date for each vulnerability, which forces you to act quickly. That's the kind of urgency you need.

But you don't have to be a security team to use this logic. For any bug, ask: is someone already taking advantage of this? If yes, drop everything. If no, you have breathing room.

Does this mean severity is useless?

No. Severity helps you understand the potential damage. It's a useful input to priority, not a replacement for it. The NVD enriches every CVE with CVSS impact metrics, which quantify severity. But CVSS scores don't tell you whether anyone cares. A 9.8 CVSS vulnerability that nobody exploits is less urgent than a 5.0 that's being actively used in ransomware campaigns. That's why CISA's KEV catalog records whether a vulnerability is known to be used in ransomware campaigns—that's a priority signal, not a severity signal.

How do I set priority without overthinking it?

Keep it simple. Use a three-tier system: Blocker, High, and Normal. Blocker means exploited in the wild or causing a critical outage. High means severe impact but not yet exploited. Normal means everything else. Don't get fancy with five levels of priority—you'll waste time debating shades of urgency.

And here's a concrete example: suppose your app has a buffer overflow that only triggers when a user uploads a malformed file. Severity is critical—it could let an attacker execute code. But if your app only processes uploads from authenticated admins, the exploit surface is tiny. Priority is low. Compare that to a minor bug that leaks a session token in the URL for all users. Severity might be medium, but priority is high because it's trivially exploitable. That's the difference.

What about accessibility bugs? Do they fit this model?

Yes, but with a twist. Accessibility defects are validated against WCAG, which has three conformance levels: A, AA, and AAA. A bug that violates a Level A success criterion is severe because it blocks access for some users. But priority should still depend on whether it's actively blocking someone. If you have a public-facing site, a WCAG 2.2 Level A failure is probably a blocker because you're legally required to meet AA in many jurisdictions. That's a priority decision based on compliance risk, not just severity.

What's the one thing to change today?

Stop triaging by severity. Start triaging by priority, and let priority be driven by exploitation status, business impact, and compliance requirements. Update your bug workflow to include a triage step that explicitly sets priority, not just severity. Atlassian's simple workflow—Open, In Progress, In Review, Done, Closed—allows for a Triage step. Use it.

Remember, severity is a label. Priority is a plan. A bug that's exploited in the wild is a race against time. CISA's KEV catalog is your starting point. Check it. If your bug is there, fix it now. If not, you have more freedom to schedule.

Sources

• Atlassian (issue priority vs severity) - https://www.atlassian.com/software/jira/guides/issues/priorities
• CISA (Known Exploited Vulnerabilities Catalog) - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD (National Vulnerability Database) - https://nvd.nist.gov/general
• W3C WAI (WCAG 2 Overview) - https://www.w3.org/WAI/standards-guidelines/wcag/