Developers trust severity labels that tell them what to do and by when. Replace abstract labels like High with action labels such as fix before merge, fix this sprint, and track. Keep the score as supporting detail and make sure each label means the same thing in every tool.
The problem with scores alone
A severity score describes how bad a flaw could be in general. It does not say whether it matters in your code, whether a fix exists, or how soon anyone should act. When a team sees "High" next to dozens of items, the label stops carrying information. Our post on CVSS critical versus real risk goes deeper on why.
Different tools also use different scales. The same finding can be High in one and Medium in another, which erodes trust. See severity inflation when scanners disagree.
Use action labels
Define three or four labels, each tied to a behavior.
| Label | Meaning | Developer action | Typical gate |
|---|---|---|---|
| Fix before merge | New, reachable, serious, fix available | Fix in this pull request | Blocks |
| Fix this sprint | Serious or exploitable, existing | Schedule within the sprint | Ticket with owner |
| Track | Real but low impact or no fix | Review on a set date | Dashboard only |
| Ignore with reason | Not applicable | Record why | Hidden after approval |
The exact names matter less than consistency. Pick words your team already uses.
What feeds a label
Combine several inputs rather than relying on a single number.
- Base severity from the advisory.
- Whether the vulnerable code is reachable in your service.
- Whether exploitation is known or likely.
- Whether a fix exists and how risky it is to apply.
- How exposed the service is, such as internet facing or internal.
Our CVSS, EPSS and KEV prioritization guide covers how some of these signals work.
Keep the rules written down
Publish the mapping on one page. A developer who disagrees with a label should be able to see why it was assigned and who to ask. Where the label depends on judgment, say so.
Test trust
Ask developers to sort ten real findings into the labels without seeing the tool's choice. Compare. Large disagreement means the labels or the inputs need work. Run the same exercise after changes to see whether alignment improves.
Avoid label drift
Over time, teams start to use Fix this sprint for everything. Review the share of findings in each label every quarter. If one label dominates, the definitions are too loose.
Handle exceptions with dates
A label that cannot change makes people argue about the label instead of the work. Allow a documented change, with a reason, an owner and an end date, so disagreements have a path that is not a quiet override.
Safeguard combines reachability analysis, policy rules and gates, which lets teams express rules like "block only reachable high risk findings that are new in this change." See the exploitability check demo and the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. See how the context around a finding changes how urgent it is.
Quick check
Do we have to drop CVSS?
No. Keep it as an input and a reference, but do not let it be the only thing that decides the action.
How many labels are right?
Three or four. More than that and people stop being able to tell them apart.
Last reviewed: 19 October 2026.
