Often not. Most dependency scanners match advisories to a package name, ecosystem and version. If you rename a fork or publish it under a new name, the advisory for the original no longer matches, and the scanner can report nothing while the same flawed code ships. You have to carry the link yourself.
How matching usually works
An advisory names an affected package and a version range. A scanner reads your manifest or lockfile, takes each package name and version, and looks for a match. The match is about identity, not code. It never opens the library to ask whether the code resembles something vulnerable.
That is efficient, and it fails quietly for forks. Three common cases:
| Fork style | What the manifest says | Likely scanner result |
|---|---|---|
| Kept the same name via a replace or override | Original name, different source | May still match by name, version may mislead |
| Published under a new name | New name, new version | No match, looks clean |
| Copied into the repo as source | Nothing | No match at all |
Why this matters more than it sounds
Forks exist because someone needed to change something, often to fix a bug quickly. The fork may include fixes upstream lacks, but it can also lack fixes upstream shipped later. A clean scan result tells you neither. It tells you just that nothing matched.
Closing the gap
- Keep a register. For every fork, record the upstream project, the base version and the date. See what to track for each fork.
- Describe ancestry in the SBOM. Use the pedigree field so the original is named. See describing a fork in a CycloneDX SBOM.
- Watch upstream advisories by hand. Subscribe to the original project's security feed, and check each notice against your base commit. See whether your fork contains an upstream fix.
- Keep a distinct version suffix. A version like the upstream number plus a local tag shows at a glance that the component is not the original.
- Add a custom rule or tracker entry. If your tooling supports custom advisories or ignore and include lists, create an entry that maps your fork name to the original's advisories.
What not to assume
Do not assume the opposite problem is absent either. A fork that keeps the original name can attract advisories that do not apply, for example if you removed the vulnerable module. Record why in a short exception note, with an expiry date, so the finding is not silently ignored forever.
Also watch for look-alike names. A package that copies a popular name is a different risk, covered in is this the official package or an impostor fork.
Where Safeguard fits
Safeguard's SBOM and dependency scanning inventories what your builds pull in, and its reachability analysis helps rank which findings matter. Names still carry the match, so keep your fork register current. Start with a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each finding ties to a package and version, which is exactly the link a rename breaks.
Quick check
Does a clean scan prove my fork is not vulnerable?
No. It proves nothing matched by name and version. The same code may be present under a name no advisory mentions.
What is the cheapest fix?
A fork register plus a feed subscription to the original project's security notices, checked at each sync.
Last reviewed: 19 October 2026.
