How do I fix my first vulnerable dependency safely?

To fix a vulnerable dependency safely, confirm you are really affected, find the lowest fixed version, upgrade on a separate branch, run your tests, read the change in a pull request, and ship it with a note about what you did. Start with a small upgrade, not the biggest one on the list.

TL;DR

• Fixing one dependency is a small, repeatable routine. Learn it once on an easy case.
• Work on a branch, upgrade one thing, run the tests, and have a person review the change.
• Prefer the smallest version jump that clears the flaw.
• Automated fixes are optional. In Safeguard, they are off by default and every category starts on Manual.

Definition: A dependency fix means changing a package in your project to a version that no longer has a known flaw. The code you wrote stays the same. The version of the outside package changes.

What does "fixing" a dependency actually mean?

Most vulnerable dependencies are fixed by one change: move to a newer version. The people who maintain the package find the flaw, release a fixed version, and publish a notice. You change a version number, install, and test.

That sounds simple, and often it is. The risk is that a new version might change how the package behaves, and your code may rely on the old behavior. So the goal of the routine below is not speed. It is to make a small change you can undo.

If you are new to this, our post on automating vulnerability remediation gives the wider picture. This post stays at the level of one dependency.

What are the steps?

Here is a routine you can follow every time.

1. Pick one finding. Choose a high severity item that has a fixed version. Do not start with the hardest one.
2. Confirm you are affected. Check that the version you run is in the affected range, and that your code uses the risky part if you can tell. The free Gold site has an "Am I affected?" check on its CVE pages, where you enter your version and get a verdict against the advisory's affected and fixed versions.
3. Find the lowest fixed version. The Gold docs say each package page with known vulnerabilities shows a recommended safe version, which is the lowest version that clears the most advisories. Lower jumps mean lower risk.
4. Create a branch. A branch is a separate copy of your code where you can try changes without touching the main line.
5. Upgrade the one package. Change the version in your dependency file and refresh your lock file, which pins the exact versions you use.
6. Run your tests. If you have none, at least start the app and use the main paths by hand.
7. Open a pull request. Write one or two lines on what changed and why. Ask a teammate to read it.
8. Rescan. Confirm the finding is gone and no new one appeared.
9. Merge and note it. Keep a short record: which CVE, which versions, when, who.

Nothing here needs special tools. The tools only make each step faster.

How big a version jump is safe?

Version numbers usually have three parts, such as 2.4.7. The parts are major, minor and patch.

These are conventions, not guarantees. Some projects follow them closely and some do not.

Safeguard's IDE extension builds this idea into three fix strategies. Safe takes minor updates only. Balanced, the default, takes minor and patch updates. Aggressive moves to the latest available version. The Safeguard fixes demo shows a similar grouping: compatible, minor and major upgrades, with the risky ones marked as likely to break your code.

When in doubt, pick the smallest jump that clears the flaw. Save major upgrades for a day when you have time to test.

What do I do when the only fix is a major upgrade?

Sometimes the fixed version is a major release. Do not rush it. Try this order:

1. Read the release notes for breaking changes.
2. Search your code to see how many places use the package.
3. Upgrade on a branch and run the tests. Let the failures tell you what changed.
4. If it is too big for today, write a ticket with the CVE, the target version and a date.
5. Meanwhile, check whether the risky feature is turned off or unused in your code. That may lower the urgency.

How do I fix it from the terminal or editor?

You have a few options, and all of them end with you reviewing a change.

• In the editor. The Safeguard extension suggests a fix on hover. In JetBrains, the fix opens a diff view so you can review it before you apply it. See our editor guide.
• In the terminal. The Safeguard CLI has a fix command for updating vulnerable dependencies, and a review command that checks working tree changes for correctness and security. Its built-in assistant can also write code. You can type something like "fix the lodash CVE in this repo". It asks before it edits files or runs commands, unless you choose a mode that does not ask. See our CLI guide.
• By hand. Edit the file and run the install command yourself. Perfectly fine.

What about automatic fix pull requests?

The platform can open fix pull requests for you. The Safeguard remediation demo says that everything starts off and set to Manual until an admin turns it on. In Settings, under Automation, an admin chooses a strategy for vulnerabilities and for eight other kinds of plans, and decides which ones run automatically. The fixes demo adds that AI Remediate ships turned off.

That default is sensible. Turn on automation slowly. First read several fix pull requests by hand to see whether the fixes match what you would do. Then decide which categories you trust to run alone. Our FAQ on automated pull request fixes covers the questions teams ask most.

What does a first fix look like with invented numbers?

Here is a pretend fix. The numbers are invented to show the routine.

Your scan shows 12 findings. You pick one: a high severity flaw in a package called formtools, version 3.1.4. The advisory says versions before 3.1.9 are affected, and 3.1.9 is the fix.

You check: you run 3.1.4, so you are affected. The jump to 3.1.9 is a patch change, so the risk is low.

You create a branch and change the version to 3.1.9. You refresh the lock file. You run 85 tests. 85 pass. You open a pull request with two lines of notes. A teammate reads it, sees one line changed in the dependency file and a few lines changed in the lock file, and approves.

You merge, rescan, and the finding is gone. You now have 11 findings. The whole routine took under an hour, and most of that was waiting for tests.

Compare that with a major upgrade: 12 tests fail, so you stop, write a ticket and plan time for it. That is the right call, too.

How can Safeguard help?

Safeguard offers generally available capabilities that support this routine:

• SBOM and dependency scanning to find the vulnerable package and rescan after the fix.
• Reachability analysis to check whether your code reaches the flaw.
• Autonomous remediation with fix pull requests, off by default, with every category on Manual until an admin turns it on.
• Policies and gates to keep new critical findings from merging.

If you have no account yet, the free scan at gold.safeguard.sh/scan is a good place to find your first candidate.

Try it yourself

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

Follow the nine steps from a scanned repo to the pull request that fixes it, and look for the step that checks whether your code really reaches the flaw.

Quick check

Sources

• Find and fix a vulnerability demo
• Remediation strategies demo
• Fixes available now demo
• IDE support documentation
• CLI usage documentation
• Gold Open Source documentation
• Safeguard Gold, Free Dependency Scan

Last reviewed: 19 October 2026.