The recurring vulnerability rate is the share of findings closed in a period that reappear within a set window, such as 90 days. A high rate means fixes are not sticking: a dependency pinned back, a base image rebuilt from an old layer, or a code pattern copied again.
Why it is worth tracking
Closure counts reward fixing. They do not reward fixing durably. A team that closes the same finding four times looks productive on a closure chart and unproductive on a recurrence chart. Recurrence points at root causes rather than symptoms.
Definition
Recurring rate equals findings reopened or re-detected within N days of closure, divided by findings closed in the period. Pick N, say 90 days, and keep it fixed. Count by the same finding identity: same component and advisory, or same rule and location.
Common causes
| Cause | Example | Remedy |
|---|---|---|
| Lockfile or pin reverts | A merge restores an old version | Dependency policy checks in pull requests |
| Stale base images | Rebuild pulls a cached vulnerable layer | Scheduled base image refresh |
| Copy paste patterns | Insecure snippet reused elsewhere | Rule in static analysis, shared library |
| Branch drift | Fix lands on main but not on a release branch | Backport tracking |
| Reintroduced transitive dependency | A new package pulls it back | Gate on the vulnerable version |
| Closed as false positive then correct | Triage mistake | Review sample of closures |
Steps
- Give each finding a stable identity across scans.
- Record closure date and closure reason.
- Flag re-detections within the window.
- Group recurrences by cause category, and sample a few by hand each month.
- For each major cause, add a preventive control, then watch the rate.
Reading the figure
A low recurrence rate with few closures is not meaningful. Show the count of closures. A recurrence rate that rises after an automation change may point at a faulty rule or bad pin handling.
Report by team and by source, but avoid ranking. The aim is to find which control is missing, such as a pull request gate, not to blame a team.
Related checks
Compare recurrence by closure reason. Findings closed as "fixed" should recur rarely. If findings closed as "not reachable" reappear, your reachability labels may need review, or code changes are making them reachable.
Quick check
What window should we use?
Ninety days is common, but any fixed window works if you keep it constant and document it.
Is a recurrence always a failure?
No. A new release can legitimately reintroduce an old library. Categorise causes before judging.
Safeguard supports this with policies and gates in pull requests plus dependency scanning, and you can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
