A finding says something is wrong. A verified patch shows that it is no longer wrong, without breaking anything else. Most tooling is good at the first and leaves the second to people, which is why backlogs grow even as detection improves.
Two different outputs
Detection produces a list: package, version, advisory, severity. It is cheap to produce at scale and easy to count, so teams report it.
A patch is a change to code or dependencies, plus evidence that the change works. It is expensive, needs context about your application, and is harder to count. The gap between the two is where risk lives.
What makes a patch verified
A patch deserves the word verified when you can answer yes to each of these.
- The fix targets the right package and the right version range.
- The advisory data says which version contains the fix. The OSV schema records this as a fixed event, and it prefers that over a last affected marker because a fixed event names the exact version with the patch.
- The build still compiles and the existing tests pass.
- Behaviour that touches the fixed code path has a test or a manual check.
- A rescan after the change no longer reports the issue.
- The change shipped, not just merged.
Why version numbers can mislead
Vendors sometimes backport a fix into an older release. Red Hat points out that a patched system can run an older upstream version number with the fix applied, and that scanners judging by version alone can flag patched packages as vulnerable. So a version check can give both false alarms and false comfort. Verification needs advisory data that understands backports, or a check of the actual build.
Why dependency bumps are not always fixes
Upgrading to the fixed version sounds simple. A minor or major bump can change behaviour, drop an API or pull in new transitive dependencies. Treat a fix pull request as a proposal that still needs your tests and a reviewer, not as a done item.
Measure the right thing
Counting findings opened rewards detection. Better measures are time from disclosure to a verified, deployed fix, and the number of known exploited issues still present in production. Both track what an attacker could actually use.
Where automation helps
Automation can draft the change, run the tests and open a pull request, which removes the tedious part. The decision to merge belongs to a person unless you have decided otherwise for a specific, low risk category. Safeguard covers the inventory and prioritisation parts of this with SBOM and dependency scanning and reachability analysis, and you can try a free scan at gold.safeguard.sh/scan. Autonomous remediation with fix PRs is off by default, and every category starts on Manual, so a person approves changes.
Quick check
Is a merged fix pull request the same as a verified patch?
No. Merged means reviewed and accepted. Verified also means tested, rescanned and deployed.
Can a scanner verify a patch on its own?
Only partly. A rescan shows the finding is gone, but it cannot tell you the application still behaves correctly.
Sources
Last reviewed: 19 October 2026.
