Imagine you're the lead developer on a team that just launched a customer-facing portal. The bug tracker is filling up: a cosmetic misalignment in the header, a broken checkout button, a rare crash when a user uploads a file with a long name. Which do you fix first? If you're like most teams, you might be tempted to sort by severity. But that's a mistake.
We've been there—staring at a queue of defects, trying to decide what deserves attention. The truth is, the tools we use shape our decisions, and too often we let the tool's default fields dictate our priorities. The single best move you can make is to stop treating severity as the primary driver of what gets fixed, and instead weight priority—which factors in business impact, user pain, and especially, for security bugs, whether the weakness is actively being exploited. Let's debunk some myths and get your tracker working for you.
Isn't severity the same as priority?
No. Severity measures how badly a bug affects system functionality or user experience—a crash is severe, a typo is minor. Priority measures how urgently it needs to be fixed, which is a business decision. (Atlassian, issue priority vs severity) A bug can be severe but low priority if it occurs only in a legacy feature no one uses. Conversely, a minor-severity bug in a login flow could be high priority if it blocks every new user. We've seen teams waste weeks polishing a rare cosmetic glitch while a slow-but-steady data leak went unnoticed. Stop conflating the two.
Shouldn't we fix all critical-severity bugs first?
Not necessarily. In security, severity is quantified by CVSS, but that's just a starting point. The NVD enriches every CVE with CVSS impact metrics, a CWE type, and CPE applicability—but it doesn't tell you if anyone is actually exploiting it. (NVD) That's where CISA's Known Exploited Vulnerabilities (KEV) catalog comes in: it's the authoritative source of vulnerabilities known to be exploited in the wild, and CISA directs organizations to use it as an input to prioritization. (CISA) So a CVSS 9.0 bug that isn't exploited may be lower priority than a CVSS 7.0 bug that's actively being used in ransomware campaigns. The KEV catalog even records remediation due dates and whether the bug is associated with ransomware. (CISA) That's the kind of intel you can't get from a severity score alone.
Doesn't fixing bugs earlier always cost less?
This is a stubborn myth. We've all heard the rule of thumb that a bug found late costs 100x more to fix than one found early. But a large study of 171 software projects from 2006–2014 found no evidence that issues resolved in a later phase cost consistently or substantially more effort than issues resolved soon after introduction. (arXiv) The delayed issue effect appears intermittently, only in certain kinds of projects. So while early detection is generally good, don't assume every bug that slips through will be a budget-buster. Prioritize based on actual risk, not a fear of late fixes.
What's the right workflow for a bug tracker?
Keep it simple. A basic workflow—Open to In Progress to In Review to Done to Closed—works well, and you can add a Triage step if you need it. (Atlassian) The point is to move bugs through stages without overcomplicating. We've seen teams with 15 statuses that no one understands. Assign bugs to the appropriate developer, reassign to the original tester after a fix, and log any new defects found during validation as separate issues. (Atlassian) That last one is key: don't reopen the same bug for a different problem—track it separately.
Should we use a dedicated bug tracker or just GitHub Issues?
For small projects, GitHub Issues is fine. But when you outgrow built-in tracking—when you need workflow management, security controls, or custom fields—dedicated tools like Bugzilla are worth the switch. (Bugzilla) Bugzilla was one of the first open-source trackers, written in 1998 to replace Netscape's in-house system, and it's still used by Mozilla and hundreds or thousands of organizations. (Bugzilla) Its design principles—running on open-source tools, speed, browser-agnostic—are still relevant. The right tool is the one that fits your workflow, not the one with the most features.
How do we track accessibility defects?
Accessibility defects are often overlooked, but they're just as important. Validate them against WCAG, the W3C's Web Content Accessibility Guidelines, which defines success criteria at three levels: A, AA, and AAA. (W3C) WCAG 2.2 is the latest version, published in October 2023, and it's backwards compatible—if you meet 2.2, you also meet 2.1 and 2.0. (W3C) When you file a bug, specify the exact guideline and level you're testing against. That way, the developer knows exactly what to fix, and you can track compliance over time.
What about security vulnerabilities—do they have a different lifecycle?
Yes, security vulns have a separate tracking lifecycle. The NVD enriches every CVE with data from descriptions, references, and other public info, but it doesn't test for vulnerabilities itself—it relies on vendors and researchers. (NVD) So your internal tracker should link to CVE IDs, but also to CISA's KEV catalog for exploit status. BOD 22-01, now superseded by BOD 26-04, required federal agencies to remediate KEV vulnerabilities on a strict timeline. (CISA) Even if you're not federal, using the KEV catalog as a prioritization input is a smart practice.
Here's a concrete example: In the 2024 CWE Top 25, the top three weaknesses were CWE-79 Cross-site Scripting, CWE-787 Out-of-bounds Write, and CWE-89 SQL Injection. (CWE) CWE-79 had a score of 56.92 and only 3 CVEs in the KEV catalog, while CWE-787 had 18 KEV CVEs. (CWE) If you have a cross-site scripting bug and an out-of-bounds write bug, and both are exploited, you might fix the out-of-bounds write first because it's more often exploited. That's the kind of nuance priority brings.
Another example: In the OWASP Top 10 2021, Broken Access Control (A01) moved up to first place, with over 318,000 occurrences in the dataset. (OWASP) That's a strong signal that access control bugs are common and should be high priority in your tracker, even if they don't always show up as critical severity.
Bottom line
Stop sorting by severity alone. Set priority based on business impact, user pain, and—for security bugs—whether the vulnerability is in CISA's KEV catalog or ranks high in the CWE Top 25. Your bug tracker is a decision tool, not just a log. Use it to make the calls that matter.
Comments (0)
Please sign in to post a comment.
Don't have an account? Create one
No comments yet. Be the first to comment!