A noise budget is a cap on how many low-value findings a team is asked to look at per week or per pull request. Set it from a measured baseline, spend it on the highest-risk rules first, and tune or retire rules when you go over.
Definition
Noise means a finding that a developer reviews and then closes without a code change: false positives, unreachable code paths, test files, and accepted risk. A noise budget treats developer attention as a limited resource, the same way an error budget treats reliability.
It is not a promise that zero real issues will be hidden. It is a deliberate choice about how much unproven work a tool may create.
Step 1: Measure the baseline
Pull the last 30 days of findings and label each one.
- Fixed with a code change.
- Closed as false positive.
- Closed as not reachable or not applicable.
- Closed as accepted risk.
- Still open.
The share in groups 2 to 4 is your current noise rate. If you have no labels yet, review a random sample of 30 findings by hand. A small sample gives a rough number, which is enough to start.
Step 2: Pick two numbers
Choose a per-pull-request cap and a per-week cap per team. Keep them small enough that someone can read everything in the time they would give a code review comment.
There is no universal value. Start with a number your reviewers say they could comfortably read, and adjust after two weeks.
Step 3: Decide what spends the budget first
Not every rule deserves a seat. Rank rules by what happens when they are right.
| Rule type | Priority for the budget |
|---|---|
| Reachable, exploitable, fix available | Highest |
| Policy violations with a clear owner | High |
| Style or hygiene findings | Low, show in a panel |
| Informational | Not in the main flow |
When the cap is hit, the lowest priority items fall back to a digest or dashboard instead of a pull request comment.
Step 4: Enforce and review
Two habits keep the budget real.
Show the count. Put the number of findings shown and hidden in the pull request summary, so nothing disappears silently. Hidden findings are still in the dashboard.
Review rules monthly. Sort rules by dismissal rate. A rule with a dismissal rate near 100 percent has earned a tune, a scope change, or retirement. See sunsetting a rule for a feedback loop that works.
What not to do
- Do not set the budget to hide a backlog. Old findings need their own burn down plan.
- Do not cap critical, reachable, known exploited findings. Those always show.
- Do not compare teams on noise rate without noting their stack. Some languages produce more noisy rules than others.
Where it fits with other controls
A noise budget works well next to a new-code-only gate, which asks authors to fix only what they introduced, and a scheduled report for the owner. Together they keep pull requests quiet and still surface old risk. For arithmetic on what noise costs in review time, see the cost of a false positive.
Safeguard's reachability analysis and policy controls can narrow what reaches a pull request, and you can inspect a first set of results with the free scan at gold.safeguard.sh/scan.
Quick check
What is a good noise rate?
There is no standard figure to cite. Track your own rate over time and aim for it to fall as you tune rules, while real fixes stay steady.
Does a budget risk hiding a real vulnerability?
It can if you set it badly. Keep critical and reachable findings outside the cap, and show hidden counts so nothing is silent.
Last reviewed: 19 October 2026.
