Send a new finding to the author of the change that introduced it, and send an existing finding to the owner of the service or repository. Authors fix what they just wrote fastest. Owners decide what to schedule. Mixing the two is a main reason alerts go unread.
Why routing matters more than volume
Developers will read ten alerts addressed to them before they read three posted in a shared channel. Attention follows ownership. A finding with no addressee is a finding with a long life.
Dependabot is an example of how defaults shape this. GitHub documents that, by default, alert emails go to people who have write, maintain or admin permission and who are watching the repository with security alerts enabled. That is a repository level default, not a person level one, so a team still has to decide who acts.
The two lanes
| Lane | Trigger | Recipient | Expected action |
|---|---|---|---|
| New finding | A pull request adds or changes code or a dependency | PR author | Fix or request a dated exception before merge |
| Existing finding | Scheduled scan or new advisory on old code | Service owner | Ticket, owner, due date |
Keep these lanes separate in the tool, in reports and in the metrics. A team that mixes them cannot tell whether the process is working or whether it is only inheriting history.
How to find the owner
Use the first source that exists, in this order.
- A code owners file path match for the affected file.
- A service catalog entry for the repository.
- The team that merged the most recent change to that path.
- A named fallback: the engineering manager for the area.
Never let the last step be "the security team." They can advise, but they cannot fix the code.
Edge cases
Bot pull requests. If an update bot opened the change, the author is a bot. Route to the code owners of the files it touched. See CODEOWNERS for bot opened pull requests.
Shared libraries. A finding in a shared library has many consumers. Route the fix to the library team and notify consumers once, with the version that contains the fix.
Contractors and departed staff. Routing to a person who left is the same as routing to nobody. Re-check ownership data on a schedule.
Monorepos. Use path based ownership so one noisy directory does not drown every team. More in CODEOWNERS for a monorepo.
What to measure
- Share of findings with a named owner. Aim to raise it every month.
- Time from finding to first human action, split by lane.
- Number of findings reassigned. A high count means ownership data is wrong.
Do not publish a leaderboard of authors. The point is to get the right person the right alert, not to rank people.
Putting it into practice
Start with one repository. Turn on pull request checks for new findings, set up a weekly owner report for existing ones, and compare action times after a month. Expand only after the lanes feel quiet.
Safeguard supports policies and gates on pull requests plus asset discovery, so new findings can be evaluated at the change and existing risk can be tied to the repositories and services it lives in. The free scan at gold.safeguard.sh/scan is a starting point.
Quick check
What if the author already left the team?
Route to the current code owners of the path. The author lane only applies while the pull request is open.
Should the security team triage everything first?
Only as a temporary step while rules are being tuned. Long term, owners should triage their own findings, with security setting the policy.
Sources
Last reviewed: 19 October 2026.
