The owner of record is the team that controls the manifest where the override lives, usually the owner of the deployable build or of the shared version list. They approve it, monitor it, renew it or remove it. The requester is not the owner just because they raised it.
Why you need this
An override is a promise: "we deliberately use this version instead of what the resolver would choose." Promises need owners. Without one, nobody removes the override when the upstream fix lands, and nobody answers when it breaks something.
Tools reinforce where ownership sits. npm states that overrides are only considered in the root package.json, and overrides in installed dependencies, including workspaces, are not considered. Cargo only looks at patch settings in the manifest at the root of the workspace and ignores patch settings in dependencies. So the root manifest owner is the practical owner.
A responsibility table
| Activity | Owner of record | Requester | Security |
|---|---|---|---|
| Approve the override | Accountable | Proposes | Consulted |
| Apply the change | Responsible | May open PR | Informed |
| Monitor for breakage | Responsible | Informed | Informed |
| Review date and renewal | Accountable | Consulted | Consulted |
| Remove when no longer needed | Responsible | Informed | Informed |
| Record exceptions | Responsible | Consulted | Consulted |
If you use a RACI style grid already, adapt it. The point is that exactly one party is accountable for each row.
Use CODEOWNERS to route the right review
GitHub's CODEOWNERS file defines individuals or teams responsible for code in a repository, and repository owners can enable branch protection to require review from code owners. In the file, the last matching pattern takes precedence, so order matters.
Point your manifests and lockfiles at the owning team:
# Shared version lists belong to platform
/build/versions/ @org/platform-build
# Each service owns its own manifest
/services/checkout/package.json @org/checkout-team
/services/checkout/package-lock.json @org/checkout-team
Now any pull request that adds or edits an override automatically asks the owner for review. Security can still open the pull request. The owner decides whether it merges.
What owner of record must do
- Keep the decision record linked from the manifest.
- Set a review date. Many teams choose a short interval for overrides tied to a vulnerability.
- Watch for the removal condition, such as an upstream release that raises its own minimum.
- Hand over the ownership explicitly if the team is reorganized. Overrides tied to a team name that no longer exists are common debt.
Orphaned overrides
Search your repositories for override blocks and compare them to your register. For each unexplained one, assign an owner and ask them to write the record or remove the override. Treat a missing owner as a finding, in the same way you would a missing code owner for any other sensitive file.
Quick check
Can the platform team own all overrides?
Only for the shared version lists it controls. For a deployable build, the team that ships it should own overrides in its root manifest, because it carries the runtime risk.
Does owning an override mean fixing the upstream bug?
No. It means keeping the override justified, monitored and temporary. Reporting or fixing upstream is a good way to retire it, but it is a choice, not a duty.
Sources
Last reviewed: 19 October 2026.
