A false positive feedback loop has six parts: an easy way to report, a route to the rule owner, a response target, a fix that includes a new test, a release, and a reply to the reporter. Without the last step, developers learn that reporting changes nothing and go back to suppressing.
Why loops fail
Most teams have a way to dismiss a finding and no way to say that the rule is wrong. The dismissal fixes one instance for one person. The rule stays wrong for everyone else, who each dismiss it again. A loop turns individual dismissals into rule fixes.
The six steps
- Make reporting one click or one line. Put a link in the rule message that opens a prefilled issue with the rule id and the file location. The less typing, the more reports.
- Route by rule id. Each rule has a named owner, so a report lands with a person, not a shared inbox.
- Set a response target. For example, acknowledge within two working days and decide within a week. Publish it.
- Triage into one of four outcomes.
- Rule bug: fix the rule.
- Rule too broad by design: narrow it or change its scope.
- Real finding: explain why and help fix the code.
- Code is safe and the rule cannot know: document the suppression pattern.
- Fix with a test. Add the reduced sample to the rule's test suite before changing the logic, so the fix is proven and the bug cannot return.
- Close the loop. Reply to the reporter with the outcome, and note the change in a rule changelog.
What to record per report
| Field | Why |
|---|---|
| Rule id | Routes it and feeds per rule counts |
| Link to code at that commit | Reproduces it |
| Outcome category | Shows patterns across reports |
| Time to first response | Shows whether the loop is working |
| Test case id | Links the report to the regression test |
Signals the loop works
- Suppression comments for a rule fall after a fix.
- Repeat reports of the same cause become rare.
- Reporters get replies, and say so.
- Rules at warn level are promoted, because trust grew.
When the maker is someone else
If the rule comes from an external tool or vendor, the same loop applies, with an extra step: send a minimal reproduction to the maintainers and keep a local exception, with an expiry, until they respond. Local exceptions with no expiry tend to become permanent.
Pitfalls
- Treating every report as developer error. Some reports are real, but if you assume so, the loop dies.
- Fixing the instance, not the rule.
- Letting the issue queue grow with no owner. A queue nobody reads is a polite way of saying no.
- Tuning a rule to silence one loud team and creating false negatives elsewhere. This is why each fix needs a sibling test that should still be flagged.
Quick check
Who should own a custom rule?
A named person or team, recorded next to the rule. Owners answer reports, review the ledger and decide when to retire the rule.
Should every report lead to a rule change?
No. Some reports are real findings and some are cases where the code is safe but the rule cannot tell. The point is that every report gets a decision and a reply.
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.
Last reviewed: 19 October 2026.
