Map each dependency finding to the repository path where the manifest lives, then map that path to a team with a CODEOWNERS file or a service catalog. Add a named fallback owner for code nobody claims. Review the map whenever a service is extracted.
Why ownership is the hard part
A scan tells you what is vulnerable. It does not tell you who fixes it. In a monolith modernization, ownership blurs fast. Modules were written by people who moved teams, and new services inherit code from several old owners. Findings without owners sit open until an audit forces attention.
Sources of ownership data
GitHub documents the CODEOWNERS file as a way to define individuals or teams responsible for code in a repository. Owners are requested for review automatically when a pull request touches code they own, and required reviews can be set to need code owner approval. That gives you a machine readable map at path level.
Other sources help fill gaps:
- A service catalog or internal wiki that lists the on call team per service
- Deployment records showing who ships each artifact
- Commit history for the manifest file, as a last resort
A four step method
- List every manifest. pom.xml, build.gradle, package.json, requirements files, and lockfiles, with paths.
- Assign each path an owner. Prefer team names over people, because people leave.
- Define a fallback. One team, usually platform or security engineering, owns anything unassigned and is accountable for finding a real owner or removing the code.
- Attach the map to your findings. Each alert should carry the owner, the service, and the due date set by your policy.
What good looks like
| Item | Good sign |
|---|---|
| Every manifest has an owner | Zero findings in the unassigned bucket for more than one sprint |
| Owners are teams | Reorgs update one file, not hundreds |
| Fallback is explicit | Orphaned code gets a decision, not silence |
| Map is in version control | Changes are reviewed |
Handling shared and extracted code
When a service is carved out, update the map in the same pull request that creates the new repository. It is easy to forget, and the new repository then starts life with no owner. Add a check that fails if a new manifest has no matching owner rule.
For code that stays in the monolith but is being replaced, the owner is the team doing the replacement, not the original authors. They know the dependencies best because they are reading the code anyway.
Related reading: how to build an alert ownership map and CODEOWNERS for a monorepo.
Safeguard's asset discovery and dependency scanning give you the inventory side of this, and its policies let you route and gate by repository. Pair that with your own owner map for the accountability side.
Quick check
What if no team will claim a module?
Assign the fallback owner and set a date to either find an owner or delete the module.
Do I need a CODEOWNERS file?
It is not required, but it is a simple way to keep ownership in version control next to the code.
Sources
Last reviewed: 19 October 2026.
