When you fork an open source library internally, you become its maintainer for security purposes. Assign an owner, record why you forked, track upstream security fixes and merge them, document your patches, and set a date to review whether you can return to upstream. Without these, a fork becomes an unpatched copy.
Why forks are risky
A fork stops receiving fixes automatically. The upstream project publishes a security release, scanners may not match your fork's renamed version, and nobody on your team notices. The vulnerable code can sit for years under an internal name.
Forking is sometimes right: an abandoned dependency that you rely on, a needed change upstream will not accept, or a license issue. It is a commitment, so treat it as one.
Rules to write before forking
| Rule | Detail |
|---|---|
| Approval | A fork needs intake approval with a named owner and a stated reason |
| Naming | Keep the upstream name and version visible in metadata so scanners can match it |
| Patch record | Keep your changes as a small, documented set, ideally on a separate branch |
| Upstream tracking | Subscribe to the project's releases and advisories, and review each within the policy time |
| License | Keep license files and notices intact, and check obligations if you distribute the fork |
| Exit plan | A review date to ask if you can upstream the change and drop the fork |
Keeping scanners accurate
Scanners match by name and version. If you rename the package or change its version scheme, they may report nothing. Record the upstream identity in your SBOM, for example as the ancestor of the component, and add a rule or manual check for it. Test with a known vulnerable version to confirm your tooling still reports it.
Day to day process
- Keep a clean mirror branch that tracks upstream.
- Rebase or merge your patches onto each new upstream release.
- Run your tests and the security scan on the result.
- Publish the new internal version and update consumers through the registry.
- Record the upstream version you are based on in the release notes.
When upstream is abandoned
If no one maintains upstream, you are now the only maintainer. Decide whether to invest, replace the library or adopt a community fork, and review that fork through intake like any other package. Consider whether others who depend on it could share the work.
Exit conditions
Revisit the fork at its review date. Retire it when upstream accepts your change, a better supported option exists, or the cost of maintenance exceeds the value. Use the same retirement steps as for any approved package.
Quick check
Do I need to publish my fork?
That depends on the license and what you distribute. Ask legal before shipping a fork to customers.
How do I get alerts for upstream fixes?
Subscribe to the project's releases and advisory feed, and monitor your inventory against advisory data using the upstream identity.
Safeguard scans dependencies and builds SBOMs, runs reachability analysis, and applies policies and gates on pull requests, so the rules in this post can be checked automatically. Autonomous fix PRs are off by default, with every category on Manual. You can run a free scan at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
