Triage Bugs by Exploit, Not Severity: A Practical Walkthrough

Who This Is For and the Misconception We're Killing

If you're a developer or a team lead whose bug triage meeting still starts with someone saying, "This one's a Critical severity, so it goes first," this article is for you. That's the misconception: severity is not the same as priority, and using severity as your triage compass is how you end up fixing a rare cosmetic glitch while an actively exploited hole burns your production server. Atlassian's own guidance separates the two terms: priority measures urgency, severity measures impact (Atlassian, issue priority vs severity). They're related but not interchangeable. In this walkthrough, I'll show you a practical, exploit-first triage process that we've used on real teams to stop chasing phantom bugs and start fixing what matters.

Step 1: Separate the Wheat from the Chaff with the KEV Catalog

Before any bug gets a priority number, check it against CISA's Known Exploited Vulnerabilities catalog. This is the authoritative list of vulnerabilities that have actually been weaponized in the wild (CISA). If your bug is a known exploited vulnerability, it doesn't matter if it's a "Minor" in severity—it gets the highest priority, period. The KEV catalog even gives you a remediation due date, which is your deadline, not a suggestion. We've had bugs that looked like a 3 out of 10 on impact but were on the KEV list, and we fixed them before the due date because the alternative was being the next breach headline. For everything else, move to step two.

Step 2: Let CVSS Score the Impact, Not Your Gut

Once you've pulled out the KEV items, look at the CVSS base score for any security-related bug. The National Vulnerability Database enriches each CVE with CVSS impact metrics, a CWE type, and CPE applicability statements (NVD). That score is your severity, but it's still not your priority. Severity is about how bad it could be; priority is about how urgent it is to fix, given your context. A CVSS 9.0 in a rarely used internal tool might be lower priority than a CVSS 6.5 that's internet-facing and has a known exploit. So don't sort by CVSS alone—use it to inform priority, not dictate it.

Step 3: Set Priority with a Simple Matrix

Here's the concrete method: after you've determined exploit status and CVSS, set priority on a scale from Lowest to Blocker (Atlassian, issue priority vs severity). Our rule of thumb: any KEV-listed bug is Blocker. Any bug with a CVSS of 9.0 or higher that's remotely exploitable is at least High. But here's the twist—we also factor in the remediation due date from the KEV catalog. If CISA says fix by next Tuesday, that's a Blocker even if your internal severity assessment said "Medium." For non-security bugs, severity still matters, but we weigh it against the user impact and the likelihood of occurrence. A crash that happens once a month in an admin panel might be Major severity but Low priority, because it's not blocking anyone's work. A login button that's misaligned on mobile might be Minor severity but High priority if it's on your main conversion path.

Step 4: Run the Triage Meeting Like a Surgeon, Not a Committee

Now you've got your candidates. In the triage meeting, we don't debate severity scores—that's a black hole. We walk through each bug in priority order, and the only question we ask is: "Is this the right priority, and who's assigned?" If a bug is a Duplicate, Rejected, or Not a Bug, we bounce it right there (Atlassian, bug life cycle). We use a simple workflow: Open, In Progress, In Review, Done, Closed, with a Triage step at the front (Atlassian, issue priority vs severity). We assign bugs to the appropriate developer, and when they're fixed, we reassign to the original tester for verification (Atlassian, bug life cycle). If validation finds new defects, we log them as separate issues—never as comments on the old one.

What Can Go Wrong: The Triage Trap

Here's the warning: the biggest failure we've seen is teams that treat triage as a one-time event. They do this process once, set priorities, and then never revisit them until the next sprint planning. But vulnerabilities are living data. The NVD re-assesses CVEs as new information comes in, updating CVSS scores and CWE types (NVD). A bug that was a 5.0 last month could become a 9.8 after a new exploit is published. If you don't re-triage regularly, you'll be flying blind. Set a weekly 15-minute triage review, and check the KEV catalog for new entries that match your stack. That's not overkill—it's survival.

The Single Most Important Thing

Remember this: priority is not severity. Triage by what's being exploited, not by how bad it could theoretically be. Use the KEV catalog as your north star, let CVSS inform your severity, and let your business context set the priority. Your triage meeting will be shorter, your fixes will be more relevant, and your users will thank you.

Sources

• Atlassian - https://www.atlassian.com/software/jira/guides/issues/priorities
• Atlassian - https://www.atlassian.com/software/jira/guides/bug-tracking/bug-life-cycle
• CISA - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• NVD - https://nvd.nist.gov/general