How do you verify a fix really closed a vulnerability finding?

A finding is truly closed when a rescan of the artifact that ships no longer reports it, and the inventory shows the fixed version. A merged pull request is not proof. Verify the build, rescan with current data, confirm the component version, and keep the before and after results as evidence.

Why a merge is not enough

Many things can go wrong between a merged fix and a clean production artifact. The lockfile may not have been updated. A cached layer may still hold the old library. A second copy of the package may sit elsewhere in the tree. Another service may use the same component and was not changed.

The six steps

1. Confirm the change landed. Check the lockfile or manifest for the new version, not just the diff summary.
2. Rebuild from clean. Build without stale caches so the artifact reflects the new dependency.
3. Rescan the artifact. Scan what ships, such as the built image or package, not only the source tree.
4. Check the inventory. Confirm the fixed version appears and the old one does not appear anywhere. Transitive copies often survive.
5. Look for absent versus not scanned. Under SARIF, a result can be absent relative to a baseline run, meaning it was seen before but not now. Absent can also reflect that the area was not covered this time, so confirm coverage.
6. Record the evidence. Save the before result, the fix reference, and the after result, each with dates and tool version.

A closing record

Keep it short and complete:

finding:   example-lib 2.3.1, advisory GHSA-xxxx
fix:       change reference, upgraded to 2.3.4
rebuilt:   date and build ID
rescan:    date, tool version, data refreshed at
result:    no match; inventory shows 2.3.4 only
closed by: name

Edge cases

• Backported fixes. An operating system vendor may fix a package without changing the upstream version number, so a scanner can keep flagging it. Read the vendor's own advisory before deciding. See checking a distro backported security fix.
• Mitigation instead of upgrade. If you closed the risk by configuration, the finding may remain. Record it as an accepted exception with an owner and an expiry date, not as fixed.
• Reopened items. If the component returns in a later build, the finding should reopen automatically. A tracker that recognises the same finding across runs does this for you.
• Shared components. Search all projects for the same package version. One fix often leaves several siblings open.

Automate the dull parts

The checks in steps 1 to 4 are mechanical. A pipeline can fail a build if the old version is still present, which turns verification into a gate instead of a habit. Keep humans for steps that need judgment, such as accepted exceptions.

Where Safeguard fits

Safeguard's policies and gates can block a pull request when a flagged component is still present, and its autonomous remediation opens fix pull requests (off by default, every category on Manual). Try the free scan before and after a change to see the difference.

Quick check

Sources

• SARIF 2.1.0 specification (OASIS)

Last reviewed: 19 October 2026.