Sonatype: 27.76% of AI-generated dependency upgrade suggestions point to nonexistent versions

AI agents are proposing dependency upgrades faster than most engineering teams can review them, and a notable share of those proposals are provably wrong. A dev.to article published on November 13 cites figures from Sonatype's 2026 State of the Software Supply Chain report: of 36,870 AI-generated upgrade recommendations analyzed, 27.76% pointed to package versions that do not exist in any registry. The same report, according to the article, found that nearly 65% of open source CVEs carry no NVD-assigned CVSS score, which leaves severity labels unreliable as a safety signal.

Wrong versions and missing severity data

Recommending a release that was never published is a distinct failure mode of automated patching. A green build proves the code compiles and that the tests a team already wrote still pass; it does not prove the version exists upstream, that it is free of known flaws, or that the affected code paths were exercised. A model's fluent explanation of its choice can feel like evidence while being none, the author argues, because without a stored record of what was checked, nobody can reconstruct the decision later. The review surface is also wider than it looks: bumping one direct dependency can pull in a dozen transitive ones, each with its own code and maintainers. Reviewers tend to read the manifest diff, while the real change lives in the lockfile.

Upgrade evidence as a build artifact

The article's central proposal is that every automated upgrade should carry a verifiable record, effectively a receipt attached to the commit, proving the change was necessary, correct, tested and approved. Because detection tools stop at the alert, that record has to be produced by whatever step actually modifies the code. The suggested record has six parts: a lockfile diff captured before and after the agent runs, covering every transitive change; the advisory IDs that motivated the upgrade; a registry lookup confirming each new version actually exists; regression test results covering the code paths that import the upgraded package; an approval tier; and a rollback reference. The registry check belongs next to the test results, since one proves the package is real and the other that the application still behaves. The file is stored as a build artifact, and a CI gate blocks the merge when it is missing, incomplete, or shows failed tests or an unverified version.

Keeping humans in the loop

Review depth is tied to the size of the version jump. Patch releases with complete evidence can auto-merge to staging after a spot check, minor releases need one reviewer who reads the evidence pack, and major releases get a full review plus a tested rollback plan. Scanners already handle detection well, the author writes, so the reviewer's role shifts from verifying a change by hand to signing off on a documented one.

A vendor-authored guide

One caveat: the post closes by describing Xccelera, a company building an AI dependency upgrader and vulnerability auto-resolver that records each scan, upgrade and fix as evidence, with human approval where policy requires it. The practices it recommends, such as stored diffs, registry verification and fail-closed CI gates, align with general supply chain norms, but they are presented by a vendor with a product in this category.

Why it matters

As agents take over patching, the characteristic error changes: instead of slow or missed updates, teams now face fast, confident and occasionally fabricated ones. A nonexistent version fails loudly at install time; a real but untested one fails quietly in production. Sonatype's figures give the concern a concrete basis, since more than one in four AI upgrade suggestions in the sample could not have been applied at all, and most known CVEs lack an authoritative severity score to arbitrate whether an upgrade is worth the risk. The deeper gap the article points to is the missing record rather than the bad version itself: without stored proof of what was checked, teams cannot reconstruct an automated decision months later, which is precisely what supply chain audits and incident reviews demand.