Bug Triage Isn't About Severity: Prioritize by Exploit, Not Impact

“Severity determines priority, right?” — No, and that’s the biggest myth in bug triage.

I’ll say it plainly: if you’re setting priority based on how badly a bug wrecks your system, you’re triaging wrong. Severity tells you the damage a bug could do; priority tells you how urgently you must act. Those are different questions. A crash in an obscure admin tool might be “fatal” in severity, but if no one uses that tool and it’s not exploitable, it’s not urgent. Meanwhile, a low-severity information leak that’s actively being exploited in the wild demands your immediate attention. The security world figured this out years ago—it’s time bug triage caught up.

“What’s the difference between priority and severity, anyway?”

Priority measures how urgent a bug is to fix, while severity measures how much it affects system functionality or user experience (Atlassian, issue priority vs severity). Think of severity as the intrinsic impact—a system crash is severe. Priority is your business decision: what order do you fix things? A bug can be severe but low priority if it’s in a rarely used feature. Conversely, a moderate bug can be high priority if it’s blocking a major release or being exploited. The two are related but not interchangeable. Too many teams conflate them, and that’s how you end up fixing a cosmetic glitch while a data leak festers.

“How do I decide what’s actually urgent?”

Start with exploitation. CISA maintains the Known Exploited Vulnerabilities (KEV) catalog as the authoritative source of vulnerabilities that have been exploited in the wild—use it as your first filter (CISA, KEV catalog). If a bug maps to a CVE in that catalog, it’s automatically top priority. Then layer on your own context: what’s mission-critical? What’s user-facing? What’s in the critical path of your product? For example, a bug that lets an attacker read any user’s data is high priority even if it doesn’t crash the system. A bug that only corrupts a rarely used export function is lower priority, even if it’s a “major” severity.

“Should I use CVSS scores to set priority?”

CVSS scores are a starting point, not the final word. The NVD enriches every CVE with CVSS impact metrics, a CWE type, and CPE applicability (NVD, general). But CVSS measures severity, not exploitability in your environment. A 9.0 score sounds scary, but if that component isn’t in your product, it’s irrelevant. And a 5.0 might be actively exploited in your niche. Don’t let a number decide for you—use it as input, then apply your judgment. The KEV catalog is a better urgency signal because it reflects real-world attacks.

“What about bugs that aren’t security vulnerabilities?”

Non-security bugs still need triage, but the same principle applies: impact versus urgency. A defect that crashes the app on every launch is both severe and urgent—fix it now. A typo in an error message is severe? No, it’s minor. But if that typo misleads users into a dangerous action, its impact rises. Use your product knowledge. Also remember the classic lifecycle: a bug moves from New/Open through Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, and Closed (Atlassian, bug life cycle). Triage happens at the front end, but you should re-triage as new information emerges. A bug that was low priority yesterday might be exploited today—reassess.

“How do I handle ‘cannot reproduce’ or ‘not a bug’?”

These are common exceptions, but they’re often triage failures in disguise. If you can’t reproduce a bug, you haven’t gathered enough information. A complete defect report includes reproduction steps, expected vs actual behavior, severity and priority, environment details, and visual proof (Atlassian, bug life cycle). Without that, you’re guessing. Don’t close a bug as “Not a Bug” just because you can’t reproduce it—escalate it to the reporter with a request for more details. And if you do reject it, log it as Rejected or Duplicate, but keep the record for traceability. The impact of dismissing a real bug can be mission-ending: NASA’s Mars Global Surveyor operated successfully for more than 9 years before the mission ended because a software update written months earlier was stored at the wrong memory address (NASA, Spinoff 2011). That bug was likely unreproducible at first, but it was real.

“Quick tip: set a reminder to re-triage weekly.”

Bug triage isn’t a one-time event. Set aside 30 minutes each week to review your open bugs, check the KEV catalog for new entries, and adjust priorities based on changing circumstances. Your team’s time is precious—spend it on what matters now.

“What’s the single most important thing to remember?”

Priority is not severity. Priority is urgency, and urgency is driven by exploitability and business impact, not by how badly a bug breaks your system. Stop letting severity dictate your triage. Use the KEV catalog, use your judgment, and reassess constantly. That’s how you fix the bugs that actually hurt you.

Sources

• Atlassian (issue priority vs severity) - https://www.atlassian.com/software/jira/guides/issues/priorities
• Atlassian (bug life cycle) - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• CISA (Known Exploited Vulnerabilities Catalog) - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD (National Vulnerability Database) - https://nvd.nist.gov/general
• NASA (NTRS Spinoff 2011, Tools Ensure Reliability) - https://ntrs.nasa.gov/api/citations/20120001915/downloads/20120001915.pdf