Why Your Bug Triage Is Broken and How to Fix It

You think triaging bugs is about labeling them High, Medium, or Low and moving on. You're wrong. That's not triage; that's a guessing game that will leave your team firefighting the wrong issues while the real time bombs sit quietly in your backlog. Triage is a decision-making discipline, and if you're not anchoring it to hard data, you're just shuffling tickets.

The question I'm going to answer today is blunt and specific: How do you set a priority that actually reflects what a bug deserves, not what the loudest stakeholder demands? Because if you conflate priority with severity, or treat all bugs as equal, you're not doing bug tracking — you're doing busywork. Let's fix that.

Priority and severity are not synonyms

Here's the first trap: most teams use priority and severity interchangeably, and it's killing their triage. Priority measures how urgent a bug is to fix, while severity measures how much it affects system functionality or user experience (Atlassian). A bug can be severe but not urgent — like a rare, non-exploitable crash in a legacy module that nobody uses — and a bug can be urgent but not severe — like a typo on the login page that your CEO just noticed. If you label everything "High," nothing is.

So the first rule of triage: separate the two axes. Rank severity on a scale from Fatal/Blocker (system crash) to Minor/Trivial, and rank priority on a scale from Lowest/Trivial to Highest/Blocker (Atlassian). Don't let one number do both jobs. That's not just semantics; it's the foundation of a sane workflow.

Your priority should be driven by exploitability, not gut feel

Now, how do you decide what's urgent? Too many teams rely on the most recent complaint or the most persistent reporter. That's a political system, not a triage system. Instead, anchor your urgency to real-world risk. For security vulnerabilities, the authoritative source is CISA's Known Exploited Vulnerabilities (KEV) catalog — a list of vulnerabilities that have been actively exploited in the wild. CISA directs organizations to use it as an input to their vulnerability management prioritization framework (CISA). If a bug in your stack is in the KEV catalog, that's a Highest/Blocker priority, full stop.

And don't forget the scoring side. The NVD enriches every CVE with CVSS impact metrics, a CWE type, and CPE applicability (NVD). CVSS v4.0 rates severity as None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), or Critical (9.0–10.0) (FIRST). Use that score to inform your priority, but remember: severity is not priority. A Critical CVSS score on a system that's not internet-facing might be a Medium priority for you. The KEV catalog tells you what's actually being exploited right now; the CVSS score tells you how bad it could be. Combine them.

Your workflow needs a triage step, not just a status list

Once you've got your priority and severity straight, you need a workflow that forces you to use them. The classic bug life cycle — New/Open, Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, Closed — is fine, but it's missing a gate. Atlassian suggests a simple workflow: Open to In Progress to In Review to Done to Closed, optionally adding a Triage step (Atlassian). That optional step is the difference between organized tracking and organized chaos.

Why? Because triage is where you apply your priority and severity decisions. It's where you reject duplicates, defer non-issues, and reassign bugs to the right developer. It's where you catch the "Not a Bug" or "Non-Reproducible" entries before they waste anyone's time (Atlassian). Without a formal triage step, bugs flow into the backlog like water into a leaky boat — and you spend all your time bailing instead of sailing.

Use real numbers, not anecdotes, to set your priorities

Now, let's talk about the numbers that should shape your triage. The 2024 CWE Top 25, published by MITRE and sponsored by CISA, ranks the most severe and prevalent software weaknesses. The top three are CWE-79 Cross-site Scripting (score 56.92, 3 CVEs in CISA's KEV catalog), CWE-787 Out-of-bounds Write (45.20, 18 KEV CVEs), and CWE-89 SQL Injection (35.88, 4 KEV CVEs) (CWE Top 25 ranked list). If you're triaging a bug that maps to one of these CWEs, it's a red flag. That's not a guess; it's a data-driven signal that you're dealing with a weakness that's both common and actively exploited.

And here's a concrete example to make it real. Suppose you're triaging a bug report that says "User input isn't sanitized on the search page." That's a potential SQL injection (CWE-89) — it's in the top three of the CWE Top 25, and it has 4 KEV CVEs behind it. That bug should jump to High priority immediately, even if no one has exploited it yet. Meanwhile, a UI glitch where a button is misaligned in Safari — that's Low priority, no matter how annoying it is. The CWE data gives you a defensible reason to say "this is urgent" or "this can wait."

Don't fall for the delayed issue effect — fix it when it's found

There's a persistent myth that fixing a bug later costs more than fixing it early. The largest study on the delayed issue effect — 171 software projects from 2006–2014 — found no evidence that issues resolved in a later phase cost consistently or substantially more effort than issues resolved soon after introduction (arXiv). That's a relief, because it means you don't have to drop everything to fix every bug the moment it's found. But it also means you can't justify procrastination by saying "it'll be cheaper later" — that's not true either. The study concludes that the delayed issue effect occurs intermittently, only in certain kinds of projects (arXiv). So the right approach is: triage each bug on its own merits, and don't let a false sense of urgency or false sense of cost dictate your priorities.

That said, for security vulnerabilities, there is a hard deadline: CISA's KEV catalog records a remediation due date for each entry (CISA). If you have a bug that's in the KEV catalog, you're not just fixing it because it's urgent; you're fixing it because a federal agency has told you to, and there's a deadline attached. That's about as concrete as triage gets.

Your triage should be a ritual, not an afterthought

So here's my recommendation, blunt and clear: Run a formal triage meeting, at least weekly, and use a decision matrix that combines severity, CVSS score, and KEV/CWE status to assign priority. Don't let engineers self-assign priority based on how interesting the bug is. Don't let product managers inflate priority because a customer complained. Triage is a team discipline, and it needs structure.

For each bug, answer three questions: (1) How severe is it — what's the user impact? (2) How urgent is it — is it in the KEV catalog, or does it map to a top CWE? (3) What's the cost of fixing it now vs. later? That last one is a judgment call, but the data from the delayed issue effect means you can be honest: sometimes it's fine to wait. But for anything in the KEV catalog, don't wait. CISA's Binding Operational Directive 22-01 (now superseded by BOD 26-04) once required federal agencies to remediate KEV vulnerabilities by specific due dates (CISA BOD 22-01) — that's the spirit you should adopt.

Sources

• Atlassian - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• Atlassian - https://www.atlassian.com/software/jira/guides/issues/priorities
• CISA - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD - https://nvd.nist.gov/general
• FIRST - https://www.first.org/cvss/v4.0/specification-document
• CWE - https://cwe.mitre.org/top25/archive/2024/2024_top25_list
• arXiv - https://arxiv.org/abs/1609.04886