Bug Triage: Why We Stopped Chasing Blockers and Started Watching the KEV Clock

Here's a claim that will annoy a lot of engineering managers: your triage process is probably optimized for the wrong clock. Most teams sort bugs by severity, then priority, then argue about whether a crash is a P1 or a P2. That's fine for consumer apps. But if you ship anything that touches money, health, or infrastructure, the only clock that matters is the one CISA is already running for you. We learned this the hard way after watching a 'minor' dependency bump sit in a backlog for six weeks while a known exploited vulnerability in the same library was being used in ransomware campaigns. The fix took twenty minutes. The triage debate took longer than the fix.

So we changed how we decide. Instead of asking 'how bad is this bug,' we ask 'which clock is this bug on.' That reframing changes which tool you should use, and it changes what you put in the first column of your board.

The three options we actually compared

We looked at the three trackers that show up in almost every team we talk to: Jira, Bugzilla, and GitHub Issues. (Atlassian lists these alongside Azure DevOps and Marker.io as common defect trackers, but those three are the ones we see in practice.) Each one encodes a different theory of triage. Jira assumes you have a process and want to configure it. Bugzilla assumes you have a lot of bugs and want speed. GitHub Issues assumes your bugs live next to your code and you don't want a second tool.

Here's how they stack up on the four criteria that actually decide triage outcomes.

The table makes the trade-off obvious. Jira gives you the most structure for triage, Bugzilla gives you the most history, and GitHub Issues gives you the least friction. None of them is 'best' in the abstract.

Who each one is actually for

Jira is for teams that ship risk, not just code. If you have a compliance obligation, a safety case, or a customer contract with a remediation SLA, you need the full lifecycle. You need the difference between 'Fixed' and 'Verified' to be auditable. You need to be able to show that a bug was reassigned to the original tester after a fix, and that any new defect found during validation was logged as a separate issue (Atlassian's bug life cycle guidance). That's not bureaucracy for its own sake; it's the difference between a triage meeting and a deposition.

Bugzilla is for teams drowning in reports. It was written in 1998 for mozilla.org to replace Netscape's in-house system, and its design principles still read like a triage manifesto: run on freely available open-source tools, keep speed and efficiency a top priority, use ANSI SQL, stay browser-agnostic (Bugzilla official site). If your triage problem is volume — thousands of incoming reports, a community of reporters, a need to reject duplicates fast — Bugzilla's age is a feature, not a bug. It was built for exactly that.

GitHub Issues is for teams where the bug and the fix live in the same repo. The killer feature isn't the tracker; it's that the issue is one click from the commit. If your triage outcome is usually 'assign to the person who wrote this file last,' GitHub Issues wins on pure speed. You will pay for it later in reporting and in any audit that asks 'show me every bug that touched this subsystem.'

So which one wins? For most of the teams we work with, Jira wins — but only if you actually use the lifecycle. The failure mode we see is a team buys Jira, configures five statuses, and then runs triage exactly like they did in GitHub Issues. That's the worst of both worlds: the cost of Jira with the traceability of a sticky note.

The one change that matters more than the tool

Whichever tracker you pick, add a single field to your triage board: 'clock.' Not priority. Not severity. Clock. There are only three values: KEV, CVSS, and normal.

• KEV means the vulnerability is in CISA's Known Exploited Vulnerabilities catalog, which records a remediation due date, the related CWE type, and whether it's known to be used in ransomware (CISA KEV catalog). These bugs skip the queue. They are not triaged; they are scheduled.
• CVSS means you have a scored vulnerability but no evidence of exploitation. Score it with CVSS v4.0, which maps numeric scores to None (0.0), Low (0.1–3.9), Medium (4.0–6.9), High (7.0–8.9), and Critical (9.0–10.0) (FIRST CVSS v4.0). Then triage by score, not by who shouted loudest.
• Normal is everything else — crashes, UI bugs, accessibility defects. These get the classic priority-versus-severity treatment: priority is how urgent it is to fix, severity is how much it affects functionality or user experience (Atlassian).

We made this change after a concrete incident. A library we depended on had a CVSS 9.8 issue that we triaged as 'High priority, next sprint.' Two weeks later the same CVE appeared in CISA's KEV catalog with a due date. Suddenly the bug had a deadline we didn't set. The fix was a version bump. The lesson was that our triage had been ranking bugs by our own urgency, not by the adversary's.

There's a second reason to separate the clocks: the delayed issue effect isn't a law. The largest study on it — 171 projects from 2006 to 2014 — found no evidence that issues resolved later cost consistently or substantially more effort (Menzies et al. 2016). So 'fix it now because it gets more expensive later' is not a universal argument. But 'fix it now because CISA says it's being exploited' is. One is a heuristic; the other is a clock.

If you're on GitHub Issues and you can't stomach Jira, you can still do this. Add three labels: clock:kev, clock:cvss, clock:normal. Sort by label first, severity second. It's ugly, but it works, and it takes an afternoon.

The single most important thing to remember

Bug triage is not a ranking problem; it's a scheduling problem. The tool you pick matters far less than whether you have a clock that isn't yours. Put KEV and CVSS on the board, give them their own lane, and let the rest of your backlog argue about P1 versus P2 the way it always has. The teams that get burned aren't the ones with the wrong tracker. They're the ones with only one clock.

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
• FIRST (CVSS v4.0 specification) - https://www.first.org/cvss/v4.0/specification-document
• arXiv (Menzies et al. 2016, delayed issue effect) - https://arxiv.org/abs/1609.04886