Batch routine, low-risk fixes such as patch bumps in the same ecosystem, and ship urgent or risky fixes alone. Batching cuts review and CI time per fix. A separate pull request keeps a hard fix from blocking easy ones and makes rollback simple. Your capacity depends on getting this split right.
Why batching changes capacity
Every pull request carries fixed costs: someone reads it, CI runs, a release goes out. If you open one pull request per advisory, those costs repeat for every finding. For a team with a backlog of small bumps, review time becomes the limit long before engineering time does.
Update tools recognise this. Dependabot's configuration includes a groups option that combines matching dependency updates into fewer, targeted pull requests, and without it opens a single pull request for each dependency. Dependabot also applies a separate limit of 10 open security update pull requests, which cannot be changed through the open pull request limit setting. That is worth knowing if you see security updates stop appearing.
A decision table
| Situation | Batch or separate | Why |
|---|---|---|
| Patch bumps, same ecosystem, tests strong | Batch | Low risk, review cost dominates |
| Minor bumps with changelogs worth reading | Small batch | Reviewer can still hold the diff in their head |
| Major upgrade | Separate | Needs its own testing and rollback |
| Fix for a finding being exploited now | Separate | Speed and clean rollback matter most |
| Fix touching a different service owner | Separate | Different reviewer and release train |
| Transitive override or fork | Separate | Unusual change, needs context in the description |
Rules that keep batches safe
- Group by risk, not by date. A batch of all patch bumps is predictable. A batch of whatever arrived this week is not.
- Cap batch size. If a failing test could be any of twenty changes, you lose the saving when you bisect.
- Keep urgent fixes out of scheduled batches. An emergency should never wait for the Thursday group.
- Name the contents in the pull request title so a reviewer knows what class of change they are approving.
- Make revert cheap. One batch should revert in one step.
How to find your own group size
Start with a small group, say patch bumps for one service. Watch two numbers: how often the batch fails CI, and how long review takes. If failures stay rare, widen the group. If bisecting becomes common, narrow it. Your own failure rate is a better guide than any rule of thumb.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at which findings already have a fixed version available. Those are your candidates for a routine batch.
Where Safeguard fits
Safeguard can open fix pull requests for findings with a fixed version. Autonomous remediation is off by default and every category starts on Manual, so you decide which classes may open pull requests and who reviews them. For wider context see automated dependency updates and patch management.
Quick check
Does batching make rollback harder?
It can, if the batch is large or mixed. Small batches of one change class revert in one step and are usually safe to roll back together.
Should security fixes ever wait for a batch window?
Routine ones can. A fix for something under active exploitation should ship on its own as soon as it is tested.
Sources
Last reviewed: 19 October 2026.
