Automated fix pull requests from SCA: what good looks like

A safe automated fix pull request changes the smallest thing that resolves the finding, explains why, runs your tests, and waits for a human to merge. Look for control over which categories of fix are automatic, and begin with all of them set to manual review.

What a good fix PR contains

• The package and the exact version change, with the reason
• The advisory it addresses
• Whether the change is a patch, minor, or major version
• The dependency path, so reviewers see why the package is there
• Results from your existing tests in CI

If the description is only "update dependency", reviewers will rubber stamp it or ignore it.

Smallest change first

Often a vulnerable package is indirect. The fix may be to update the parent package, or to override the indirect version. Ask the tool which it proposes and why. A broad update that touches thirty packages is hard to review and easy to break.

Controls to demand

• Off by default. Nothing should open pull requests until you enable it.
• Per category settings. For example, patch updates for dev dependencies could differ from major updates for runtime libraries.
• Manual approval. The tool opens the pull request. You merge it.
• Scope limits. Choose repositories and branches.
• Rate limits. Prevent a flood of pull requests on day one.
• An audit trail. Who enabled what, when.

A staged rollout

1. Enable on one low risk repository with every category on manual.
2. Review the first ten pull requests. Count the ones you would have merged as is.
3. Expand to more repositories.
4. Consider auto merge only for narrow, well tested cases, if at all.

What to do when no fix exists

Sometimes there is no patched version. A good tool says so, and offers options: a workaround, a different package, or a policy exception with an expiry date. It should not invent a fix.

How to judge quality in a pilot

Take five findings and compare the tool's proposed change to what an engineer would do by hand. Count tests passed, lines changed, and time to review. See the 30 day pilot plan.

Fixes in context

Fix pull requests work best after you have cut noise. Fixing unreachable findings first wastes review time. See how to test reachability claims.

Safeguard offers autonomous remediation with fix pull requests. It is off by default, and every category starts on Manual. The free scan at https://gold.safeguard.sh/scan shows findings first.

Click through it at your own pace, or open it full screen.

Reviewing a fix pull request

A reviewer should ask four things. Does the version change match the advisory? Did tests run, and did they pass? Is anything else changed, such as a lockfile reshuffle that touches unrelated packages? And does the release note of the new version mention breaking changes? Reviews that take two minutes on patch updates and ten on major ones are normal. Track review time, because it shows whether the tool is helping or just moving work around.

Quick check

Last reviewed: 19 October 2026.