Keep a small ledger per rule: how many findings were reviewed, how many were confirmed real, how many were dismissed as false positives, and the confirmed share. That share is the rule's precision. Review the ledger on a schedule and promote, tune or retire each rule based on it.
Definitions
- Precision: of the findings a rule reports, the share that are real. Confirmed divided by reviewed.
- Recall: of the real problems that exist, the share the rule finds. Harder to measure, because you must know about problems the rule missed.
- Dismissal reason: a short category for why a finding was set aside, such as safe by construction, test code, generated code, or rule bug.
Most teams can measure precision cheaply. Recall needs seeded bugs or incident reviews.
The ledger
| Column | Meaning |
|---|---|
| Rule id | Stable name |
| Owner | A person or team |
| Stage | Warn, error on new code, error everywhere |
| Reviewed | Findings someone has judged |
| Confirmed | Judged real |
| Dismissed | Judged not a problem, with reason |
| Precision | Confirmed over reviewed |
| Last reviewed | Date |
A spreadsheet is enough. The value is in having one row per rule and a date on every row.
Where the data comes from
- Triage statuses. If your workflow records statuses such as confirmed, false positive and accepted risk, count them monthly.
- Suppression comments. Each one is a judgment. Sample them and read the stated reasons.
- Sampling. If volume is high, review a random sample, not the first page of results. OWASP notes that static tools are known for high false positive counts, so sampling is a normal part of running them.
- Developer reports. Tag each with the rule id.
Reading the numbers
- High precision, low volume. Good candidate for error mode.
- Low precision, high volume. Tune the rule or move it back to warn, since developers will start suppressing everything.
- Many dismissals with the same reason. The reason is the bug. Fix it in the rule.
- No findings at all. Either the code is clean or the rule is broken. Check with a test file.
- Rising suppressions after a release. Something changed, maybe a framework upgrade.
Cautions
- A small sample gives a wide margin of error. Do not act on ten findings as if they were a hundred.
- Do not set a precision target and punish teams for missing it, because people then stop recording dismissals honestly.
- Precision alone can mislead. A rule that reports almost nothing may be precise and useless.
Try it yourself
Click through it at your own pace, or open it full screen.
See how filtering by whether code is actually called changes the number of findings you would have to triage. Each rule in your ledger has a similar story.
Quick check
What precision is good enough?
It depends on the cost of a miss and the cost of a review. Decide a threshold per severity with your team, and treat it as a starting point to revisit.
How often should the ledger be reviewed?
Monthly for new rules, and at least quarterly for stable ones.
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.
