Stop Treating Every Bug Like an Emergency: A Triage Field Guide

Here's a number that should change how you run your bug tracker: in the 2024 CWE Top 25, the weakness ranked #1 — cross-site scripting — was linked to only 3 CVEs in CISA's Known Exploited Vulnerabilities catalog, while the #2 weakness, out-of-bounds write, was tied to 18 actively exploited CVEs (CWE/MITRE). That gap is your entire job in a nutshell. Triage isn't about counting bugs; it's about figuring out which ones are actually coming for you.

This guide is for the person who owns the backlog — the lead dev, the QA manager, the one-person shop wearing every hat. You already know what a bug is. What you need is a system for deciding what to do with each one before it drowns you. I'm going to walk you through a practical, opinionated triage process that treats every bug report as a suspect, not a verdict.

1. Start With the Three Questions

Before you touch a single bug, ask three questions. First: Is it real? Second: Is it reachable? Third: What breaks if you ignore it? The first question separates a reproducible defect from a one-off glitch or a user error. The second forces you to think about whether an attacker or a normal user can actually trigger it. The third is where severity and priority start to separate. A bug that crashes a demo but sits behind an admin-only page is very different from one that any visitor can hit on your login form. Get comfortable saying "not a bug" or "can't reproduce" early — you'll need that muscle.

2. Severity Is About the Wound, Priority Is About the Clock

Don't let the words blur. Severity measures how badly the bug hurts the system or the user experience — crash, data loss, wrong output. Priority measures how urgent it is to fix, which is a business call. (Atlassian makes this same distinction.) A cosmetic typo on your homepage might be high priority if that page is your sales pitch, even though its severity is trivial. A crash in a rarely used admin report might be severe but low priority if nobody's clicking it this week. Write both in the report, and don't let a tester's anxiety inflate severity just to get attention.

3. Use the CVSS as a Starting Line, Not a Finish Line

For security bugs, you've got a cheat sheet: the CVSS score. The National Vulnerability Database (NVD) enriches every CVE with CVSS impact metrics, a CWE type, and platform applicability statements — so you're not starting from zero. But here's the trap: a raw CVSS score of 9.0 (Critical) can be misleading if the vulnerable component isn't exposed or if a workaround already exists. FIRST's CVSS v4.0 splits scores across Base, Threat, Environmental, and Supplemental groups precisely because context matters. So use the score to sort, then override it with your own environmental and threat data. That's not cheating; that's triage.

4. Check the KEV Catalog Before You Argue About Priority

Here's a blunt rule: if a bug is in CISA's Known Exploited Vulnerabilities catalog, it's a top priority. Period. That catalog is the authoritative list of vulnerabilities that are actually being exploited in the wild, and it even includes remediation due dates and whether ransomware gangs are using it (CISA). You can spend hours debating severity scores, but if the bug is being actively weaponized, the debate is over. For everything else, you've got room to breathe. And don't forget that BOD 22-01 may have been revoked, but its successor, BOD 26-04, keeps the same spirit — federal agencies have to fix KEV bugs on a deadline, and you should adopt that discipline voluntarily.

5. Move Bugs Through a Simple Workflow — With a Triage Step

Your workflow doesn't need to be elaborate. Atlassian suggests a simple chain: Open to In Progress to In Review to Done, optionally adding a Triage step. That's enough. The triage step is where you decide whether a bug is even worth the next click. If it's a duplicate, reject it. If it's deferred, say why and when it'll be revisited. If it's not reproducible, ask for more info and set a timer — if the reporter goes silent for two weeks, close it. And when you do fix something, assign it back to the original tester for verification, not to a random QA person. That's basic accountability, and it cuts down on "works for me" ping-pong.

6. What Can Go Wrong: The False Urgency Trap

Let me warn you about the most common failure mode. A developer reports a bug in a module they own, and because they're embarrassed or overworked, they mark it High severity and Blocker priority. You rubber-stamp it, and suddenly the sprint is blown because you're fixing a bug that affects a feature nobody uses. I've seen it happen a hundred times. The fix is to force every high-severity report to include reproduction steps, expected vs. actual behavior, and environment details — if they can't write that down, it's not ready for triage. (Atlassian's guidance on complete defect reports is exactly this.) And don't be afraid to downgrade. Your job is to protect the roadmap, not to validate someone's panic.

Remember This

If you take one thing from this guide: triage is a decision-making discipline, not a sorting exercise. The goal is to spend your finite engineering hours on bugs that matter — and to let the rest wait without guilt. When in doubt, ask yourself: would this bug be in the KEV catalog if it were a security issue? If yes, fix it now. If no, it can probably wait until tomorrow.

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
• CWE (Top 25 2024 ranked list, MITRE) - https://cwe.mitre.org/top25/archive/2024/2024_top25_list