A bot-opened upgrade pull request should need the same checks as a human one: a build from the lockfile, passing tests, a smoke test, a dependency and policy scan, and a review proportional to risk. Auto-merge is acceptable only for low risk updates with strong tests and a staged rollout behind them.
The core idea
A bot changes who opens the change, not what the change does. A bumped package runs in production the same way whatever opened the pull request. So the controls should depend on the risk of the change, not on the author.
Required checks
| Check | Why |
|---|---|
| Build from the lockfile, in a clean environment | Reproducible result |
| Unit and component tests | Basic regression |
| Smoke test on the built artifact | Catches start-up and wiring failures |
| Dependency and vulnerability scan, compared with the base branch | No new known vulnerabilities introduced |
| Policy checks: licenses, banned packages, minimum release age if you use one | Supply chain rules |
| Lockfile diff size and transitive changes reported in the pull request | Reviewer sees what moved |
Make these required status checks on the protected branch, so a bot cannot bypass them and neither can a human in a hurry.
Review rules by risk
- Low risk, auto-merge allowed: patch updates of development tools, and patch updates of libraries off any trust boundary, with all checks green.
- Medium risk, one reviewer: minor updates of runtime libraries, and any update that adds transitive packages.
- High risk, owner review plus a second reviewer: anything touching authentication, cryptography, parsing, database drivers or HTTP clients, and every major version.
Write this in the repository, and configure the bot's labels or rules to match. Dependabot's configuration documents options such as groups, labels, assignees and a limit on open pull requests, which you can use to apply different treatment to different groups.
Guard against the bot being the weak point
Automated updaters hold credentials and can open pull requests that run in CI. Two things deserve attention:
- Limit the permissions of the bot and of the CI tokens that run on its pull requests. Do not give pull requests from bots access to production secrets.
- Be careful with workflows that run on pull request events with elevated permissions. Treat a bot branch as untrusted code until reviewed.
See Dependabot supply chain security for related risks.
Watch for fast-moving malicious releases
A new version of a package is not automatically trustworthy. Some teams use a cooling-off period before accepting very new releases, and the Dependabot configuration documents a cooldown option for this, so that compromised versions are more likely to be caught and pulled before they reach you. Security fixes are the exception, where speed matters. Decide your rule and apply it in policy.
Measure the program
Track the age of open update pull requests, the share merged without edits, the share that failed checks, and how many were reverted after merge. If reverts are rising, your auto-merge scope is too wide. If open pull requests pile up, your review rules are too heavy or tests too slow.
Safeguard's policies, gates and guardrails can enforce required checks on pull requests, and its fix pull requests are off by default with every category on Manual, so auto-merge scope is something you choose deliberately. Free scan: gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at which findings block a merge and which just warn.
Quick check
Is it safe to auto-merge all patch updates?
Not all. Keep trust boundary packages and anything pre 1.0 on human review, and make sure a staged rollout and rollback exist.
Should bot pull requests skip the smoke test to go faster?
No. The smoke test is what catches wiring failures that unit tests miss. Keep it short instead of skipping it.
Sources
Last reviewed: 19 October 2026.
