AI-Era Software Supply Chain Risk: Sonatype's 49-Month Study
Blog post from Sonatype by Aaron Linskens (technical writer), published on August 18, 2026, ~1,300 words: it recounts a Sonatype Research Labs study spanning 49 months (June 2022 — June 2026) and a fixed cohort of enterprise applications, a methodological choice asserted to isolate the evolution of the application fleet rather than that of the customer portfolio.
By Aaron Linskens// Source sonatype.com ↗/Reading 2 min/.md// Auto-verified translation
#software supply chain#software supply chain#Sonatype Research Labs#fixed cohort#longitudinal study#Critical and High vulnerabilities#vulnerability advisory#affected component versions
Summary
Sonatype publishes, written by its technical writer Aaron Linskens, a synthesis of a longitudinal study by its research labs spanning forty-nine months, from June 2022 to June 2026. The method is stated upfront: a fixed cohort of applications tracked continuously, so that the measured variations reflect the evolution of the software fleet rather than that of the customer portfolio. The central result is presented as a contradiction: organizations remediate faster than before, yet their applications accumulate more risk.
Four measures frame the finding. Critical and High vulnerabilities per application were multiplied by 4.31, rising from an average of 14.14 in June 2022 to 54.3 in 2026; the effect is not driven by legacy alone, since excluding legacy applications recently brought under management still leaves a factor of 3.91. Newly affected component versions are advancing at forty-six times the pre-AI rate. The median age of vulnerabilities has fallen 59% since its peak in January 2024. Finally, the average monthly creation of applications was multiplied by 4.84, and with it the dependency decisions.
The progress in remediation is real: more than half of resolved violations are resolved in under a day, and the median age of unresolved Critical/High vulnerabilities drops from 228 to 126 days, then to 103 days in May 2026. Among cohorts with at least twelve months to act, 52.6% are resolved, 44.3% remain open, and 3.1% are under waiver.
The proposed shift concerns the upstream. The researchers examined the vulnerable dependencies that entered the period's applications and asked a simple question: at the time of selection, did a substantially less risky version already exist? The answer is yes in 62.2% of cases on Maven, 46.9% on npm, and 34.3% on PyPI. The text declines to read this as developer fault: some vulnerabilities are unavoidable, others stem from an information gap at the time of the choice — a point that becomes sensitive when an AI assistant can introduce a component in seconds without having up-to-date intelligence on its risk and on organizational policy.
The post acknowledges that AI is not the sole cause of the expanding vulnerability landscape and cites four competing factors. It concludes on Sonatype Guide, which brings this intelligence to the point of selection, and points to the full report, The AI-Era Software Assembly Line, for the underlying data.
Key takeaways
The contradiction is the main result. , and it is arithmetic before it is strategic: remediation is accelerating (median age 228 → 126 → 103 days) while the stock per application quadruples (14.14 → 54.3Critical/High). Remediating faster is not enough when the inbound flow grows faster than processing capacity.
An application's risk moves even when its code doesn't. Direct formulation from the post: a dependency deemed acceptable yesterday can receive a disclosure tomorrow, become unmaintained, or see a safer version released. Consequence for internal monitoring: a frozen inventory is not a security state, and the absence of a commit is not the absence of an event.
The most actionable figure is that of the available version. at the time of selection, a substantially less risky version already existed in 62.2% of cases on Maven, 46.9% on npm, 34.3% on PyPI. The gap between ecosystems is itself a data point — it ranks where prevention pays off most.
Two distinct causes behind the same symptom. some vulnerabilities are unavoidable (the ecosystem offers no safer option), others are information problems (the one choosing — human or assistant — lacks the right context at the moment of choice). Only the second class is addressable through tooling at the point of selection.
The tension point specific to AI. , as the post frames it: an assistant can recommend and introduce a component in seconds, but « a fast recommendation is not necessarily an informed one » — it needs current intelligence on risk, available versions, maintenance, and internal policy, which knowledge frozen in the model's weights does not guarantee.
What the post does not quantify. , and should be requested from the full report before citing: the cohort size (no application count given), the value of the January 2024 peak — the 59% decline refers to it, while the 45% decline starts from 228 days, hence two different baselines —, and the start date of "the AI era", used as a comparison boundary without being defined.
Causal honesty is carried by the text itself. four alternative factors to AI are named for the expansion of the vulnerability landscape — better research, better disclosure, AI-assisted security research, and evolving attacker behavior. The position taken is pragmatic: « Organizations don't need to prove a single cause to confront the outcome. The scale itself is the problem. »
Related. [[fiches/2026-08/claxton-anthropic-ai-native-sdlc-playbook-2026-08-21]] (the skill advises, the hook constrains — here, component policy is exactly what stands to gain from becoming deterministic at the moment of choice) and [[fiches/2026-07/sfeir-code-review-anneau-contraintes-2026-07-30]] (the ring of constraints around the agent, of which dependency selection is a rarely instrumented upstream link).
Key figures
Critical/High vulnerabilities per application ×4,31 between June 2022 and June 2026
la remédiation s'accélère alors que le risque accumulé par application augmente
— Securing Software at the Speed of AI
le profil de sécurité d'une application change sans que son code change
— Securing Software at the Speed of AI
AI is not the sole cause of the expanding vulnerability landscape
— Aaron Linskens
the version gap is an information failure, not a developer fault
— Aaron Linskens
The knowledge graph extracted from this fiche — 11 entities, 19 relations.
In this graph :Sonatype · Aaron Linskens · Sonatype Research Labs · Securing Software at the Speed of AI · The AI-Era Software Assembly Line · cohorte fixe d'applications · sélection de composant · Sonatype Guide · Maven · npm · PyPI