"Fix available" means a newer version of the affected component exists that is listed as not affected. It does not mean the upgrade is safe, compatible or already in your build. Treat it as a lead: verify the target version, read the changes, and run your tests.
What the label tells you
The scanner compared your version with advisory data and found a release at or above a patched version. That is all. It does not know your code, your other dependencies, or your constraints.
What it does not tell you
- Whether the new version changes behavior your code relies on.
- Whether other packages pin the old one, blocking the upgrade.
- Whether the fix is a minor patch or a jump across major versions.
- Whether the affected function is even called by your code.
Checks before you merge
| Check | Why |
|---|---|
| Version distance | A patch bump is lower risk than a major release |
| Release notes | Look for removed APIs and changed defaults |
| Dependency tree | A transitive package may need an override or a parent upgrade |
| Tests | Run unit and integration tests, plus a smoke test of key flows |
| Reachability | Decides urgency, not whether to fix |
Steps
- Read the advisory and note the first patched version.
- Pick the smallest upgrade that reaches it.
- Open a branch, apply the change and regenerate the lockfile.
- Run tests and compare the dependency diff, so you see what else moved.
- Merge through normal review. Record the result in the ticket.
When there is no fix
Options include a vendor workaround, removing the feature, replacing the package, or accepting the risk with a reason and a review date. Do not leave it unowned.
Common mistakes
A common mistake is merging a bulk upgrade because every line says fix available. Large batches hide which change broke what. Prefer small, separate changes for risky packages, and group only low risk patch updates. Another mistake is forgetting runtime effects such as a changed default. Run the application in staging for a short period and watch error rates. Keep the rollback ready, and note the previous version in the pull request description.
Try it yourself
Click through it at your own pace, or open it full screen.
Look at how a proposed fix is shown next to the finding it resolves.
Quick check
Can I apply every available fix automatically?
Be careful. Automated fixes are useful, but they should open a reviewable change that your tests run against, not merge unseen.
Is the newest version always the right target?
Not always. The smallest version that includes the fix usually carries less change.
Where Safeguard fits
Safeguard offers autonomous remediation with fix pull requests. It is off by default, with every category set to Manual. Try the free scan.
Last reviewed: 19 October 2026.
