Skip to content
Qubitron Security

4 min readQubitron Labs security team

OWASP Top 10:2025 puts supply chain at A03. A year of npm worms shows why

The 2025 OWASP Top 10 moves software supply chain failures to third place. Twelve months of npm and PyPI compromises explain the change, and what to check in your build.

  • OWASP
  • Supply chain
  • Web security

The OWASP Top 10 is the list most security questionnaires, pen test scopes and procurement checklists point at. The 2025 edition, presented at OWASP Global AppSec in November 2025, made one change that matters more than the rest: software supply chain failures is now its own category, in third place.

This post covers what changed in the list, the run of real incidents behind the change, and the checks that would have blunted most of them.

What changed in the 2025 list

The ten categories, as OWASP publishes them:

  1. A01:2025 Broken Access Control
  2. A02:2025 Security Misconfiguration
  3. A03:2025 Software Supply Chain Failures
  4. A04:2025 Cryptographic Failures
  5. A05:2025 Injection
  6. A06:2025 Insecure Design
  7. A07:2025 Authentication Failures
  8. A08:2025 Software or Data Integrity Failures
  9. A09:2025 Security Logging & Alerting Failures
  10. A10:2025 Mishandling of Exceptional Conditions

OWASP describes A03 as an expansion of the 2021 category for vulnerable and outdated components. It now covers compromises "within or across the entire ecosystem of software dependencies, build systems, and distribution infrastructure". In other words, the risk is no longer only an old library with a known CVE. It is the pipeline that builds and publishes your code. The list draws on data donated for more than 2.8 million applications, and OWASP says the category was overwhelmingly voted a top concern in its community survey.

Twelve months of worms

The timeline below is why "supply chain" stopped being an abstract category.

  • September 2025, chalk and debug. Malicious versions of 18 popular npm packages, including chalk and debug, were published with code that hijacked crypto wallet activity in the browser. Aikido, which reported it, noted that together these packages see more than 2 billion downloads a week.
  • September 2025, Shai-Hulud. A self-replicating worm spread through compromised maintainer accounts and stole cloud and GitHub credentials. CISA said it compromised more than 500 npm packages. GitHub removed the packages and announced phishing-resistant 2FA, short-lived granular tokens and trusted publishing for npm.
  • November 2025, Shai-Hulud 2.0. A new wave ran during package install. Wiz counted more than 25,000 affected repositories.
  • March 2026, Trivy, then LiteLLM. An attacker who kept access after an earlier incident force-pushed 75 of 76 trivy-action tags to malicious versions, according to Wiz. Days later, two LiteLLM releases on PyPI carried a credential stealer. LiteLLM traced it to the Trivy dependency in its own CI security scanning.
  • May 2026, TanStack. 84 malicious versions across 42 @tanstack packages went out in six minutes. TanStack's post-mortem describes a chain of three CI weaknesses: a pull_request_target workflow, GitHub Actions cache poisoning, and an OIDC token read from runner memory. Akamai reported that the worm's full code was published openly on 12 May.
  • August 2026, keyv and cacheable. A compromised maintainer account pushed a descendant of the same worm to more than 400 npm packages. Wiz noted it tried to persist through Claude Code hooks and VS Code task files.

The pattern: trust, not old CVEs

Read the root causes together and a pattern appears. None of these started with a dependency that had a known vulnerability. They started with a stolen or phished maintainer credential, a CI workflow that trusted the wrong input, a token that lived too long or wasn't fully rotated, or an install script that ran with the developer's permissions. Security tools and AI developer tooling were targets too: a scanner became the entry point for LiteLLM, and editor and agent hooks became persistence.

That is what A03 now asks you to own: not just "are my packages up to date" but "who and what can change what I ship".

What to check this week

  • Lockfiles and pinning. Commit lockfiles, install with the frozen or ci variant, and pin GitHub Actions to a commit SHA rather than a tag that can be force-pushed.
  • Install scripts. Know which dependencies run preinstall or postinstall scripts. Disable scripts in CI where you can and allow-list the few you need.
  • CI triggers. Never run untrusted pull request code with secrets. Treat pull_request_target and shared caches as privileged.
  • Short-lived, scoped credentials. Prefer trusted publishing and OIDC with narrow scopes over long-lived tokens. After any incident, rotate everything, not just the obvious token.
  • Phishing-resistant 2FA for every maintainer and anyone who can publish.
  • Repository hooks. Review agent hooks, editor tasks and git hooks committed to your repos; they run code on every developer machine that opens the project.
  • Know what you ship. Generate an SBOM for each release so you can answer "were we affected?" in minutes, not days.

A penetration test covers your application against the full Top 10. Hardening includes the build hygiene above, because what ships is only as trustworthy as the pipeline that produced it.

Sources

Keep reading

All posts

Next step

Find out what your app gives away. Book a free exposure call.

Thirty minutes with an engineer, not a sales deck. Tell us what you ship; we tell you what we'd look at first and what an audit would involve.

Book a free exposure callRequest an audit

We only test applications you own or are explicitly authorized to test.