Verify that the suggested version exists, that the advisory says it fixes your issue, what breaking changes it introduces, what else changes in the lockfile, and that tests cover the code that uses the package. The assistant's confidence is not evidence for any of these.
Why the suggestion needs checking
OWASP's misinformation entry notes that models can suggest non-existent libraries and that attackers can publish malicious packages under commonly hallucinated names. The same weakness applies to versions: a model can name a release that was never published, or one that does not contain the fix.
The six checks
- Does the version exist? Look it up on the registry page, not in the model's answer. Check the publish date and the maintainer.
- Does it fix the issue? Open the advisory and confirm the fixed version range. Do not rely on the model's summary of it.
- What does the changelog say? Scan release notes for removed APIs, changed defaults and minimum runtime versions. A major version bump deserves a longer look.
- What else moved? Run the install in a branch and read the lockfile diff. A single upgrade can pull in new transitive packages.
- Do tests cover the usage? Search your code for calls into the package. If no test exercises them, add one before upgrading.
- Rescan. Confirm the finding is gone and that no new advisories were introduced by the transitive changes.
Reading the lockfile diff
| What you see | What to do |
|---|---|
| Only the target package changed | Good, proceed with tests |
| Several packages changed | Check each new version exists and its advisories |
| A new package appeared | Check what it is and why it is needed |
| A package was removed | Confirm nothing in your code depended on it |
| Integrity hashes changed unexpectedly | Stop and investigate |
Install commands
Use the lockfile based install command your ecosystem offers in CI, so builds use exactly what was reviewed. An assistant told to run install commands on its own can alter the lockfile in ways nobody reviewed. See npm ci vs npm install for AI-generated changes.
When there is no fixed version
Sometimes the answer is not an upgrade. Options include pinning to a patched fork you have reviewed, removing the feature that uses the vulnerable function, or adding a compensating control with an expiry date. Ask the assistant to list options, then decide with the code owner.
Record the outcome
Put the registry link, advisory link and test result in the pull request. It takes a minute and saves the next reviewer from repeating it.
Where Safeguard fits
Safeguard scans dependencies and can open fix pull requests, which are off by default with every category on Manual, then rescans the change. Try a free scan at https://gold.safeguard.sh/scan.
Quick check
Is a patch version bump always safe?
Usually lower risk, but not guaranteed. Still read the diff and run tests.
Should the assistant run the install itself?
Prefer that a person or CI runs it from the reviewed lockfile, so changes are visible before they land.
Sources
- OWASP GenAI, LLM09:2025 Misinformation: https://genai.owasp.org/llmrisk/llm092025-misinformation/
Last reviewed: 19 October 2026.
