A named staff member or team must own every path a contractor touches, for review today and for fixes after the contractor leaves. Record that in a CODEOWNERS file and require code owner approval, so accountability sits in the repository and not in someone's memory. This is an engineering control, not a legal opinion.
The question underneath
Teams often ask who owns contractor written code, and mean two different things. One is legal ownership of the work product, which depends on your contract and the law that applies. Ask your legal advisers for that.
The other is operational accountability: who reviews a change, who answers when it breaks at 2 a.m., who patches the library it uses next year. That one is yours to define, and it is the one this post covers.
What CODEOWNERS gives you
GitHub says code owners are automatically requested for review when a pull request modifies code they own. When required reviews are enabled, an admin can also require code owner approval before the author can merge. The people you list must have write permissions, and when the owner is a team, that team must be visible and have write permissions. Review requests use the CODEOWNERS file from the pull request's base branch.
The file lives in .github, the repository root, or docs, and GitHub uses the first one it finds in that order.
Build the map in four steps
- List the paths. For each repository the contractor works in, list the directories and files they will change.
- Assign a team, not a person. Individuals go on leave and change jobs. Use a team that has several members.
- Cover the sensitive files. Dependency manifests, workflow files, infrastructure definitions and the CODEOWNERS file itself need owners. See protecting workflow files and the last match wins pitfall.
- Require code owner approval on the protected branches.
What an ownership record should hold
| Field | Example |
|---|---|
| Path | The payments module directory |
| Internal owning team | Platform team |
| Named backup | A second reviewer on that team |
| Contractor with write access | Name and end date |
| Documentation location | Link to the design notes |
| Last reviewed | Date |
The map tells you in minutes who to ask about a path. It also reveals the dangerous case: a path with no internal owner that only the contractor understands.
Finding gaps
GitHub's tooltip on a file shows who owns it and from which CODEOWNERS line. Walk the contractor's directories and hover, or read the file. The related post on finding repos nobody owns shows a way to sweep at scale. Any path that shows no owner needs one before the contractor's last day.
Make ownership real
- Ask the owning team to review at least a sample of the contractor's pull requests deeply, not only approve.
- Pair a staff engineer with the contractor for the riskiest module.
- Put the contractor's design reasoning in the repository, as notes beside the code.
- Add the ownership map to the engagement handover.
A warning about bots and AI
If a contractor uses AI coding tools, the owner is still a human who must understand what was merged. The post on who should review AI generated code covers the rule.
Safeguard's asset discovery helps you find repositories and components, and its dependency scanning and reachability analysis tell the owning team which vulnerabilities in contractor written code actually matter. Try the free scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how findings are assigned and tracked, which is the same job your owning team will do for contractor written code.
Quick check
Does CODEOWNERS decide who legally owns code?
No. It routes reviews. Legal ownership comes from your contract and applicable law, so ask your legal advisers.
Who should be a code owner, a person or a team?
Prefer a team with several members that has write permission, so reviews continue when one person is away.
Sources
Last reviewed: 19 October 2026.
