Route by what the reader must do. Send a fix pull request when the fix is mechanical, a ticket when work must be scheduled and tracked, a chat message only when someone must act within hours, and a dashboard for everything else. One alert, one primary channel.
Why channel choice matters
An alert in the wrong place is a missed alert. Chat scrolls away. Email is filtered. A ticket nobody triages ages in silence. The same finding can be urgent in one service and irrelevant in another, so the route should depend on the finding and the owner, not on the tool that produced it.
The four channels
| Channel | Best for | Weakness |
|---|---|---|
| Pull request | Version bumps with a known fix and passing tests | Piles up if nobody reviews |
| Ticket | Work that needs scheduling, ownership and a due date | Can become a graveyard |
| Chat message | Time critical items, such as a vulnerability under active exploitation in a reachable path | Noisy, no history |
| Dashboard or digest | Awareness, trends, low severity | Nobody is accountable |
A routing rule set
- Fix available and tests pass: open a pull request to the owning team and label it. See reduce dependency update PR noise.
- No fix available, or the fix is a major upgrade: create a ticket with an owner and a due date.
- Known exploited and reachable in your code: message the owner and the on-call channel, and create a ticket so the work is tracked.
- Low severity or not reachable: weekly digest only. See weekly digest or real-time alerts.
- Anything older than your target: escalate to the owner's lead.
Known exploitation can be checked against the CISA catalog. See check a target's stack against the CISA KEV catalog.
Steps to implement
- Write the rules above in your own terms, with thresholds your team accepts.
- Make sure every repository has an owner field, because routing needs it.
- Start with one team. Measure how many alerts reach each channel for two weeks.
- Adjust. If chat gets more than a handful per day per person, tighten rule 3.
- Add a monthly check that each channel's items are being closed.
Measure the routing
Track time to first action per channel, and the share of items closed within target. If tickets age and pull requests merge quickly, move more items to pull requests. If chat items are ignored, the rule that sends them is too loose.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a new advisory is matched to what you already ship.
Quick check
Should every alert be posted to chat?
No. Reserve chat for time critical items. Everything else belongs in a pull request, ticket or digest.
What if two channels get the same alert?
That is fine for urgent items, as long as one channel is the place where the work is tracked.
Safeguard's reachability analysis helps separate urgent findings from background ones, and fix PRs are available with autonomous remediation, which is off by default. A free scan is at gold.safeguard.sh/scan.
Last reviewed: 19 October 2026.
