Run two lanes. Security updates respond to a known advisory for a version you use, so they should move quickly. Version updates keep you current and can be batched, delayed and reviewed on a calmer schedule. One policy for both makes either too slow or too risky.
How the two differ
| Security updates | Version updates | |
|---|---|---|
| Trigger | A published advisory affects a version you use | A newer version exists |
| Urgency | Depends on severity and exposure | Low |
| Delay for new releases | Usually none | Often a few days |
| Grouping | Often separate pull requests | Often grouped |
| Review depth | Targeted: does the fix break us? | Routine |
Documentation for one widely used bot shows this split in practice. Its cooldown setting, which delays proposals for new releases, applies only to version updates and not to security updates. Its security pull requests also have a fixed limit of 10 that is separate from the configurable limit on version updates, which defaults to 5. Without an allow rule, security updates cover vulnerable dependencies found in lockfiles, which means they can reach transitive packages.
Why a delay helps one lane and hurts the other
A short wait after a release gives the community time to notice a broken or malicious version. That is a good trade for routine updates. For a security fix, waiting extends exposure. The fix itself is usually a newly published version, so a blanket delay would hold it back.
Setting up each lane
Version lane:
- Weekly or monthly schedule.
- Group patch and minor updates.
- A cooldown of a few days for new releases.
- Majors in their own pull requests.
Security lane:
- Enable alerts and automated security pull requests.
- No cooldown.
- One advisory per pull request where possible.
- Triage by exploitability and reachability, not severity alone.
- A service level for the response, such as critical and reachable in days, the rest in your normal cycle.
Do not let the lanes merge
The usual failure is an organization that sets a monthly schedule for everything, then finds a critical fix waited three weeks. The opposite failure is treating every advisory as an emergency, which exhausts reviewers and lowers the care they give each one.
Know what the alert does not say
An advisory says a version is affected. It does not say your code reaches the vulnerable function. Check that before you pull the team off other work, and record the decision so an audit can follow it.
Try it yourself
Click through it at your own pace, or open it full screen. Find a finding where a fix version exists and see how the proposed change is scoped to the affected package.
Quick check
Should security updates wait for a cooldown?
Usually not. The cooldown exists to catch bad new releases. For one documented bot it applies only to version updates.
Do security updates cover transitive dependencies?
Documentation for one bot says that without an allow rule, security updates cover vulnerable dependencies in lockfiles. Check your own tool's behavior.
Safeguard scans manifests and lockfiles into an SBOM, uses reachability analysis to show which flagged dependencies your code actually calls, and can open fix pull requests (off by default, every category on Manual). You can try a free scan on a public repository.
Sources
Last reviewed: 19 October 2026.
