Stop Triage Theater: Fix Bugs by What's Exploited, Not by Severity

"Why do we keep fixing the wrong bugs?" That's the question I hear from teams drowning in defect backlogs. They've got Jira boards full of tickets, a triage meeting that runs long, and yet the bugs that actually bite users—or worse, get exploited in the wild—slip through. The answer isn't a better triage scorecard. It's a fundamental reordering of what you fix first.

Here's my thesis, and I'll defend it with facts: Your bug workflow should prioritize by real-world exploitation, not by your team's subjective severity rating. Severity feels objective—it's a crash, it's a data loss—but it's a guess about impact. Exploitation is a fact: someone is actively using that bug to break into systems. The fix is to weave that fact into your workflow, starting with a simple triage step that checks a federal catalog. Let me show you why this works and why your current system is failing you.

Severity Is a Guess, Priority Is a Choice—But Both Are Wrong

Every bug tracker teaches you the same dance: you log a defect, assign it a severity (how bad it is) and a priority (how urgent it is). Atlassian, the folks behind Jira, define priority as urgency and severity as impact (Atlassian). That sounds clean, but in practice, severity is assigned by whoever files the ticket—often a tester who's seen the bug once, on one machine, under one scenario. They slap a "Critical" on a UI glitch that happens only on a 2004 browser, while a silent data-corruption bug gets a "Major" because it didn't crash anything. Priority then becomes a bureaucratic tug-of-war between product managers and developers, each arguing for their pet feature.

And here's the kicker: severity levels are just a ladder—Fatal/Blocker, Critical, Major, Minor (Atlassian). They're static labels, not dynamic signals. A bug that's "Minor" today can become "Critical" tomorrow if a botnet starts exploiting it. Your workflow needs to react to that, not wait for a quarterly review.

The Government Already Gives You a Priority List—Use It

Here's the fact that should change your workflow: the Cybersecurity and Infrastructure Security Agency (CISA) maintains the Known Exploited Vulnerabilities (KEV) catalog, which is the authoritative source for vulnerabilities that have been actively exploited in the wild (CISA). It's not a theoretical list of CVEs with high CVSS scores—it's a list of bugs that are being used right now, with remediation due dates and whether they're tied to ransomware campaigns. And CISA explicitly directs organizations to use this catalog as an input to their vulnerability management prioritization framework (CISA).

Now, let's be concrete. Say you're a SaaS company with a web app. You have two bugs in your backlog: Bug A is a buffer overflow in your file-upload module that could crash the server (severity: Critical). Bug B is a cross-site scripting (XSS) flaw in a comment field (severity: Medium). Your team, following classic severity-based triage, would fix Bug A first. But if Bug B appears in the KEV catalog—because attackers are using it to steal session cookies—then your priority should flip. CISA's whole point is that exploited bugs are the ones that matter, regardless of their CVSS score. The KEV catalog even lists a remediation due date (CISA), so you have a hard deadline. That's not a suggestion; it's a directive, especially if you're a federal contractor.

What About the "We Don't Have Security Bugs" Excuse?

I can hear the counter-argument: "We're a small team, we don't deal with security vulnerabilities, we just fix functional bugs." Nice try. Every bug is potentially a security bug. The NVD—the U.S. government's vulnerability database—doesn't test for vulnerabilities itself; it relies on vendors and researchers to report them (NVD). That means if you don't report your bug, it might never get a CVE. But that doesn't mean it's not exploitable. The Mars Global Surveyor, a NASA spacecraft, was lost after nine successful years because a software update was stored at the wrong memory address (NASA). That wasn't a security bug—it was a memory error. And it killed a mission. If you're building anything that matters, you can't afford to ignore the exploitation angle.

Another pushback: "But severity is what our QA team understands." Fine. Keep severity as a field—it's useful for describing impact. But make it secondary to a new field: "Exploited?" Check the KEV catalog during triage. If the bug is there, it's a Blocker, period. If it's not, then you can argue over priority. This doesn't require a security team—it's a simple lookup. CISA's catalog is free and searchable.

How to Rework Your Workflow (Without Overhauling Your Tools)

You don't need to switch from Jira to Bugzilla to make this work. Bugzilla was originally written in 1998 to replace Netscape's in-house system (Bugzilla), and it's still used by thousands of organizations, but the workflow principles apply to any tracker. Atlassian suggests a simple workflow: Open → In Progress → In Review → Done → Closed, with an optional Triage step (Atlassian). That Triage step is where you need to add the exploitation check. Here's my recommended flow:

When a bug comes in, the triage team does three things: (1) confirm it's a real defect (not a duplicate or "not a bug"—common states per Atlassian), (2) assign a severity and priority, and (3) search the KEV catalog and NVD for that bug or its CVE. If it's in the KEV catalog, the priority is automatically Highest/Blocker, and the remediation due date is your deadline. If it's not, you proceed with your normal severity-based prioritization. That's it.

And when you fix it, don't just close the ticket. The NVD data is living—CVSS scores and CWE types change as new information comes in (NVD). So after you fix an exploited bug, verify the fix, and then re-check the catalog to see if the vulnerability's status has changed. This ties into the broader best practice of linking bugs to user stories, test cases, and code changes for traceability (Atlassian).

But What About Bugs That Aren't Security-Related?

You might think this only applies to security bugs. But the principle extends to any bug that's causing real-world harm. The KEV catalog is just the most extreme example. For functional bugs, you can apply a similar logic: is this bug causing a known failure that's affecting users? For instance, a bug that prevents a screen reader from reading a form field is an accessibility defect—and that's not just a "nice to have." The W3C's Web Content Accessibility Guidelines (WCAG) have specific success criteria at levels A, AA, and AAA (W3C), and if you're building for the public sector, you might be required to meet WCAG 2.1 or 2.2 (W3C). So if a bug violates a WCAG criterion, that's a legal risk, not just a UX nit. Treat it with the same urgency as an exploited vulnerability.

Let me give you a real-world scenario: a hospital infusion pump manufacturer. The FDA has encouraged them to use static analysis tools like CodeSonar to check their software (NASA). CodeSonar, which was adapted with NASA JPL funding, can find defects without executing the code (NASA). If a static analysis flags a potential buffer overflow, that could be a safety issue. But is it exploited in the wild? Probably not. So it might be a high severity, but not a KEV priority. That's fine—you fix it based on risk, but you don't let it crowd out a bug that's actively being exploited in your production environment.

Here's the bottom line: your bug workflow is a life-or-death system, not a bureaucratic formality. The next time you're in a triage meeting and someone says "this is Critical because it crashes," ask them: "Is it in the KEV catalog?" If not, maybe it can wait. If yes, drop everything. That's the fix.

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
• W3C - https://www.w3.org/WAI/standards-guidelines/wcag/
• NASA - https://ntrs.nasa.gov/api/citations/20120001915/downloads/20120001915.pdf