Bug Triage: Why Severity Beats Priority and Your Process Is Backwards

You think bug triage is about sorting bugs by priority. You're wrong.

Priority measures how urgent a fix is. Severity measures how much damage the bug can do. When you triage by priority first, you're asking "who's screaming the loudest?" — not "what's actually going to break?" That's how a cosmetic glitch on the CEO's laptop jumps the queue while a memory leak slowly corrupts your customer database. (Atlassian's own guidance separates the two: priority is about urgency, severity about impact.)

I'm not saying priority doesn't matter. It does — for scheduling. But triage is about sorting, and sorting by severity is the only way to catch the bugs that will kill you. Here's the head-to-head: the classic Scrum-style triage (priority-first) versus a severity-first triage that borrows from vulnerability management. I'll show you why severity-first wins for any team that ships software people rely on.

The Two Contenders: Priority-First vs. Severity-First

The default in most bug trackers is a priority field. You set it to High, Medium, Low, and you're done. That's the priority-first approach. It's fast, but it's reactive. The other way — severity-first — starts with a question: "How bad is this bug?" Only after you answer that do you ask "How urgent?"

For security vulnerabilities, the industry already does this. The National Vulnerability Database (NVD) enriches every CVE with a CVSS score — a numerical severity rating based on impact metrics. CVSS isn't perfect, but it's a standardized way to compare apples to oranges. (NVD hosts CVSS v2.0, v3.x, and v4.0 calculators, so you can see how severity changes across versions.)

In the bug-tracking world, severity levels are usually Fatal/Blocker (system crash), Critical, Major, and Minor/Trivial. Priority levels run from Lowest/Trivial up to Highest/Blocker. The two scales look similar, but they're measuring different things. Severity is intrinsic to the bug. Priority is a business decision.

Here's the concrete example. A bug that crashes the app on a specific obscure device is High severity — it's a crash. But if only 0.1% of users have that device, priority might be Low. A bug that shows the wrong price on a product page for all users is also High severity — it's a revenue killer. Priority should be High too. The point is you can't set priority until you know severity.

Now, which approach is better? It depends on your context. If you're a tiny startup shipping a weekend side project, priority-first is fine — you're just trying to keep the lights on. But if you're building software that handles money, health data, or national infrastructure, severity-first is non-negotiable.

Three Tests: Impact, Exploitability, and Urgency

Let's compare the two approaches on three concrete criteria: impact, exploitability, and urgency. These are the dimensions that matter for triage.

Impact is obvious — severity-first wins because it forces you to think about what the bug does to the system, not who's complaining.

Exploitability is where it gets interesting. A priority-first team might triage a security bug as "Medium" because it's not in the main user flow. But if that vulnerability is in CISA's KEV catalog — meaning it's been exploited in the wild — it's not medium anything. CISA explicitly directs organizations to use KEV as an input to vulnerability management prioritization. If you're not checking KEV, you're flying blind.

Urgency is the trap. Priority-first treats urgency as the starting point. Severity-first treats it as a result. A bug that's both High severity and in KEV is urgent. A bug that's High severity but not exploited might be urgent if it's in a critical path. A bug that's Low severity is never urgent, no matter who's yelling.

Who Should Use Which (and My Verdict)

Priority-first is for teams that ship fast and don't have a dedicated security or QA process. It's the default in Jira, Bugzilla, GitHub Issues — you create a bug, set priority, and move on. It works for small teams that can keep the whole system in their heads.

Severity-first is for teams that can't afford a single disaster. If you're handling payment transactions, medical records, or control systems, you need severity-first. It's also for teams that have a formal bug lifecycle. Atlassian's recommended workflow — Open to In Progress to In Review to Done to Closed, with a Triage step — is built for this. That triage step is where you assign severity, not just priority.

My verdict: severity-first wins for any team that has more than a handful of bugs at a time. Here's why.

• It aligns with how vulnerabilities are actually tracked — CVSS and KEV are severity-based.
• It prevents the classic failure: a "High priority" bug that turns out to be a minor cosmetic issue, while a "Medium priority" bug silently corrupts data.
• It makes your triage defensible. You can point to a CVSS score or a severity level and say "this is why this bug is in the queue."

But here's the nuance: severity-first doesn't mean you ignore priority. It means you set priority after you assign severity. The two work together — severity tells you impact, priority tells you order. The mistake is letting priority override severity.

For a concrete example, consider a bug that causes a NullPointerException in a rarely used admin report. Severity: Major (it's a crash, but in a non-critical path). Priority: Low (only admins see it, and they can work around it). That's a defensible triage decision. The bug sits in the backlog until a sprint opens up. Now take a bug that allows unauthenticated users to access another user's data. Severity: Fatal/Blocker. Priority: Highest. You drop everything to fix it. That's severity-first in action.

And if that data-access bug also happens to be in CISA's KEV catalog, you don't even need to think about priority — it's a must-fix today. CISA provides a remediation due date for each KEV entry, so you have a hard deadline.

Building a Severity-First Triage in Your Tracker

You don't need a fancy tool to do this. Here's a simple workflow you can implement in Jira, Bugzilla, or even a shared spreadsheet.

First, define severity levels. Use the five common ones: Blocker (system crash), Critical (major functionality broken), Major (minor functionality broken), Minor (cosmetic or edge case), Trivial (no impact). Write a one-line definition for each so your team doesn't argue.

Second, make severity a required field on every bug. In Bugzilla, you can customize the fields to enforce this. The goal is to force the reporter to think about severity, not just priority.

Third, add a triage step in your workflow. Atlassian suggests a Triage step between Open and In Progress. That's where a human (or a small team) reviews the bug, confirms severity, and then sets priority. If the bug is a security vulnerability, check the NVD and KEV catalogs. If it's in KEV, it's automatically Blocker and due immediately.

Fourth, track your triage quality. Use metrics like defect rejection ratio — (rejected defects / total reported) × 100 — and defect leakage ratio — (production defects / total found) × 100. If your rejection ratio is high, your reporters aren't doing their homework. If leakage is high, your testers are missing things. These numbers give you a baseline for improvement.

Finally, don't forget accessibility. Accessibility bugs are often treated as low priority, but they can be just as damaging. WCAG has three conformance levels: A, AA, and AAA. If you're a public-facing site, you should probably be at AA. Track accessibility bugs against a specific WCAG version — WCAG 2.2 is the latest, published on 5 October 2023, and it's backwards compatible with 2.1 and 2.0. A bug that fails WCAG 2.2 AA is a real defect, not a nice-to-have.

Here's the thing: triage isn't about being fair. It's about being effective. Severity-first is the most effective method I know, and it's backed by how the security industry already works.

The single most important thing to remember: Severity is the truth; priority is the spin. Triage by severity first, then set priority. Your bug queue will thank you.

Sources

• Atlassian - Bug Life Cycle: https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• Atlassian - Issue Priority vs Severity: https://www.atlassian.com/software/jira/guides/issues/priorities
• NVD - National Vulnerability Database: https://nvd.nist.gov/general
• CISA - Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Bugzilla - Official Site: https://www.bugzilla.org/about/
• W3C WAI - WCAG 2 Overview: https://www.w3.org/WAI/standards-guidelines/wcag/