Introduction
A bot opens a pull request that bumps a vulnerable package to the vendor's fixed version. You merge it. Did your security posture actually improve?
Often the honest answer is "we think so." The newer version might carry a CVE of its own. The vulnerable package might sit three levels deep in your dependency tree, where bumping it does nothing. And nobody on the review knows which of your call sites the upgrade will break. This post walks through how ZeroPath's auto-remediation closes those gaps: it opens upgrade PRs chosen so they don't make your posture worse, proves transitive fixes by resolving your tree in a sandbox, and attaches a report of what might break to each one.
What's wrong with "just bump it"?
Automated dependency updates were a real step forward. Dependabot and Renovate turned a manual chore into a steady stream of PRs that catches real risk. But an upgrade PR answers one question, "is there a newer version?", and a security team needs three more answered before it merges.
- Does the upgrade trade one CVE for another? "Latest" is not the same as "clean." A naive bump can move you onto a version with its own advisory, so you close one finding and quietly open another.
- Does it actually reach the vulnerable package? Most vulnerabilities live in transitive dependencies you never chose. Renovate can't update a transitive dependency unless its top-level parent moves, and the usual fallback, pinning a version with an
overrideorresolutionsblock, can change runtime behavior even when your tests pass. - What will it break in my code? A version bump is a diff against a library you didn't write, and without knowing which call sites it touches, review is guesswork.
Neither tool runs reachability analysis, so every CVE match looks equally urgent. On a large repo that means a wall of PRs where the two that matter are buried under fifty that don't.
How does ZeroPath choose a safe version?
ZeroPath picks the upgrade target instead of always taking the latest release, and the choice is deterministic. It runs two passes against live OSV advisory data and each ecosystem's package registry.
First it looks for the nearest version above yours with zero known CVEs. If one exists, that's the target. If none does, it falls back to the nearest version that fixes the specific advisory without adding a new CVE you weren't already exposed to, and it prefers a same-major bump so one finding doesn't drag you across a breaking major release.
If the advisory feed can't be reached, ZeroPath fails closed. A transient outage counts as "unknown," never as "no known vulnerabilities," so an unreachable feed can't wave through a still-vulnerable upgrade. Version comparisons follow each registry's real ordering rules (semver, PEP 440, Maven's own scheme) instead of a naive string sort, since that ordering is what decides whether a version is actually fixed.
How do you fix a transitive vulnerability without overrides?
Most tools stop at a recommendation here. When the vulnerable package is transitive, ZeroPath walks your lockfile to the nearest direct parent it can upgrade to pull in the fix, following the chain through multiple hops rather than one level.
Then it proves the fix, which registry metadata alone can't do. ZeroPath applies the parent bump and runs your package manager inside a hardened, gVisor-sandboxed environment to regenerate the lockfile, then reads that lockfile to confirm the vulnerable dependency now resolves to a fixed version. If it can't confirm that from the real resolved tree, it won't claim the fix worked.
Say [email protected] is flagged, pulled in by async. ZeroPath finds the async release that resolves lodash onto a patched line, runs the install to generate a real lockfile with real integrity hashes, checks that lodash landed safe, and only then opens the PR. No hand-written overrides, and no trusting a metadata table.
How do you know the upgrade won't break your code?
Every upgrade PR carries a blast radius report. ZeroPath fetches the old and new versions of the package, diffs the source, finds the real call sites in your repository, and labels each one safe, needs-review, or breaking, with a short reason, riskiest first. Reviewers spend their attention on the few sites likely to break instead of reading a diff blind.
Blast radius is context, not a gate. It never blocks a patch, and it leans toward needs-review over breaking, because a false alarm costs a reviewer less than a missed one. It reads static source, so it has real blind spots, like dynamically dispatched calls and renamed imports, which is why it flags a site for a human to check rather than deciding on its own.
What about the CVEs with no clean upgrade?
Sometimes no safe version exists. ZeroPath doesn't just file the finding as unfixable. For a direct dependency whose vulnerable code is reachable in your application, it can patch your calling code, fed the exact reachable call-site locations so it addresses all of them, or add a compensating control such as an authorization check or a defensive guard. When it genuinely can't produce a safe fix, it says so, with the reason and manual remediation steps, rather than shipping a guess.
Deterministic where it counts
The division of labor is deliberate. The version choice and the manifest and lockfile edits are deterministic. Language models never pick your version or invent a package hash. They work only at the edges: as a fallback patcher restricted to editing the manifest file, as the blast-radius reviewer, and as the last-resort code patcher above.
Which findings auto-open a PR at all is a threshold you set on severity and confidence, split independently for direct and transitive dependencies. Critical direct CVEs can remediate on their own, while the noisier transitive tail stays in manual review.
Getting started
Auto-remediation and CVE alerting are configured per repository in your scanner settings. Set a score threshold that matches your risk tolerance, point remediation at the branches you actually deploy, and let ZeroPath open upgrade PRs that arrive with their own evidence.
If you're not yet on ZeroPath, book a demo to see posture-safe remediation on your own dependencies. Most teams are scanning within five minutes of connecting their repositories. Read the docs → zeropath.com/docs/sca/remediation
ZeroPath is the AI-native application security platform that autonomously finds, verifies, and fixes exploitable vulnerabilities, consolidating SAST, SCA, secrets, and IaC into a single reasoning engine.
