Bug Triage: Treat Every Report Like It Could Crash the Therac-25

Imagine you're the lead developer at a mid-sized SaaS company. It's Monday morning, and your inbox has 47 new bug reports. One says the login page crashes when a user pastes a password with a trailing space. Another says the PDF export occasionally mangles a table. A third, buried at the bottom, says a specific API endpoint allows an attacker to read another user's private messages. You have a sprint to plan, a demo on Friday, and a manager who wants everything fixed yesterday. What do you do?

You triage. And you do it ruthlessly, because if you treat every report like an emergency, you'll fix nothing important. The good news is that triage isn't guesswork—it's a discipline with decades of hard-won lessons. The bad news is that most teams get it wrong by conflating severity with priority, ignoring the vulnerability catalogs that can save their bacon, and burying the one report that matters under a pile of noise.

Severity Is Not Priority, and Priority Is Not Severity

The first thing to internalize is the difference between severity and priority. Severity measures how much a bug affects system functionality or user experience—think "system crash" versus "typo on the About page." Priority measures how urgent it is to fix, which is a business decision that weighs severity against customer impact, release timing, and available resources (Atlassian). A crash in a rarely used admin panel might be severe but low priority. A cosmetic glitch on the main checkout page might be minor in severity but high priority.

So when you look at that login page crash, don't just ask "how bad is it?" Ask "what happens if I don't fix it today?" If the answer is "a few users get annoyed," it can wait. But if the answer is "we lose a major client," it jumps the queue. The trap is thinking that severity and priority are the same. They're not. And the teams that conflate them are the ones that end up with a backlog of half-fixed critical bugs and a pile of trivial issues that somehow became urgent.

Use the Vulnerability Catalogs as Your Triage Shortcut

For security bugs, you have an unfair advantage: the U.S. government has already done much of the triage for you. CISA maintains the Known Exploited Vulnerabilities (KEV) catalog, which is the authoritative source for vulnerabilities that have been actively exploited in the wild (CISA). If a bug you're triaging matches a CVE in that catalog, it's not a question of whether to fix it—it's a question of when, and the answer is "last week." CISA even directs organizations to use the KEV catalog as an input to their vulnerability management prioritization framework, and binding operational directives have required federal agencies to remediate those within strict timelines (CISA).

But don't stop at the KEV. The NVD enriches every CVE with CVSS scores, CWE types, and CPE applicability (NVD). A CVSS v4.0 score of 9.8 is a screaming alarm. A score of 3.1 is a whisper. The CVSS qualitative ratings map scores to bands: 9.0–10.0 is Critical, 7.0–8.9 is High, 4.0–6.9 is Medium, 0.1–3.9 is Low (FIRST). Use those bands to set your initial priority, then adjust for your specific context.

The Cost of Getting It Wrong: From Therac-25 to Mars

If you think triage is just about being efficient, consider the Therac-25. Between June 1985 and January 1987, six known accidents involving that radiation therapy machine caused massive overdoses, with resultant deaths and serious injuries—the worst series of radiation accidents in the 35-year history of medical accelerators (MIT). The root cause wasn't a single coding error; it was a cascade of software requirement errors, including the omission of safety interlocks that existed in the earlier Therac-20 (MIT). The Therac-20 had the same software error, but its hardware interlocks mitigated the consequences (MIT).

Now think about your triage process. If a bug report comes in that says "the system sometimes allows a patient to receive a double dose," would you prioritize it? Of course you would. But the Therac-25 lesson is that the most dangerous bugs are often not the ones in the code—they're the ones in the requirements, the ones that everyone assumed were handled by a safety mechanism that didn't exist. The investigation found that most computer-related accidents are not caused by coding errors but by errors in the software requirements, such as omissions and mishandled environmental conditions (MIT). So when you triage, ask: does this report point to a missing requirement, not just a broken implementation?

Your Triage Workflow: Open, Triage, Act, Verify

Here's the workflow I recommend, and it's simple: every bug enters the tracker as Open, then moves to a Triage state where you (or a designated triager) assign severity, priority, and an owner. Then it goes to In Progress, In Review, Done, and Closed (Atlassian). The key is to have a triage step that is not optional. In that step, you do three things: reproduce the bug, classify it, and decide its fate.

Reproduction is non-negotiable. If you can't reproduce it, you can't fix it, and you risk wasting a developer's time on a ghost. The Atlassian bug life cycle includes "Rejected" and "Not a Bug" states for a reason—use them. If a bug is a duplicate, mark it as Duplicate and move on. If it's real but not worth fixing now, set it to Deferred. The goal is to keep the active backlog small and focused.

When you classify, use priority levels that range from Lowest/Trivial to Highest/Blocker (Atlassian). Severity levels commonly include Fatal/Blocker, Critical, Major, and Minor/Trivial (Atlassian). Don't let every bug be a "High" or "Critical"—that dilutes the meaning. And don't let a bug with severity "Minor" slide into oblivion either. That's how you end up with a backlog of 2,000 issues that no one ever looks at.

For security bugs, I recommend a separate triage path. If a report mentions a CVE, a CWE, or an OWASP category, route it to someone with security expertise. The OWASP Top 10 2021 lists Broken Access Control as the top web application security risk, with over 318,000 occurrences in the contributed dataset (OWASP). If your bug is a broken access control issue, it's not a minor annoyance—it's a top-ranked weakness. CWE-79, Cross-site Scripting, was the #1 weakness in the 2024 CWE Top 25, with a score of 56.92 (CWE). If you see that in a report, treat it seriously.

What to Do With the Rest: The Delayed Issue Effect

Now, about those 47 reports. The truth is, not all of them need to be fixed today, and some may never need to be fixed at all. But here's the thing: the conventional wisdom that "the longer you wait, the more it costs to fix" is not always true. A large study of 171 software projects from 2006 to 2014 found no evidence that issues resolved in a later phase cost consistently more effort than issues resolved soon after introduction (Menzies et al.). The delayed issue effect appears intermittently, not as a global truism. So you don't need to panic about that minor UI glitch you're deferring.

But don't use that as an excuse to ignore everything. The same study found that the effect is project-dependent, so you need to measure your own data. If your team consistently spends three times longer fixing bugs that were reported six months ago, then your triage process needs to change. If not, you can safely defer.

Your triage should also consider the cost of not fixing. The 2002 RTI study for NIST estimated the annual cost of inadequate software testing infrastructure at $22.2 to $59.5 billion, with over half borne by users in error avoidance and mitigation (NIST). That's the cost of bugs that escape to production. Your triage is your first line of defense.

Don't Forget Accessibility and the Human Factor

One more thing: accessibility bugs are not optional. If you're triaging web application bugs, remember that WCAG success criteria are defined at three conformance levels: A, AA, and AAA (W3C). A bug that prevents a screen reader user from completing a purchase is a severity "Critical" in user experience, even if the page renders fine visually. Track accessibility bugs against a specific WCAG version—2.2 is the latest, published in October 2023 (W3C). And don't treat accessibility as a separate silo.

Finally, remember that triage is a human process. The Mars Pathfinder experienced repeated system resets due to a priority inversion problem in its real-time software (Chalmers). The team patched it remotely within a few days, but the lesson is that bugs can be subtle and systemic. Your triage should encourage engineers to dig into root causes, not just slap a band-aid on the symptom. The Therac-25 investigation recommended that software audit trails be designed in from the beginning, and that software be subjected to extensive testing at the module and software level—system testing alone is not adequate (MIT).

The One Thing to Remember

When you're staring at a fresh pile of bug reports, the most important thing is to triage with intent: separate severity from priority, lean on the vulnerability catalogs for security bugs, and always ask what happens if you don't fix it now. Fix the ones that could kill your product—or your users—first, and let the rest wait. Your backlog 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
• CISA – Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD – National Vulnerability Database: https://nvd.nist.gov/general
• FIRST – CVSS v4.0 Specification: https://www.first.org/cvss/v4.0/specification-document
• MIT – Therac-25 Accidents Part V: https://web.mit.edu/6.033/2004/wwwdocs/papers/Therac_5.html
• Menzies et al. – Delayed Issue Effect: https://arxiv.org/abs/1609.04886
• NIST – Economic Impacts of Inadequate Infrastructure for Software Testing: https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf