Automated Remediation
Found a vulnerable dependency? Fix it without leaving the dashboard. For direct dependencies, one click opens a pull request that bumps the package to a safe version. For deeper, transitive dependencies, we show you the exact path to the one you actually need to upgrade.
Fix a direct dependency
A direct dependency is one your project lists in its own manifest (package.json, requirements.txt, go.mod, and the like). When a finding is on a direct dependency and a safe version exists, the vulnerability table shows an Upgrade to vX.Y.Z button right on the row.
Click it and we open a pull request against your repository that raises the package to the suggested version. There is nothing to configure - the button handles the branch, the manifest edit, and the PR.
What you see while it runs
The button updates live as the fix moves through the pipeline, so you never have to refresh or guess where things stand.
| Button shows | What it means |
|---|---|
| Queued… | The request is accepted and waiting for a worker to pick it up. |
| Creating PR… | We are cloning the repository and preparing the upgrade. |
| View PR #123 | Done. The link takes you straight to the pull request on GitHub. |
| Retry | Something went wrong. Click to try again - see troubleshooting. |
Requesting the same upgrade twice will not create duplicate pull requests - if a PR for that exact package and version already exists, the button links you to it instead of opening another.
Transitive dependencies and the upgrade path
A transitive dependency is one your project never asked for directly - it gets pulled in by something else you depend on. You cannot upgrade it on its own, because nothing in your manifest points to it. Its version is decided entirely by the direct dependency that brought it in.
So instead of an upgrade button, these findings show View upgrade path. Open it and you get the full dependency chain, from your project down to the vulnerable package:
your project → express (direct) → lodash (vulnerable)Each step is tagged Your project, Direct, or Transitive, and flagged with its own vulnerability count where relevant. The chain points you to the one node that matters: the direct dependency that introduced the problem.
When the direct parent has its own fix
{package} action that jumps you to that package’s finding, where you can open a pull request the usual way. Upgrading the parent is what pulls in the patched transitive version.When the direct parent has no tracked fix
How the fix is built
Behind the button, the upgrade is driven by Renovate , the same engine that powers automated dependency updates across the industry. We run it in a tightly scoped mode so it does exactly one thing:
- Only the package you asked for is touched. Every other dependency is left exactly as it is.
- The bump is capped at the suggested version - it will not leapfrog past the safe target.
- Updates that would introduce breaking changes are held back, so the pull request stays safe to review and merge.
- Each pull request gets its own branch named after the package and version, keeping your branch list tidy.
To open the PR, we use the Git credentials from your connected integration. Make sure your provider is connected before you start.
If a fix does not go through
Most failures come down to access or a manifest the upgrade engine cannot parse. When a request fails, the button switches to Retry so you can run it again once the cause is sorted.
Check your integration
Taking longer than expected?
Decide what to fix first
Not every vulnerability is worth an immediate upgrade. Pair remediation with the signals on each finding to spend your effort where it counts:
- Enrichment & prioritization tells you how exploitable a vulnerability really is, using CVSS severity, EPSS probability, and CISA KEV status.
- The Upgrade Feasibility Index estimates how hard the upgrade will be on your specific codebase - so you know whether one click will do it or whether to plan for a bigger change.