A rotating fix duty suits teams with modest, steady volume and strong ownership. A dedicated squad suits large backlogs, many services or shared platform code. Many leaders end up with a hybrid: a small core team plus a weekly rotation in each product group. Pick based on volume and code ownership.
The two models
Rotation. Each week one engineer per team takes the vulnerability queue. They triage, fix what they can, and hand off the rest. The load is shared, and every team keeps contact with its own dependencies.
Dedicated squad. A small group owns remediation across services. They build tooling, work the backlog, and handle cross-cutting upgrades.
Comparison
| Factor | Rotation | Dedicated squad |
|---|---|---|
| Code familiarity | High, engineers know their own service | Lower, squad must learn each codebase |
| Consistency | Varies by team | Uniform process |
| Disruption to roadmap | Spread thin, regular | Concentrated in one group |
| Tooling investment | Rarely gets time | Natural fit for the squad |
| Knowledge spread | Wide | Risk of a few experts |
| Fit for shared libraries | Weak | Strong |
| Ownership signal | Teams own their risk | Teams may assume the squad handles it |
Where rotation breaks down
Rotation fails when the rotating engineer has no authority or time. If the person on duty is also carrying a full feature load, the queue loses. Protect rotation time explicitly, and rotate often enough that nobody burns out.
It also struggles with cross-team dependencies. When a vulnerable library lives in a shared package, no single team owns the fix.
Where a squad breaks down
A squad can become a dumping ground. Teams stop caring about their dependencies because someone else handles them, and the squad turns into a ticket queue with no ability to change habits. Google's SRE guidance on toil warns that operational work expands to fill whatever time exists. Without a goal to automate, a squad can drift into permanent manual work.
The hybrid
- A small core team owns tooling, policy, shared libraries and the hardest upgrades.
- Each product team runs a short weekly rotation for its own routine fixes.
- The core team reports throughput and aging per team, so ownership stays visible.
- The core team sets a standing goal to automate any fix class that repeats.
This gives familiarity where it matters and consistency where it helps. Review the split every quarter.
How to choose, in order
- Count your services and how many have clear owners.
- Look at the share of backlog that sits in shared code. A high share points toward a squad.
- Check whether your teams have real slack. If not, a rotation will not hold.
- Start small and measure throughput before committing headcount.
Where Safeguard fits
Safeguard assigns findings to owners and tracks aging per team, which helps either model show who is clearing what. Autonomous fix pull requests are off by default and can take routine bumps off a rotation if you enable them. A related read is appsec team roles and staffing models compared.
Quick check
Can a very small company use a dedicated squad?
Usually not. With few engineers, a light rotation plus automation for routine fixes is more realistic.
How do I stop a squad becoming a ticket queue?
Give it an automation goal and report ownership per team, so teams stay accountable for their own dependencies.
Sources
Last reviewed: 19 October 2026.
