When your scanner says a package is vulnerable and your vendor says it is patched, both can be reading the same facts differently. The scanner often compares version numbers. The vendor may have applied the fix to an older version without changing its upstream number. You settle it with advisory data and a build check.
What a backport is
Red Hat describes backporting as taking a security fix from a newer upstream release and applying it to the older version it still ships. Its example is a PHP version upstream no longer supported, where moving to the next upstream release could break compatibility, so the vendor patched the old line instead.
The result is a package that reports an old upstream number but contains the fix.
Why scanners get this wrong
A scanner that only looks at the upstream version sees a number below the advisory's fixed version and raises a finding. That is a false positive if a backport exists. The reverse also happens: a headline telling everyone to upgrade to an upstream release does not apply to people on vendor builds.
How advisory data expresses fixes
The OSV schema describes affected ranges with events such as introduced and fixed, and each range has a type: semantic version, ecosystem specific or git. Ecosystem specific ranges exist because package managers compare versions in their own ways. A tool needs to use the right comparison for the ecosystem, and ideally the vendor's own advisory for vendor builds.
A short process to resolve a conflict
- Identify the exact installed package and release string, not just the upstream version.
- Read the vendor advisory for the CVE and see whether it says the fix arrived by backport.
- Check the package changelog or build metadata for the CVE reference.
- Rescan using a data source that understands vendor advisories.
- If still unclear, record the decision as an exception with an owner and a review date.
When to rebase instead
Backports are the right call when stability matters more than features. If a vendor line is near end of support, or a fix would be too large to backport safely, moving to a supported release is the better path. That choice should come from the vendor's stated support dates, which you should read directly.
What to put in your tooling
Prefer scanners and data feeds that ingest vendor advisories. Keep a short list of packages where version checks are known to disagree, and review it when you upgrade the base image.
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 version below the fixed version always vulnerable?
No. On vendor builds the fix may be backported, so check the vendor advisory and package changelog.
Should I suppress the finding while I check?
Mark it as under review with an owner and a date, rather than suppressing it silently.
Sources
Last reviewed: 19 October 2026.
