Usually because the scan compares version strings and the fix did not change the string, or because the data source has not caught up. Ask the supplier for the exact build and a statement of the fix, check the advisory yourself, and record a VEX style status instead of silencing the alert.
Why the mismatch happens
A scanner matches a component name and version against a list of affected versions. That works when a fix always means a new version number. It breaks when a patch is applied without a visible version bump, for example in a vendor's own build of an open source library. The scanner sees the old number and flags it.
The opposite also occurs. A supplier may say "fixed in 2.4.1" while their SBOM still lists 2.3.9 because it was generated before the fix.
Other causes: the SBOM was made before the patch release, your scan looked at a different build, or the vulnerability data has an error in its affected range.
Step by step
- Confirm the exact version you run. Not the latest release. Compare build numbers or hashes if the supplier provides them.
- Check the SBOM date against the supplier's release notes. If the SBOM predates the fix, ask for a new one.
- Read the advisory. What versions does it say are affected? Is the range correct for your component?
- Ask the supplier for a written statement. Product version, component, advisory, and the fix applied. The OpenVEX specification gives a status called fixed, meaning the product versions contain a fix. A statement of that kind is more useful than an email saying "we patched it."
- Ask for evidence if the stakes are high. A changelog entry, a patch reference, or a rebuilt SBOM with the corrected version.
- Record the outcome. What you checked, what they said, the date, and who accepted it.
Choosing how to treat the alert
| Situation | Treatment |
|---|---|
| Supplier statement says fixed, build matches | Close as fixed with reference |
| Supplier says fixed, SBOM older than fix | Request new SBOM, keep alert open |
| Supplier says fixed but gives no detail | Keep open, ask for specifics |
| Advisory range looks wrong | Report to the data source, record as false positive with evidence |
Do not suppress the alert silently. If the suppression note says "supplier says fixed," a reader a year later cannot tell what that was based on.
Why not just ignore it
Because the same pattern can hide a real gap. If the fix was not actually applied, a quiet override leaves you exposed. Ask once, write it down, move on.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding shows its fixed version, which you can compare with what the supplier claims.
Safeguard's SBOM and dependency scanning show fix information for findings, and the free scan is at gold.safeguard.sh/scan.
Quick check
Can a scanner be wrong about a patched component?
Yes. Matching by version string can miss fixes that did not change the version, and data can lag. Verify before acting either way.
What statement should we ask the supplier for?
Product version, component, advisory and the fix applied, ideally as a VEX status of fixed.
Sources
Last reviewed: 19 October 2026.
