A fork register is a table with one row per fork you ship or depend on. Record the upstream project, base version, carried patches, owner, last sync date, and the condition for retiring the fork. Review it quarterly. It turns forks from hidden liabilities into managed assets.
Why a register
Most organizations cannot list their forks. They live in private repositories, in replace lines, in Git URL dependencies and in copied directories. When an advisory arrives, the first question is whether you run the affected code, and without a register the answer takes days. With one, it takes minutes.
The fields
| Field | Meaning | Example |
|---|---|---|
| Fork name and location | Where it lives | internal repo or directory |
| Upstream project and URL | Original source | project and address |
| Base version and commit | Where you forked or last synced | tag plus full hash |
| Carried patches | Count and short list | 3, one security backport |
| Reason | Why the fork exists | needed a fix upstream rejected |
| Owner | A named team and a backup | platform team |
| Last sync | Date | 2026-09-30 |
| Divergence | Behind and ahead counts | 14 behind, 3 ahead |
| Advisory feed | How you hear about issues | project security list |
| Exit condition | When you stop | upstream releases the fix |
| Review date | Next check | 2027-01-15 |
You can fill divergence with the method in how to measure fork divergence.
Who should own a fork
The owner is the team that depends on the fork most, not the person who created it. Give each fork one accountable team and a named backup. The owner has four duties: watch the upstream advisory feed, sync on the agreed cadence, review upstream diffs, and keep the register row current. See what security responsibilities come with maintaining a fork.
Where a fork has no willing owner, that is information. Either assign one or plan to retire it. An unowned fork is the riskiest kind.
How to find forks you forgot
- Search manifests for Git URLs, replace and override lines, and patch sections. See Go replace directives and pinning forks in pip and npm.
- Search your repositories for third party directories and vendored folders.
- Search your package registry account for packages you published that wrap an upstream project.
- Ask each team what they patched and never sent upstream.
- Compare your SBOM with the register, and investigate components that look modified.
Review routine
Each quarter, the register owner walks the rows with the fork owners. For each, answer: is the reason still valid, are we within our sync cadence, did any advisory land, and can we shrink the patch list? Close forks that fail the first question. See exit criteria for forks.
Why auditors like it
A register is evidence of control over third party code. It supports vendor and supply chain questions in security reviews and questionnaires, where answers should be specific and true.
Where Safeguard fits
Safeguard's asset discovery and SBOM and dependency scanning can help build the list of components, and its compliance and evidence automation can hold the records. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Check how many components could be forks or copies, and which would need a register row.
Quick check
Who should own a fork?
The team that depends on it most, with a named backup. An unowned fork should be assigned or retired.
How often should the register be reviewed?
Quarterly is a reasonable default, plus whenever an advisory touches an upstream project in it.
Last reviewed: 19 October 2026.
