Notify the pull request author first, because they can fix it. Notify code owners only when the finding touches files they own and needs their judgement. Alert the security team only for a small set of critical or policy exception cases. Everyone else should find the result on the page, not in their inbox.
Why routing is a noise problem
Every mention is an email, a push alert or a badge. A bot that tags a team on each finding turns a shared channel into a feed that people mute. Muting is permanent, and a muted channel misses the one finding that mattered.
GitHub's own guidance on review comments is a useful model. Batching comments into one submitted review sends one notification instead of one per comment, and anyone watching the pull request is notified of comments either way. Design with the knowledge that watchers already get everything.
A routing table
| Audience | Gets notified when | Through |
|---|---|---|
| Author | Any finding on their change | The pull request itself |
| Code owner | Finding in owned files that needs a decision | Review request |
| Security team | Critical reachable finding, exception request, repeated bypass | Dedicated channel |
| Manager or lead | Weekly digest of open items | Report, not alerts |
Use ownership data you already have
CODEOWNERS maps paths to owners, and GitHub requests owners for review automatically when a pull request changes files they own. The last matching pattern wins, and owners need write access. Reuse that mapping for findings in sensitive paths, such as authentication code or workflow files, instead of building a second ownership list that drifts.
If a file has no owner, say so in the weekly report. Unowned code with findings is a more important signal than a single comment.
Escalate by rule, not by mood
Define escalation conditions in advance and write them down. For example: a critical, reachable finding in a service that handles customer data; a policy exception requested for the third time in a month; a gate bypassed with no recorded reason. Rules like these keep escalation rare and predictable.
Avoid tagging individuals in bot comments
A mention of a named person puts social pressure on a conversation that should be about code. Prefer team handles for ownership, and only where the owner is needed for a decision. Remember that people change roles, so a handle that was right last quarter may be wrong now.
Digest the rest
Findings that need awareness and not action can go into a weekly digest per team: counts, oldest open item, and fixes merged. A digest is read once and does not interrupt, which is exactly the property you want for low urgency information.
Safeguard asset discovery and policy features can help map findings to services and owners. Try a free scan to see findings you could route.
Quick check
Should the security team be on every pull request?
No. Add them for defined triggers, such as changes to authentication code, not as a default reviewer on everything.
What about findings in files with no owner?
Report them in a digest and assign an owner. Do not default them to the security team, which then becomes the owner of everything.
Sources
Last reviewed: 19 October 2026.
