How to route a finding when CODEOWNERS is incomplete

When a security finding or unresolved candidate has no usable CODEOWNERS match, assign a temporary decision owner first, then find the team that can inspect and, if needed, change the affected behavior. Route a verified, approved finding to a fixing team with a specific action and acceptance criterion; route an uncertain claim to an evidence owner for investigation. The temporary owner keeps either record from disappearing while checking repository ownership, runtime ownership, and access to the evidence. If ownership remains disputed, have the engineering manager choose an accountable coordinator and a decision date; do not copy a sensitive report to every possible team.

CODEOWNERS is useful for review requests, but it is not a complete service directory. GitHub uses its CODEOWNERS file to request reviews for matching changed files. Its rules depend on file location, the base branch, pattern order, syntax and owner permissions. A missing or invalid match tells you about review automation; it does not prove nobody owns the deployed service.

Worked scenario: shared code, separate deployer

Illustrative system: Alder Commerce has a checkout-api repository. At pinned revision 7e4c2a, a security alert proposes that an export endpoint could return another account's order summary. The reviewer sees no account check in the selected-record lookup, but has not inspected the final link service or established whether it applies a downstream check. The claim remains an investigation, with an evidence task for a developer who knows the path; no production exploit is implied. The route lives under /src/exports/, which receives no owner from the effective CODEOWNERS file. A shared /src/auth/ directory is owned by Platform, while the Checkout team builds and deploys the API. The last contributor to the route has moved teams.

A simple “assign it to whoever changed the file” would send the investigation to someone who may lack deployment control or context. Assigning Platform because the word “auth” appears in the alert would confuse a dependency with ownership. The manager makes this short routing record:

The investigation's technical record stays in a restricted location. The manager sends a need-to-know summary to Checkout and asks Platform for a narrow check of the helper. The evidence check is not delayed until the CODEOWNERS file is repaired.

Reproduce the missing match on paper

Alder's PR targets release/october. The manager first looks at main and sees Checkout listed. That is the wrong branch for this routing question. The following fictional .github/CODEOWNERS file is present on the actual base branch:

*                       @alder/platform
/src/exports/           @alder/checkout
/src/auth/              @alder/platform
/src/exports/

The changed file is src/exports/download.ts. The broad rule matches, then the Checkout rule matches, then the last line matches with no owner. The final line leaves this path without a code owner. A default Platform rule does not rescue it after that later match. This is an ownership-rule failure, not evidence that Checkout stopped operating the service.

GitHub's CODEOWNERS documentation establishes the base-branch, last-match and empty-owner behavior. It also documents that .github/CODEOWNERS takes precedence over root and docs/ locations. In this example, editing a root file while the .github file remains active would repair nothing.

The proposed file removes the unintended empty override and gives ownership of the configuration itself to repository administrators:

*                       @alder/platform
/src/exports/           @alder/checkout
/src/auth/              @alder/platform
/.github/CODEOWNERS     @alder/repository-admins

The team must be visible and have explicit repository write access to receive assignment; individual members' permissions do not establish that team permission. A real repair therefore checks the effective base-branch file, syntax diagnostics and team access, then inspects a representative ready-for-review PR changing the export path. GitHub does not automatically request code owners on draft PRs. The desired evidence is the actual review request to Checkout after the repaired base configuration is effective, not just a syntactically attractive file. A correct review request does not by itself prevent merge. If owner approval is required by policy, separately check the applicable branch protection or ruleset. GitHub's documentation distinguishes automatic requests from required code-owner reviews; when several owners share a pattern, one owner's approval can satisfy that requirement. No repository rule was changed for this article.

Route the security question before repairing automation

The service catalogue and deployed API manifest identify Checkout as operator, so the manager does not wait for the CODEOWNERS change. The accepted handoff is:

Coordinator: Checkout engineering manager. State: investigation at 7e4c2a; no approved repair yet. Accepted evidence action: Checkout API lead will trace exportId through the deployed handler and provide the mandatory final link call. Consulted: Platform explains what the shared auth helper checks. Missing owner: final link service; manager retains that lookup with a Friday deadline. Next decision: security reviewer determines whether the completed path supports an issue, defeats it or remains inconclusive.

Checkout replies that it can supply the caller but does not maintain the link service. That is a valid boundary, not a rejection of all responsibility. The manager keeps coordination and asks the release authority for the downstream service contact. In the exercise, the service registry identifies Documents; its lead accepts the narrower task of supplying the signing function, account rule and effective service revision. Checkout does not need permission to browse every Documents finding to ask that interface question.

When the artifact arrives, assume it shows a compulsory account check against the selected export before signing the stored object. The reviewer traces the actual caller through that check and rejects the specific missing-authorization claim. The CODEOWNERS repair still proceeds because the routing defect was real. If the artifact instead showed a gap, the implementation owner would be chosen from the enforceable repair boundary, not automatically from whichever team appeared first in CODEOWNERS.

The two completion records remain separate: “investigation rejected with downstream control evidence” and “export review requests now route to Checkout after representative PR check.” Fixing the latter would not have proved the former. This distinction is what keeps ownership cleanup from becoming a substitute for technical review.

When no owner can be established

If the service catalogue is stale, the deploy manifest is unclear and on-call teams disagree, keep the manager as decision owner and time-box an ownership investigation. Identify who controls the deployment credentials or approves releases, then ask that person to identify the current maintainer. For a high-impact verified issue or credible suspected exposure, arrange temporary mitigation or a release decision with the responsible security and engineering leaders while ownership is resolved. Do not mark the record “accepted risk” solely because nobody has claimed it.

If the route was removed, confirm at a new revision that no alternate entry reaches the questioned operation before closing an investigation or treating a confirmed issue as fixed. If a different team now deploys it, preserve the original routing history and reassign the work with a reason; avoid a second ticket that loses the first decision trail.

Distinguish a routed request from an accepted handoff

A request sent to a team is only the start of routing. In the Checkout exercise, the Documents lead may agree that the final signer belongs to their service but explain that the suspected behavior is governed by the shared account contract. That response helps locate the decision; it does not transfer the entire investigation automatically to Platform.

Use a short handoff trace for the constructed case:

This trace avoids two common mistakes. The first is assigning every role to the team that owns the last file in the stack. The second is splitting the ticket so aggressively that nobody checks whether the caller's account context still identifies the object ultimately signed. Local ownership answers where work happens; the coordinator preserves the end-to-end question.

If Documents cannot respond within the required window, the manager selects an available escalation owner and states which decision is waiting. “Need current signer contract before deciding whether Checkout bypasses account authorization” is actionable. “Security needs ownership” is too vague to schedule. The developer can meanwhile provide the caller inventory or identify the relevant revision, provided that work does not depend on guessing the missing service contract.

Repair the ownership map after the immediate decision

An incomplete ownership file is useful feedback about the system's maintenance process. Once the case is routed, ask why the relevant boundary was absent. The service may have moved repositories, the team may have changed, or a generated output may have no clear maintainer even though its generator does. Update the smallest durable source that future routing will actually consult. That may be the repository's ownership configuration, a service catalog, or both; avoid creating a new spreadsheet that nobody maintains.

Record who accepts maintenance of the mapping and what causes it to be reviewed. A directory move should bring the ownership implication into the change review. A team reorganization should trigger confirmation that the replacement team can receive and act on requests. These are operating conventions the organization chooses, separate from the platform's exact review-request behavior.

Do not use the mapping repair as a substitute for resolving the original technical question. In the example, downstream account enforcement may reject the suspected vulnerability even though CODEOWNERS remains incomplete. Conversely, a perfectly routed review can still identify a real defect. Track the routing improvement and technical outcome separately so an administrative cleanup cannot close an open exposure, and a rejected claim cannot hide a recurring ownership problem.

The final record should let the next reviewer answer three practical questions quickly: who can explain this boundary, who can change it, and who will coordinate when the change spans both services. That is a stronger result than merely adding another team name to a file.

For the next unowned finding or candidate, start with the routing record above. To improve the quality of the developer handoff after approval, use how to hand a security finding to the right code owner. When several tools have opened tickets for the same path, continue with how to prevent duplicate security tickets across tools.