For each forked or patched library, record the upstream name and version it started from, where the fork lives, the commit in use, and a short list of local changes. Without the upstream link, vulnerability data cannot be matched, and without the change list nobody knows if upstream fixes still apply.
Why forks break inventories
Scanners match components by name, version and identifiers. A fork renamed to an internal name, or a library copied in with edits, looks like unknown software. It then shows no vulnerabilities, which reads as clean when the truth is unknown.
The NTIA minimum elements report treats other unique identifiers as the look up key for relevant databases, and asks that component names defined by the original supplier be preserved, with aliases noted where possible. For a fork, that means keeping the original supplier and name visible.
What to record
| Field | Example content | Why |
|---|---|---|
| Upstream supplier and name | The original project | Matching to advisories |
| Upstream base version | The release it forked from | Which fixes are present |
| Fork location | Repository URL and commit | Reproducibility |
| Local changes | Short list or diff reference | Does an upstream fix apply cleanly? |
| Reason for the fork | Bug, feature, license, abandoned upstream | Whether it can be dropped |
| Owner | Named person or team | Who maintains it |
| Last upstream sync | Date | How far behind |
Steps
- Search the organization for repositories that are forks, and for dependencies pointing at git URLs rather than registries.
- For each, find the upstream and the base version from the history.
- Write the record above.
- Check upstream advisories for the base version and later versions.
- Decide per fork: sync, keep, or replace.
Common findings
- Forks created years ago for a one line fix that upstream later accepted. Candidate to drop.
- Forks of abandoned projects. These need an owner who accepts the maintenance duty, or a replacement plan.
- Forks that nobody can identify the base of. Treat them as unknown source code, review them like internal code.
Patched in place
Edited copies inside a vendored folder are forks without the fork. Look for license headers and version comments, and record them the same way.
Remediation of gaps
Start with the list sorted by distance from upstream. The furthest behind carry the most unknown risk. For each, either rebase onto a current upstream release, contribute the change upstream, or document why the divergence is intentional and who reviews upstream advisories.
Safeguard's SBOM and dependency scanning and reachability analysis help decide which unmatched or outdated components matter first. Try a free scan at gold.safeguard.sh/scan.
Quick check
Do forks need their own version number?
Give them one so builds are reproducible, but keep the upstream base version in the record. Both are needed.
How do I check if an upstream fix applies to a fork?
Compare the fix commit with your local changes. If the files do not overlap, it often applies cleanly. If they do, review by hand.
Sources
Last reviewed: 19 October 2026.
