Home / Knowledge hub / Code owners
Knowledge hub
Code owners
People named as required reviewers for sensitive parts of a codebase.
What it means
Code owners are people or teams named as the required reviewers for particular files or folders. In GitHub this is a file called CODEOWNERS, which lists a path pattern and the owners who must approve changes to anything matching it.
GitLab and other platforms offer the same idea. When a pull request touches a path with an owner, the owner is requested automatically. Combined with branch protection, the platform can refuse to merge until an owner has approved. This keeps the right people in the loop without anyone remembering to ask.
Why it matters
Not every file is equally risky. A change to a button colour is routine. A change to the sign-in code, the payment flow or the pipeline definition could open a hole. Code owners make sure the people who understand the risk see those changes.
It also protects against honest mistakes and bad actors. One compromised developer account cannot slip a change into the pipeline file unnoticed if the file's owners must approve it. It leaves a record of who approved what, which helps in audits.
How it shows up
Put owners on the places where a bad change costs the most: authorisation code, authentication, payment logic, infrastructure and deployment files, and the CODEOWNERS file itself. Name teams instead of individuals, so a holiday does not block a release. Keep the list short enough that the owners read what they approve.
The mistakes repeat. The file is out of date and names people who left. Patterns are too broad, so owners are asked for everything and approve without reading. The approval rule is not enforced in settings, so the file is only a suggestion. In GitHub the last matching pattern wins, so order matters. Test it with a trial change, and see secure code review.
Questions people ask
Code owners, answered
Where does the CODEOWNERS file go?
In GitHub, in the repository root, in a .github folder or in a docs folder. GitLab uses a similar file with its own location rules. Check your platform's documentation. The file is plain text and sits in version control like any other.
Does a CODEOWNERS file block merges by itself?
No. On GitHub you must turn on the setting that requires a review from code owners, as part of a branch protection rule. Without that, it only suggests reviewers. Check that the setting is on, not just the file.
Should owners be people or teams?
Teams are usually better. They avoid blocking on one person's availability and keep working when staff change. Group ownership also spreads knowledge of the sensitive areas, which makes reviews faster over time.
Can an owner approve their own change?
That depends on your settings. Most teams require approval from someone other than the author, so owners cannot approve their own work alone. Check the rule, because the default may allow it.
What should we protect first?
Start with pipeline files, authorisation and authentication code, and payment logic. Those are the places where one wrong change has the biggest effect. Add more paths as you learn where changes carry risk.
Sources
Where this comes from
Related
Terms that sit next to this one
Branch protection
Repository rules that stop unreviewed code reaching the main branch.
Secure code review
Reading code specifically to spot security flaws before they ship.
Pull request security check
Automatic security testing that runs on a code change before it is merged.
Build pipeline compromise
An attacker altering your build system so every release carries their code.
Separation of duties
Splitting a sensitive task so no single person can complete it alone.
Who approves your riskiest code?
Review rules help, but they only cover what reviewers notice. We test the running app and prove what actually breaks, including access flaws no one spotted in review. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.