In the documentation of two widely used update bots, no: security fix pull requests are handled separately from the cap on version updates. One has its own fixed limit for security pull requests. The other creates them even when the cap is reached. Confirm this for your own tool and test it.
Why the question matters
Teams cap open update pull requests to protect reviewers, as covered in our post on how many open update pull requests to allow. A cap of three feels sensible. But if three old version bumps sit open and the cap also applied to security fixes, an advisory fix would wait behind routine work. You would have a quiet dashboard and a known vulnerable dependency.
What the documentation says
The first bot says its version update limit defaults to five open pull requests, and that security update pull requests are subject to a separate, fixed limit of ten that cannot be changed with the version update setting. The same page says a very large number removes the version update limit.
The second bot says it always creates security pull requests even if its concurrent limit is already reached. Its default configuration for vulnerability pull requests also sets the concurrency limit to zero, which in that tool means no limit, and applies the security tag to the title so they are easy to find. It can read vulnerability data from the code host's alerts, which must be enabled, and has an experimental option for an open vulnerability database that covers direct dependencies only.
| Question | Check in your tool |
|---|---|
| Is there a separate limit for security pull requests? | Read the options reference |
| Can that limit be changed? | One documented limit is fixed |
| Are security pull requests labeled? | Needed for triage and reporting |
| Which dependencies get security coverage? | Direct only, or transitive too |
| What data source triggers them? | Platform alerts or another database |
Settings that quietly hold fixes back
Even with separate limits, other settings can delay a security pull request:
- A cooldown or minimum release age. One bot's documentation says its cooldown applies only to version updates, not security updates. Another has a vulnerability alert block that sets its minimum release age to null by default. Confirm yours does not delay fixes.
- A schedule. The default vulnerability configuration in the second bot has an empty schedule, so fixes are not restricted to your weekly window. Your own override may change that.
- Approval requirements. The vulnerability defaults do not require dashboard approval, but a broad rule might.
- A grouping rule that bundles the fix into a larger pull request that is failing.
A simple test
Pick a known vulnerable dependency in a test repository, with the open cap set to one and one routine pull request already open. See whether the security pull request appears and how it is titled. Record the result next to your configuration so the next engineer does not repeat the experiment.
Quick check
Is a fix pull request still blocked if I disable the open limit?
Disabling the version limit removes one barrier, but schedules, approval rules and grouping can still delay a fix.
Do these tools fix indirect dependencies?
Coverage differs. One documented open database option covers direct dependencies only, so check how your tool treats transitive packages.
Safeguard applies policies and gates to dependency risk, builds an SBOM from manifests and lockfiles, and uses reachability analysis to separate vulnerable packages your code calls from those it does not. Fix pull requests are off by default, with every category on Manual. Try a free scan.
Sources
- Code host documentation: update bot options reference
- Update bot documentation: configuration options, concurrent limit and vulnerability alerts
Last reviewed: 19 October 2026.
