Set a rule's severity from two questions: how bad is it if the finding is real, and how often is the rule right? Block the build only when both impact and precision are high. Use warnings for rules that are uncertain, and informational messages for hygiene. Revisit the mapping when the rule's precision changes.
Why one scale is not enough
Teams often copy the severity a tool assigns by default. But severity as a label of impact is different from the decision to stop a build. A rule can describe a serious weakness and still be a poor blocker because it is wrong half the time. Blocking on such a rule teaches developers to route around it.
The two axes
- Impact: what happens if the finding is real. Data exposure, code execution and authentication bypass sit at the top. Style and maintainability sit at the bottom.
- Confidence: how often the rule is right on your code, taken from your precision ledger or a sample review.
Mapping table
| Impact | Confidence | Action |
|---|---|---|
| High | High | Block |
| High | Low | Warn, and invest in tuning or a better rule |
| Low | High | Warn or info, fix in normal work |
| Low | Low | Info, or turn off |
The second row is where most effort should go. A high impact rule that cannot be trusted is a rule worth improving, since the risk is real.
What the tools offer
ESLint rules can be off, warn or error, and only error sets a failing exit code. Roslyn analyzers have Error, Warning, Suggestion, Silent, None and Default, and the setting is applied per rule ID in an EditorConfig file. SARIF, the interchange format, has a level on its rule configuration and a separate rank, which gives downstream tools more than a single label to sort by. Check what your tool supports and use all the levels it has.
Steps
- List your active rules.
- Rate each for impact, using a short written definition so ratings are consistent.
- Rate confidence from data, not feeling.
- Apply the table.
- Record the decision and the date next to the rule.
- Review every quarter, and whenever precision moves.
Where severity should differ by context
- Test code and generated code. Often lower, or excluded, since the risk differs.
- Internet facing services. A rule on request handling may deserve a higher setting there than in an internal batch job.
- New code and old code. Error on changed files, warn on the legacy backlog.
Avoid these mistakes
- Setting everything to error to look strict.
- Letting a vendor's default decide your policy.
- Raising severity after an incident without checking precision, which floods developers with noise.
- Never lowering severity, even when a rule has proven noisy.
Quick check
Should critical findings always block the build?
Not automatically. Block when the rule is reliable enough that a block is usually right. For a low precision rule, warn and improve the rule.
Who decides the mapping?
Security and the owning engineering team together, with the decision recorded and reviewed on a schedule.
Safeguard's scanning covers dependencies and SBOMs, and its reachability analysis helps show which findings your code can actually call. You can run a free scan on a repository.
Sources
Last reviewed: 19 October 2026.
