Draft ownership from commit history, assign one team per top level directory, put the file where GitHub reads it, and have each team confirm its lines. Remember that the last matching pattern wins. A rough but reviewed file beats none, because every scanner finding needs somewhere to go.
Why this comes up at onboarding
The first scan of a legacy monorepo produces findings in directories nobody claims. Without an owner, tickets sit in a general queue and age. Ownership is the cheapest fix, and CODEOWNERS is a file many teams already use for reviews.
What the file does
GitHub's documentation says CODEOWNERS can sit in the .github directory, the repository root or the docs directory, and that if several exist it searches in that order and uses the first it finds. Each file assigns owners for a single branch. It also says order matters: the last matching pattern takes precedence. When an administrator enables required reviews, a code owner approval can also be required before merge.
Steps for a first draft
- List top level directories and, for each, the authors of the most recent commits, as a hint and not a verdict. Authors move teams.
- Map each directory to a team name, not a person. People leave; teams persist.
- Write a catch-all line first, then specific paths below it, since later lines override earlier ones.
- Send each team their lines for confirmation. Give them a week, and treat silence as a prompt to ask a manager.
- Commit the file on the default branch.
A small example:
# Fallback owner for anything unclaimed
* @example-org/platform
/services/billing/ @example-org/payments
/services/search/ @example-org/search
/libs/shared-money/ @example-org/payments
Because the catch-all comes first, the specific lines after it win for their paths.
Pitfalls
| Pitfall | Effect |
|---|---|
| Catch-all placed last | It overrides every specific rule |
| Owner is a person who left | Review requests go nowhere |
| Team does not have write access | Ownership is ignored for review purposes |
| Directory renamed, line not updated | Files silently fall to the fallback |
Reconcile with findings
After the file exists, take the first scan results and check how many findings land on the fallback owner. A large share means the file is incomplete. Use that number as a progress measure, and drive it down in the first weeks.
Do not turn on required code owner approval at the same moment. Adding that rule while the file is still rough can block merges for the wrong reasons. Start with owners for routing, and add required approval after the file has settled.
Keep it alive
Add a quarterly review, and a check that fails when a path in CODEOWNERS no longer exists. Ownership files rot quietly unless something nags.
Where Safeguard fits
Safeguard tracks findings with owners and status, and autonomous remediation fix PRs, which are off by default, still go through your normal review. A free scan at https://gold.safeguard.sh/scan can seed the first list of affected directories.
Quick check
Is CODEOWNERS the same as a security owner list?
No. It is a review file. It is a convenient starting point for routing, but security ownership may also need an on call contact.
Can one directory have two owners?
Yes, a pattern can list several owners. Keep it to two at most, or nobody feels responsible.
Sources
Last reviewed: 19 October 2026.
