Not automatically. A fixed version removes a known vulnerability, but it can also change behavior, add dependencies or break builds. Before merging, check how big the version jump is, read the changelog, run your tests, compare the dependency tree, and keep a rollback ready.
Why "fix available" is only the start
Scanners flag a finding as fixable when a later version without the flaw exists. That tells you a path exists. It does not tell you the path is short, safe for your code, or free of new risk. Vulnerability management treats a fix as a change, and changes need checks, which is the confirming part of what NIST describes as identifying, ranking, obtaining, deploying and confirming.
Six checks before you merge
1. Size of the version jump. A patch release usually carries less risk than a minor one, and a major one deserves a plan. Semantic versioning is a convention, not a guarantee, so treat it as a hint.
2. Changelog and release notes. Look for removed features, changed defaults and notes on the security fix itself. If there are none, that is worth noting.
3. Your tests. Run the full suite and any integration tests that exercise the package. A fix with no passing tests is not verified.
4. The dependency tree. Compare before and after. New transitive dependencies are new supply chain exposure. A diff of the lockfile shows them.
5. Reachability. Does your code call the vulnerable function? If not, the upgrade is lower urgency, and you can schedule it with normal updates unless the flaw is on the KEV list.
6. Rollback. Know how to revert, and confirm your deploy process can do it quickly.
Choosing between upgrade, mitigate and accept
| Situation | Reasonable action |
|---|---|
| Patch release, tests pass, reachable | Merge and deploy soon |
| Major version jump, reachable, KEV listed | Plan the upgrade as urgent work; apply a mitigation meanwhile |
| Major jump, not reachable | Schedule; record an exception with an expiry date |
| No fix available | Mitigate or replace; monitor |
Automating the safe part
Automated fix pull requests save time when they are treated like any other contribution. Keep them small, one component per pull request where possible, require the same review and tests, and leave automatic merging off until you trust your test coverage. Group low risk patch updates together to reduce noise.
After the merge
Rescan the new build. Confirm the finding closed and that no new findings appeared in the new dependency set. Close the ticket only when the scan agrees.
A worked example
A scanner flags a vulnerable HTTP client library at version 2.4. The fixed version is 2.6. Walk through the checks.
- Jump size. Two minor versions. Probably moderate risk, so continue.
- Changelog. Version 2.5 deprecates a configuration option that the service uses. Version 2.6 contains the security fix. The deprecated option still works but logs a warning.
- Tests. The unit suite passes. An integration test for retries fails, because a default timeout changed.
- Dependency tree. The lockfile diff shows one new transitive package. It is a small, widely used utility, so the team notes it for review.
- Reachability. The vulnerable code path handles redirects, which the service does use. Urgency is high.
- Rollback. The team knows how to redeploy the previous image in minutes.
The team sets the timeout explicitly in code to preserve old behavior, reruns the tests, merges, and deploys with a canary. After the rescan confirms closure, the ticket ends. The whole change was small because the checks were done.
Step by step: a repeatable upgrade routine
- Read the scanner finding for the fixed version and dependency path.
- Open a branch and change only the one component where possible.
- Read the notes between the current and target versions.
- Run the suite and any manual checks tied to the package.
- Diff the lockfile and review new packages.
- Deploy gradually if your process supports it.
- Rescan and confirm the finding closed.
When the fix is not simple
| Situation | Options |
|---|---|
| Fix requires a major version change | Plan the work, apply a temporary mitigation, track as a project |
| Parent package pins the vulnerable version | Update the parent, request an update from its maintainers, or use an override with caution |
| Package is unmaintained | Replace it, fork with care, or isolate it |
| No fix exists | Mitigate, monitor and record an exception with expiry |
Mitigations to consider
- Disable the vulnerable feature through configuration.
- Filter inputs at the edge to block the known pattern.
- Restrict network exposure of the affected service.
- Add detection for exploitation attempts while a fix is prepared.
Mitigations buy time. They do not close the finding, so keep the ticket open until the component is gone or the risk is formally accepted.
Try it yourself
Step through a proposed fix and look at what changes in the dependency tree.
Click through it at your own pace, or open it full screen.
Where Safeguard fits
Safeguard can open fix pull requests for dependency findings. The capability is off by default and every category starts on Manual, so a person reviews each change. A free scan is at gold.safeguard.sh/scan.
Quick check
Should fix pull requests merge automatically?
Start with manual review. Consider automation only for low risk updates once your tests are trusted.
What if no fixed version exists?
Look for a mitigation, a replacement package, or a documented exception with an expiry date, and keep monitoring.
Is it ever safe to skip the changelog?
Rarely. A quick read often reveals changed defaults or removed behavior, which are the most common causes of broken upgrades.
Sources
Last reviewed: 19 October 2026.
