Triage Bugs Like a Security Engineer: Prioritize by Exploit, Not Severity

Imagine you're the bug triage lead on a Tuesday morning. Your queue has 47 new defects. One is a cosmetic misalignment in a settings page. Another is a crash in the payment flow. A third mentions a strange string in the URL that makes the server return a 500. Your developers can only fix five today. What do you do?

Most teams I've seen sort by severity: crash first, typo last. That's a mistake. Severity tells you how bad a bug is, not how urgent it is. Priority should be your only triage number. And the best way to set priority isn't by guessing—it's by borrowing a playbook from security engineers who track known exploits. This is a practical how-to for anyone who owns a bug queue, whether you're a QA lead, a product manager, or a developer who got stuck with the triage role. I'll walk you through a five-step triage routine that separates must-fix-now from can-wait-forever.

1. Start with the KEV catalog, not your gut

Before you touch your bug queue, check CISA's Known Exploited Vulnerabilities (KEV) catalog. It's the authoritative list of vulnerabilities that have actually been exploited in the wild. Each entry includes a remediation due date, the related Common Weakness Enumeration (CWE) type, and whether it's been used in ransomware campaigns (CISA). If your bug matches a KEV entry, that's your highest priority. No debate.

Why? Because an exploited vulnerability is a live fire. The NVD—the U.S. government's vulnerability database—tells us that security vulnerabilities follow a separate tracking lifecycle, and they enrich every CVE with CVSS scores, CWE types, and CPE applicability statements (NVD). But those scores are static. KEV tells you what's happening in the wild right now. So your first triage rule: if it's in KEV, fix it yesterday.

2. Separate severity from priority—then ignore severity

Severity measures how much a bug affects functionality or user experience. Priority measures how urgent it is to fix (Atlassian). They're different, and you only need priority for triage. Severity levels like Fatal/Blocker, Critical, Major, and Minor describe the impact (Atlassian). Priority levels range from Lowest/Trivial to Highest/Blocker (Atlassian).

Here's the trap: teams assign priority based on severity. A crash is High, a typo is Low. But that ignores business context. A crash in an internal admin tool might be low priority if no one uses it today. A typo on your pricing page could be high priority if it affects conversions. So in triage, ask one question: What happens if I don't fix this today? If the answer is "we lose money" or "we get sued," it's high priority. If the answer is "we'll hear about it later," it's not.

3. Run a five-step triage walkthrough

Here's my routine. It takes about 30 minutes for a queue of 50 bugs.

1. Scan for KEV matches. Use the catalog's search or your own notes. If a bug references a CVE in KEV, mark it Blocker.
2. Check for accessibility impact. If your product is a website, WCAG conformance matters. WCAG 2.2 has 13 guidelines under four principles, and content conforming to WCAG 2.2 also conforms to 2.1 and 2.0 (W3C). Accessibility defects aren't optional—they're legal risks. If a bug violates WCAG AA, it's at least High priority.
3. Evaluate exploitability, not just severity. A crash is bad, but a crash that can be triggered by a remote attacker is worse. If a bug is exploitable without authentication, it's High. If it requires local access, it's Medium.
4. Assign to the right owner. If you're using a tracker like Jira or Bugzilla, assign the bug to the appropriate developer. If the bug is a duplicate, mark it Duplicate. If it's not reproducible, mark it Non-Reproducible. These are standard states (Atlassian).
5. Set a due date. For KEV items, use the remediation due date. For everything else, set a date based on business impact. If you don't have a date, you'll defer forever.

What can go wrong: You'll be tempted to assign a bug to the first developer who's free. Don't. Assign to the developer who owns that code. Otherwise, the bug bounces around and gets lost. Also, resist the urge to close a bug as "Fixed" without retesting. The bug life cycle includes Pending Retest, Retest, and Verified stages for a reason (Atlassian).

4. Use the KEV catalog as your prioritization framework

CISA directs organizations to use the KEV catalog as an input to their vulnerability management prioritization framework (CISA). You can do the same for bugs. Create a simple priority matrix:

• Blocker: In KEV, or causes total system failure.
• High: Exploitable remotely, or violates WCAG AA.
• Medium: Exploitable locally, or affects a non-critical feature.
• Low: Cosmetic, no security impact.

This isn't rocket science. It's just applying the same rigor that security teams use. And it works for non-security bugs too. If a bug affects a user story that's due this sprint, it's high priority. If it's a nice-to-have, it's low.

5. Track your triage quality with metrics

You can't improve what you don't measure. Two metrics matter: defect rejection ratio and defect leakage ratio. Rejection ratio is (rejected defects / total reported) × 100. Leakage is (production defects / total found) × 100 (Atlassian). If your rejection ratio is high, your reporters are filing junk. If your leakage is high, your testers are missing bugs. Triage is the filter that controls both.

For example, if you see 100 bugs a month and reject 20, your rejection ratio is 20%. That's probably too high. Investigate whether your bug template is clear. If you have 10 bugs in production out of 100 total, your leakage is 10%. That's decent, but you can do better. The goal is to catch bugs before production, not after.

Bottom line

The single best move in bug triage is to stop prioritizing by severity and start prioritizing by real-world exploitability and business impact. Use the KEV catalog as your north star. If it's exploited in the wild, it's a Blocker. If it's a cosmetic typo, it's Low. Everything else falls in between. That's how you triage like a security engineer—and ship software that doesn't burn down.

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
• W3C WAI (WCAG 2 Overview) - https://www.w3.org/WAI/standards-guidelines/wcag/