Tune a noisy rule when some of its hits are real, lower its severity when hits are real but minor, and disable it only when it cannot find anything useful in your code. Disabling is a last resort, because it removes detection everywhere that rule applies, including places you have not looked.
Four options for a rule
| Option | What changes | Use when |
|---|---|---|
| Tune | Narrow what the rule matches, add sanitiser or framework knowledge | A mix of real and false hits |
| Lower severity | Same hits, lower priority or non blocking | Real but minor, or low confidence |
| Move to informational | Hits reported, never block, grouped in a summary | You want visibility without friction |
| Disable | Rule stops running | Zero real hits and no realistic chance of any |
A decision path
- Sample the hits. Review a handful, ideally thirty if you have them, and mark each true or false. Sample sizing is discussed in estimating a false positive rate.
- If most are true, keep the rule and fix the code. A loud rule that is right is doing its job.
- If the hits are mixed, look for a pattern in the false ones. A shared helper function or framework call that makes the code safe can often be taught to the rule as a sanitiser.
- If hits are real but unimportant, lower severity or make it informational.
- If nothing in the sample is real, and you can explain why the rule cannot apply, for example the language feature it checks is never used, disable it and write down the reason.
- Re-check later. Rules and code both change. Put a date on any disabled rule.
Safeguards when disabling
- Write down who decided and why.
- Disable per repository first, not globally, so you see the effect before widening it.
- Keep a list of disabled rules in version control, covered by review.
- Compare the vulnerability classes you cover before and after, so you notice if one is now uncovered. See what SAST cannot find for classes tools already miss.
Packaged scan settings as a model
Some scanners handle this with a simple three level setting. ZAP's packaged scans let each rule be set to ignore, warn or fail through a configuration file, with warn as the default. Setting an active rule to ignore also stops it running, which shortens the scan. That is a useful shape for your own policy: every rule has an explicit level, and changes go through review.
Try it yourself
Open the demo and look at how findings by rule differ in volume and severity.
Click through it at your own pace, or open it full screen.
One factual note on Safeguard
Safeguard offers policies and gates with explicit rules per repository. If you want a quick look at your own code, the free scan at gold.safeguard.sh/scan is a no-account place to start.
Quick check
Is it ever fine to turn off a rule for being noisy?
Only after sampling shows no real hits and you can say why. Otherwise tune or lower severity.
Who should approve disabling a rule?
Security plus the owning team, recorded with a reason and a review date.
Sources
Last reviewed: 19 October 2026.
