A five-engineer team should rotate one named triage owner each week, route every alert to that person, and use a short written rule for what gets fixed, deferred, or dismissed. Keep it to one channel and one queue. The goal is that nobody wonders whether someone else saw it.
The problem at this size
With five engineers, security is everyone's job, which in practice means it is nobody's. Alerts land in a shared channel, each person assumes a teammate looked, and old findings pile up quietly.
You do not need a security hire to fix this. You need an owner, a rule, and a small queue.
Set up in four moves
- Pick a weekly owner. Rotate Monday to Monday. The owner reads every new alert that week and either acts, assigns, or dismisses with a reason.
- Use one queue. One channel or one board, not three. Alerts that arrive anywhere else get forwarded in.
- Write a three line policy. Fix within a short window for known exploited issues and anything reachable in production. Schedule the rest. Dismiss only with a reason and a review date.
- Hold a ten minute handover. The outgoing owner lists what is open, what is blocked, and what was dismissed.
GitHub's documentation notes that users with write access can assign Dependabot alerts to collaborators or teams, which gives each alert a visible owner, and that the alert list can be filtered by assignee. That maps directly onto a rotating owner.
What the owner actually does
| Alert type | Default action | Owner decision |
|---|---|---|
| Listed in CISA's known exploited catalog | Fix now | Pull in a second engineer if needed |
| Reachable in production code | Fix this sprint | Assign to the service's author |
| Dev-only or unreachable | Defer to monthly upgrade | Log reason |
| Looks wrong or duplicate | Dismiss with note | Set review date |
The first row follows CISA's guidance that all organizations review and monitor the Known Exploited Vulnerabilities catalog and prioritize listed items.
Protect the rotation from overload
Rotations fail when the owner is also the on-call and the person with the biggest feature deadline. Put a ceiling on it: if more than a handful of new alerts need real work in one week, the owner may ask the team to pause feature work for half a day. Make that rule explicit before it is needed.
Reduce volume upstream as well. Auto-triage rules apply before notifications are sent, so low-risk alerts can be dismissed on creation. Rules still leave an audit trail, since automatic dismissal activity appears in alert webhooks, APIs, and the audit log.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings move from detected to assigned to resolved.
For a general ranking method, see how to prioritize vulnerabilities. Safeguard can apply policies and reachability analysis to the queue, and its free scan at gold.safeguard.sh/scan gives a starting list.
Quick check
Do we need a ticketing tool for this?
No. A shared board with columns for new, assigned, deferred, and dismissed is enough at five people. Add tooling when the board stops fitting on one screen.
Who should own dismissed alerts?
The owner who dismissed it, until the review date. Then the current weekly owner re-checks it.
Sources
- CISA, Reducing the Significant Risk of Known Exploited Vulnerabilities
- GitHub Docs, About Dependabot alerts
- GitHub Docs, Dependabot auto-triage rules
Last reviewed: 19 October 2026.
