Use push alerts for the small set of findings that need action within hours, such as confirmed exploitation in something you run. Use pull views, like a dashboard or weekly digest, for everything else. Push buys speed at the cost of attention, and pull buys calm at the cost of delay.
Definitions
A push alert is delivered to a person or channel when an event happens: an email, a chat message, a page, a webhook. A pull view is a place someone visits on their own schedule: a dashboard, a report, a queue.
Neither is better. The question is which cost you can afford for each class of finding.
What each mode is good at
| Push | Pull | |
|---|---|---|
| Speed | Fast, in minutes | As fast as the next visit |
| Attention cost | High, interrupts work | Low, reader chooses the time |
| Risk | Fatigue, muted channels | Never looked at |
| Fits | Exploited, reachable, owned | Backlog, trends, low severity |
GitHub's own settings show the same split. Its Dependabot alerts documentation says you can pick which notification types you get, turn them off, or opt for a weekly email digest. The alerts themselves also sit in a view on the repository for anyone who goes looking.
A simple rule for choosing
Ask three questions about a finding.
- Is there evidence of exploitation, such as an entry in the CISA KEV catalog?
- Does it affect something deployed and reachable?
- Is there a named owner who can act today?
If all three are yes, push. If one or two are yes, put it in a ticket queue the owner reads daily. If none, let it appear in a weekly digest. The point is to reserve interruptions for cases where waiting costs more than the interruption.
Failure modes to design against
Pure push fails quietly when people mute the channel. Pure pull fails quietly when nobody opens the dashboard. Fix both with a small amount of structure.
- Give every push alert an owner and an expected response time.
- Review the push channel monthly and retire alert types that never led to action.
- Put a standing item in a weekly meeting to read the pull view out loud.
- Alert on the monitor itself, so a stopped scan does not look like a quiet week.
Where Safeguard fits
Safeguard's policies and gates can block a pull request that introduces a serious finding, which is a push moment tied to the author. Findings that need triage collect in a view you can review on a schedule. A free scan shows how results are laid out.
See also an alert nobody acts on is not a control.
Quick check
Is a weekly digest too slow for critical issues?
Yes, for exploited and reachable ones. Keep a push path for those, and use the digest for the rest.
Should every severity page someone?
No. Paging on every finding teaches people to ignore pages. Reserve it for a narrow, defined class.
Sources
Last reviewed: 19 October 2026.
