Yes. Dependabot's groups have an applies-to setting that targets either version updates or security updates. Putting security fixes in their own group means a vulnerability fix is never bundled with routine bumps, which keeps review focused and makes a rollback cleaner.
Why separate them
A security fix and a routine version bump have different urgency and different questions. The security PR asks "does this close the finding and is it safe?" The routine PR asks "is it worth taking now?" Mixed together, a slow routine update can hold a security fix back, and a risky routine update can force you to revert a fix you wanted to keep.
What the options reference says
GitHub's Dependabot options reference lists the group criteria. The applies-to key specifies which type of update the group covers. When it is undefined, it defaults to version updates. The supported values are version-updates and security-updates. Other criteria in the same block are dependency-type (development or production), patterns and exclude-patterns for package names, update-types for semantic versioning levels, and group-by for grouping across directories.
GitHub's guide to optimising PR creation adds that you configure groups per package ecosystem, and can define several groups per ecosystem. It describes groups as a way to consolidate multiple updates into one PR so reviewers can spend time on higher risk updates.
A simple grouping scheme
| Group | Applies to | Contents | Review style |
|---|---|---|---|
| security-all | security updates | Every vulnerable dependency in the ecosystem | Prompt review by owner, full checks |
| dev-routine | version updates | Development dependencies, minor and patch | Light review, automerge candidate later |
| prod-routine | version updates | Production dependencies, patch only | Normal review, full checks |
| everything else | version updates | Left ungrouped | One PR each, read the notes |
Treat the table as a pattern to adapt, not a prescription. A small repository may need only two groups.
Trade offs to accept
- A grouped security PR is a bigger change. If it fails, you must find which update broke it. See find the guilty update in a grouped fix PR with git bisect.
- Grouping hides detail. One title for many packages can disguise a risky one. Read the list, not just the title. See how to group dependency updates without hiding risk.
- A group changes the unit of revert. If you revert the group you revert every fix in it. That is a reason to keep security groups tight, or to group by ecosystem and severity rather than putting everything together.
Rules that stay true however you group
Security updates have their own limit in Dependabot: GitHub states that security update PRs are subject to a separate fixed limit of 10 open PRs, which cannot be configured with the open-pull-requests-limit option. So grouping does not change how many security PRs can be open at once, but it does change how many you must read.
Pair the grouping with labels so triage is quick, as described in how to name and label dependency update pull requests for triage.
Try it yourself
Open the demo and look at how findings are tracked and prioritised. Think about which of them would sit in a security group of their own.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Does applies-to change how fast security PRs open?
The documentation describes it as selecting which update type a group covers. It is about grouping, not timing.
Should dev dependencies share a group with production ones?
They can, but the dependency-type setting lets you separate them. Separate groups let you review production changes with more care.
Sources
- GitHub Docs: Dependabot options reference
- GitHub Docs: Optimizing the creation of pull requests for Dependabot version updates
Last reviewed: 19 October 2026.
