Triage Like a Pilot: Why Severity Beats Priority in Bug Tracking

One Number That Should Change Your Triage

Software flaws cost the U.S. economy $59.5 billion annually, according to a 2002 NIST study. That's a number that should haunt every triage meeting. It means that every bug you triage is a line item in a national bill. But the real kicker is that the study also found about 50 percent of software development budgets go to testing. So we're spending a fortune on testing, yet bugs still cost billions. The problem isn't testing; it's that we triage poorly. We let urgency trump impact.

Imagine You're a Triage Lead

You're a triage lead at a mid-sized SaaS company. Your team uses Jira, and your backlog is a mess: 300 open tickets, everything from a typo in a tooltip to a rare race condition that might cause a crash. You're the one who decides what gets fixed next. If you're like most teams, you're sorting by priority: high, medium, low. But here's the trap: priority is about urgency, not impact. The Atlassian guide is clear: priority measures how urgent a bug is to fix, while severity measures how much it affects system functionality or user experience. If you triage by priority alone, you'll fix the loudest bug, not the most damaging one.

Severity First: The Only Way to Fly

My recommendation: triage by severity first, then priority. Severity levels commonly include Fatal/Blocker (system crash), Critical, Major, and Minor/Trivial (Atlassian). A fatal bug that crashes the app for a few users on an ancient browser might be high severity but low priority because it affects 0.1% of your users. Meanwhile, a minor bug that makes your checkout button lag by 200ms might be low severity but high priority because it affects every customer. The trick is to weigh both, but severity should anchor your decision. If it can crash the system, it goes to the top of the queue, even if only one person hits it. Because that one person might be a whale customer, and that crash might be mission-ending.

Think about NASA's Mars Global Surveyor: a software update stored at the wrong memory address ended a mission that had operated successfully for more than 9 years (NASA). That's a severity level you can't ignore. Your bug might not be on Mars, but a crash in your payment service could cost you a contract. So when you triage, ask: What's the worst case if this stays? If it's a crash, it's a blocker, period.

Security Bugs: The KEV Catalog Is Your Triage Shortcut

Security bugs deserve a separate lane. The NVD enriches every CVE with CVSS impact metrics, CWE type, and CPE applicability statements (NVD). But you can't triage every CVE. That's where CISA's Known Exploited Vulnerabilities (KEV) catalog comes in. CISA maintains it as the authoritative source of vulnerabilities that have been exploited in the wild, and directs organizations to use it as input to vulnerability management prioritization (CISA). If a bug is in the KEV catalog, it's not a maybe; it's a fix-now. The catalog even records a remediation due date and whether the vulnerability is known to be used in ransomware campaigns (CISA). That's your triage cheat sheet. If a bug is on that list, it jumps to the top, regardless of severity score. Because it's not theoretical; it's already being exploited.

But here's a nuance: the NVD doesn't test vulnerabilities itself; it relies on vendors and researchers to provide information (NVD). So a CVE might have an incomplete CVSS score. Don't wait for the perfect score. If it's in KEV, fix it. If it's not, but it's a critical-severity CVE with a known exploit, treat it like a blocker. And remember, the NVD re-assesses CVEs as new info comes in, so revisit your triage decisions.

Build a Simple, Effective Workflow

Your workflow shouldn't be a maze. Atlassian suggests a simple one: Open, In Progress, In Review, Done, Closed, with an optional Triage step. That's enough. If you outgrow that, you can adopt a dedicated tracker like Bugzilla, but don't go overboard. The bug life cycle typically moves through New/Open, Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, and Closed (Atlassian). But you can collapse that to fit your team. The key is to have a triage step where you assign severity and priority, and then let the workflow run. Don't let bugs sit in limbo. If a bug is non-reproducible, mark it as such and move on. Don't let it clog your queue.

Traceability: Link Everything

When you triage, you need context. Atlassian recommends maintaining traceability by linking bugs to user stories, test cases, and code changes. That's not just for compliance; it's for triage. If you see a bug linked to a high-value feature, you know its severity matters more. If it's linked to a test case, you can see if it's a regression. And when you fix it, link the code change so you can track it. This is especially important for accessibility bugs. WCAG has 13 guidelines under four principles, and they're versioned (W3C). If you're tracking accessibility defects, you need to know which version you're testing against: WCAG 2.0, 2.1, or 2.2. That's a metadata field in your triage. Don't let an accessibility bug languish because it's 'minor'—if it violates a WCAG A criterion, it's a legal risk.

Static Analysis: Your Triage Assistant

Finally, use static analysis to catch bugs before they hit your triage queue. NASA adapted CodeSonar, a static analysis tool, to check compliance with JPL's 'Power of 10' rules for safety-critical code (NASA). You don't need to be building spacecraft, but running a static analyzer on every commit can catch a class of bugs that never reach triage. The Power of 10 rules are a small set that are easy to remember and allow automated checking (NASA). That's a triage win: fewer bugs to triage. And for accessibility, you can use automated tools, but you'll still need manual checks. The point is, triage isn't just about sorting; it's about reducing the number of bugs that need sorting.

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
• NIST (2010 combination testing news release) - https://www.nist.gov/news-events/news/2010/11/updated-nist-software-uses-combination-testing-catch-bugs-fast-and-easy
• 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
• W3C WAI (WCAG 2 Overview) - https://www.w3.org/WAI/standards-guidelines/wcag/

Takeaway: Triage is not about picking the loudest bug; it's about picking the bug that hurts the most. Let severity anchor your decisions, use the KEV catalog as a shortcut for security, keep your workflow simple, link everything for traceability, and use static analysis to shrink the pile. If you do that, you'll spend less time arguing about priorities and more time fixing what matters—and maybe you'll help chip away at that $59.5 billion.