ASPM routes findings by looking up who owns the affected repository, path or service, using sources such as code owners files, a service catalog or a manual mapping. The routing is only as accurate as that ownership data, so fixing the data matters more than the tool.
What routing does
Routing turns a finding into a task for a named team. It answers "who should look at this first?" Without it, findings collect in a central queue where security staff become the default fixers for code they did not write.
Where ownership data comes from
| Source | How it works | Weakness |
|---|---|---|
| Code owners file | A file in the repository lists people or teams per path | Goes stale after reorganizations |
| Service catalog | A central list of services and teams | Needs someone to maintain it |
| Source control team settings | Repository access by team | Access is not the same as ownership |
| Commit history | Most frequent recent committers | Fails for quiet or abandoned code |
| Manual map | A spreadsheet or config | Easy to start, easy to forget |
Most organizations end up with a blend. The order of preference matters: an explicit declaration from the owners beats an inference from history.
Common routing failures
- The orphan. A repository with no owner. Findings pile up.
- The shared library. Used by many teams, owned by none. Decide on an owning team, even if informal.
- The departed owner. The named person left. Route to the team, not the individual.
- The wrong layer. A vulnerable base image belongs to a platform team, but the finding shows up in each application repository.
A fix cycle you can run monthly
- List findings with no owner, and sort by repository.
- For each repository, ask the most recent contributors who should own it.
- Add or update the code owners file, and link it from the platform.
- List repositories with no commits for a long period and propose archiving.
- Recheck unowned count. It should fall each month.
Handling the shared dependency problem
For a base image or common library, route the root cause to the team that maintains it, and let consuming teams see a read only reference. This avoids ten teams opening ten tickets for one fix. It also pairs well with deduplication, since the same flaw appears once and links to the places it matters.
Rules for escalation
Decide in advance what happens when a team does not respond. A simple rule is that unacknowledged high priority items go to the team's lead after a set number of days, and then to the engineering director. Write the rule down so it does not feel personal.
Measuring it
Track the share of open findings with an owner, and the median time from detection to acknowledgment. If the second number is large, routing may be correct but the notification channel is not being watched.
A worked example: one finding, three possible routes
A vulnerable library is found in a repository called payments-service. Three sources disagree.
| Source | Says owner is | Reliability |
|---|---|---|
| Code owners file | Payments team | High, edited last month |
| Source control access | Platform team (they have admin rights) | Low, access is not ownership |
| Commit history | An individual who left the company | Stale |
The routing rule should choose the code owners file, and ignore the other two. Writing the rule down, in order of trust, prevents arguments later: "Declared ownership first, then the service catalog, then a manual map. Commit history is a hint, not an owner."
Step by step: building a routing policy
- List the ownership sources you have and rank them by how often they are correct.
- Write the order of precedence in one paragraph.
- Decide what happens when no source gives an answer. Routing to an unassigned queue with a visible count works well.
- Name who triages the unassigned queue and how often.
- Test the policy on twenty findings and note the misroutes.
- Fix the data behind each misroute rather than adding special cases.
Notification channels
Routing can still fail if the team never sees the message. Choose channels that people actually watch. Options include a team channel, a ticket in the team's board or an email list. Avoid personal direct messages as the main channel because people go on leave. Test it by sending a low severity message and checking the response time.
Handling cross team issues
Some findings involve more than one team: a base image used by many services, or a shared library. Create a parent item for the root cause, owned by the maintaining team, and link child items for consumers. Consumers watch the parent and apply the update when it ships. This avoids duplicate work and duplicate noise.
What to report
Show leadership the percentage of findings with an owner, the median time to acknowledgment and the count of items in the unassigned queue. If the unassigned count is not shrinking, the problem is ownership data, not the platform.
Where Safeguard fits
Safeguard provides asset discovery and policies, gates and guardrails. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look for where an owner is shown next to each issue.
Quick check
Should findings go to a person or a team?
A team. People change roles, and a team name survives that.
What if two teams both claim a repository?
Name one primary owner and list the other as a contact. Dual ownership usually means no ownership.
Should security be the fallback owner for unowned code?
Only briefly. Security can triage and find a real owner, but making security the permanent owner means developers never take responsibility for code they ship.
Last reviewed: 19 October 2026.
