When a fork, vendor rebuild or internal patch keeps the original version number, scanners match on the number and may still raise an alert even though the code is fixed. Verify the fix in the source or binary, then suppress that alert for that exact build with the proof attached and an end date.
Why the scanner is confused
Most dependency scanners compare a package name and version to affected ranges in an advisory database. The OSV schema, for example, describes affected ranges using introduced and fixed versions, or full commit hashes for source ranges. If your build carries a patch but the version string says 2.3.1, a name and version match will say it is affected.
The scanner is not wrong about the number. It cannot see that you cherry picked the fix.
Common situations
- An internal fork with a security patch applied on the same version.
- A vendor or distribution rebuild that backports a fix without bumping the upstream version.
- A vendored copy of a library inside your repository.
- A shaded or bundled copy inside a larger archive.
How to verify before you suppress
- Read the advisory. Find the commit or change that fixes it.
- Check your source. Is that change, or an equivalent, present in your fork? A diff or a blame view is evidence.
- Check the artifact. If you ship a binary, confirm the patched behavior in the built output, not just in the repository.
- Test it. If the advisory includes a proof of concept or a description of the faulty behavior, write a test that fails on the old code and passes on yours.
- Pin the identity. Record the commit hash or build digest, since the version string will not tell the story.
| Evidence | Strength |
|---|---|
| Link to the fix commit in your fork | Good |
| Passing regression test | Better |
| Same plus a build digest | Best for audits |
Write the suppression record
Say what a reader needs: the advisory ID, your artifact identity, the fix commit, the test, the owner and the end date. Scope it to this build, not to the package name.
Fix the root cause when you can
Suppressions for forks come back every scan. Two ways to cut them out:
- Give your fork its own version, such as a local suffix, and add an affected range correction if your tool supports it.
- Publish a statement in a machine readable form. OpenVEX offers a fixed status for a product, which lets downstream tools read the answer instead of guessing.
Our post on checking distro backports shows the same method for operating system packages.
When the fork is stale
A fork that needs hand patches for every advisory is a maintenance cost. Track how many patches you carry. If the number grows, plan a return to upstream.
Quick check
Can I trust a vendor's claim that a fix was backported?
Ask for the advisory reference and the changed source or a signed statement. Then spot check behavior with a test.
Should I rename my fork's version?
Usually yes. A distinct version makes scanners and humans see that it is not the upstream build.
Sources
Last reviewed: 19 October 2026.
