Bug Triage Is a Lifecycle, Not a Triage Step: Debunking the Severity Myth

Here's a number that should make every team rethink its triage: software flaws cost the U.S. economy $59.5 billion annually, even though about 50 percent of development budgets go to testing (NIST). That was in 2002. We've gotten better at tracking bugs, but we still treat triage like a one-time sorting event, when it's actually a continuous lifecycle. Let's bust some myths.

Is severity the same as priority?

No. Severity measures how much a bug affects system functionality or user experience, while priority measures how urgent it is to fix (Atlassian). A cosmetic typo on the login page might be minor severity, but if it breaks a compliance requirement, it could be highest priority. And a crash in an obscure feature might be severe, but if no one uses it, priority can be low. The two are not interchangeable.

Should we triage based on severity alone?

Absolutely not. If you triage by severity alone, you'll fix the loudest crashes first, but you might ignore the quietly exploited vulnerability that's already in the wild. CISA maintains the Known Exploited Vulnerabilities (KEV) catalog as the authoritative source of vulnerabilities that have been exploited in the wild, and directs organizations to use it as an input to their vulnerability management prioritization framework (CISA). That's a clear signal: exploitability trumps severity when deciding what to fix first.

Isn't triage just a step at the start of the workflow?

No. A simple, effective bug workflow might be Open to In Progress to In Review to Done to Closed, optionally adding a Triage step (Atlassian). But that's just the beginning. A defect typically moves through New/Open, Assigned, In Progress, Fixed, Pending Retest, Retest, Verified, and Closed stages (Atlassian). Triage happens at every stage: when a bug is rejected, deferred, or reopened, you're re-triaging. And for security vulnerabilities, the NVD enriches every CVE with CVSS, CWE, and CPE data, and that data can change as new information emerges (NVD). So triage isn't a gate; it's a loop.

Do we really need a separate bug tracker?

If you're beyond a handful of developers, yes. Organizations adopt dedicated bug trackers such as Bugzilla when they outgrow built-in tracking in source-code management systems, typically for workflow management, bug-visibility (security) control, or custom fields (Bugzilla). Bugzilla was one of the first open-source trackers, released in 1998, and it's still used by Mozilla and hundreds or thousands of organizations (Bugzilla). The point is: you need a system that supports the full lifecycle, not just a place to dump issues.

Is the 'Cannot Reproduce' state a dead end?

It shouldn't be. Common alternative states include Rejected, Duplicate, Deferred, Reopened, Not a Bug, and Non-Reproducible (Atlassian). But 'Non-Reproducible' is often a cop-out. A complete defect report includes reproduction steps, expected vs actual behavior, severity and priority, environment details, and visual proof (Atlassian). If you can't reproduce, you probably didn't collect enough info. Triage should send it back for more details, not close it.

Should we treat accessibility bugs differently?

Yes, but not by ignoring them. Accessibility defects are validated against WCAG, which has success criteria at three conformance levels: A, AA, and AAA (W3C). WCAG 2.2, published October 5, 2023, is backwards compatible—content that conforms to 2.2 also conforms to 2.1 and 2.0 (W3C). So when triaging an accessibility bug, you need to know which version and level you're targeting. And because WCAG 2.2 is an ISO standard and EN 301 549 uses 2.1, you might have legal obligations. Triage should route these to the right expertise, not just to the nearest dev.

How do we measure if our triage is working?

Use defect rejection ratio (rejected defects divided by total reported) and defect leakage ratio (production defects divided by total found) (Atlassian). If your rejection ratio is high, you're accepting too many junk reports. If your leakage ratio is high, your triage is missing bugs that matter. These metrics give you a feedback loop. But don't game them—if you reject everything, you'll miss real bugs.

Is it worth investing in static analysis for triage?

For safety-critical code, yes. NASA JPL's Gerard Holzmann proposed 'The Power of 10: Rules for Developing Safety-Critical Code' in 2006, a small set of rules that can be automatically checked (NASA). Tools like CodeSonar, adapted with NASA SBIR funding, are used by hundreds of organizations worldwide (NASA). Static analysis can catch defects before they even enter the tracker, saving triage effort. But for most teams, it's a supplement, not a replacement.

What I'd actually do

Stop treating triage as a one-time severity sort. Instead, build a triage lifecycle: every bug enters with a priority that's based on exploitability and business impact, not just severity. Check the CISA KEV catalog when prioritizing security bugs—if it's listed, it gets top priority, period. For non-security bugs, use a simple matrix: severity x user impact x frequency. And don't let 'Cannot Reproduce' be a graveyard—send those back for more info, and track your rejection and leakage ratios to keep improving. Finally, invest in a dedicated tracker like Bugzilla or Jira, because a source-code management system can't handle the full lifecycle. That's how you turn triage from a step into a system.

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
• Bugzilla (official site) - https://www.bugzilla.org/about/
• CISA (Known Exploited Vulnerabilities Catalog) - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NASA (NTRS Spinoff 2011, Tools Ensure Reliability) - https://ntrs.nasa.gov/api/citations/20120001915/downloads/20120001915.pdf
• 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