Verify three facts: the recommended package and version exist on the registry, the version is at or above the fixed version in a current advisory for your release line, and your lockfile resolves to it after the change. An AI suggestion is a lead to check, not evidence.
Why not trust the number
OWASP's cheat sheet on secure coding with AI says assistants are trained on historical code and often suggest versions that were current during training but now have known vulnerabilities. It also says assistants may not know about CVEs published after their training cutoff, and that they frequently suggest package names that do not exist.
So there are two separate risks: a real package at a stale version, and a name that points to nothing, or to something an attacker registered.
Step by step
- Confirm the package exists. Open its page on the public registry. Look at creation date, download history and maintainers. OWASP suggests being suspicious of very recent, low download packages with a single maintainer.
- Find the advisory. Use a vulnerability database. Many advisories use the OSV format, where affected ranges are described with events such as introduced and fixed.
- Match your release line. Some advisories list several fixed versions, one per supported line. Pick the fixed version on the line you can adopt without a major upgrade, and say so in the pull request. See also advisory fixed in several release lines.
- Compare with the diff. The version in the manifest should be at or above that fixed event.
- Check the lockfile. The manifest may allow a range while the lockfile pins something older. Confirm the resolved version in the lockfile diff.
- Look for extra changes. A lockfile diff that adds unrelated packages needs an explanation.
- Rescan the branch. Confirm the finding closes and no new one appears.
How semantic versioning helps and where it does not
The semantic versioning specification describes a patch increment as backward compatible bug fixes. That gives a reasonable expectation for patch bumps, but it is a convention that maintainers follow with varying discipline. A security fix may also arrive in a minor or major release. Read the release notes either way.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a finding is paired with a fixed version, which is the comparison you are making by hand in step four.
Make it routine
Run a dependency audit in CI on every pull request, whoever wrote it. OWASP recommends failing the pipeline on known vulnerabilities regardless of whether code was human or AI generated, and pinning versions so updates flow through your normal process.
Safeguard's SBOM and dependency scanning show affected and fixed versions, and its fix pull requests are off by default. The checks above still make sense when they open one.
Quick check
If the version exists, is it safe?
Not necessarily. It must also be at or above the fixed version for the advisory, and free of other known issues.
What if the AI names a package I have never heard of?
Do not install it until you have checked the registry page, age and maintainers. It may not exist or may be a lookalike.
Sources
Last reviewed: 19 October 2026.
