When OWASP surveyed 225 security practitioners for the 2025 Top 10 update, something unusual happened. Software Supply Chain Failures didn't just make the list — it received 106 first-place votes out of 212 respondents, a weighted score nearly double the runner-up. Virtually every respondent who ranked it placed it in the top three. In the history of the OWASP Top 10, no category has ever received that kind of consensus.

This wasn't a marginal reshuffling. It was the security community making a clear statement about where the threat landscape has moved.

From Patching Libraries to Defending the Entire Software Supply Chain

To understand why this matters, look at how the category evolved. In 2017, OWASP called it Using Components with Known Vulnerabilities. In 2021, it became Vulnerable and Outdated Components — still focused on keeping dependencies patched and up to date. Both framings treated the problem as a hygiene issue: know what you're running, keep it up to date, move on.

The 2025 version, A03: Software Supply Chain Failures, is a fundamentally different category. The scope now covers compromised build systems, poisoned CI/CD pipelines, tampered distribution infrastructure, dependency confusion attacks, and compromised third-party scripts running in users' browsers. It's no longer about whether you've patched Log4j. It's about whether any part of the chain between a developer's commit and a user's browser session has been compromised.

The real-world attacks that drove this expansion are familiar: SolarWinds showed what a compromised build pipeline looks like at scale. The XZ Utils backdoor demonstrated years-long social engineering of open-source maintainers. The Bybit wallet theft — $1.5 billion stolen — exploited a supply chain compromise that only activated under specific conditions. And the Shai-Hulud npm worm in 2025 became the first self-propagating supply chain attack in the npm ecosystem.

The Client Side Is Part of This Story

Think about supply chain security along two dimensions: when you check (build-time versus runtime) and where the code runs (server-side versus client-side). Most organizations have invested heavily in the build-time column — SCA tools, SBOM generation, dependency scanning, and build provenance verification. On the server side, some have extended that into runtime with container scanning, WAF, and RASP. These are mature capabilities that address real risks.

Figure 1 - Supply Chain controls quadrants

There's another limitation worth calling out. Most of the tooling in the build-time column works from manifests — package.json in JavaScript, requirements.txt or pyproject.toml in Python, pom.xml in Java. SCA tools and SBOM generators parse these manifests, resolve dependency trees, and check for known vulnerabilities. That's valuable work. But it only covers what the manifest says should be there. It won't detect a script that was injected after deployment, a CDN resource that was silently swapped, or a third-party tag that loaded a payload not declared in any manifest.

Here's an analogy: traditional supply chain tools are like airport security checking passengers against the flight manifest. You verify names, match boarding passes, and confirm everyone on the list is accounted for. In a typical client-side supply chain attack, the problem isn't a passenger on the manifest behaving badly — it's someone boarding the plane who was never on the manifest in the first place, and who didn't even have a ticket. If that mental picture feels alarming, it should. That's the reality of the top-right quadrant.

Client-side code monitored at runtime remains largely empty in most appsec programs. Organizations scan their npm dependencies before deployment, but once third-party scripts are executing in users' browsers, visibility drops to near zero. This is the quadrant where Polyfill.io, e-skimming attacks, and CDN compromises live. It's also the quadrant that has the fewest mature tools and the least organizational awareness.

The OWASP Top 10 team clearly intended A03 to cover this gap. The A03 prevention guidance explicitly calls for organizations to "continuously inventory the versions of both client-side and server-side components." That word — both — matters. It signals that the project leads recognize many organizations are only covering one side. The page even recommends retire.js alongside server-side tools like OWASP Dependency Track, acknowledging the need for client-side JavaScript scanning. But retire.js detects known vulnerable library versions at scan time. It doesn't monitor what third-party scripts actually do at runtime — and that's where the real exposure lives.

This matters because the client-side attack surface is enormous. According to the HTTP Archive's 2024 Web Almanac, 92% of webpages load third-party resources. Akamai's research found that 50% of JavaScript on e-commerce sites comes from third-party sources. These aren't libraries you chose and installed — they're analytics tags, marketing pixels, CDN-hosted scripts, and chat widgets that execute in your users' browsers with full access to the page DOM.

When Polyfill.io was compromised in 2024, over 110,000 websites were affected — a CDN acquired by a malicious actor that injected code targeting mobile users. No SCA tool caught it. No SBOM listed it. E-skimming attacks follow the same pattern: British Airways lost data on 380,000 customers through 22 lines of injected JavaScript; Ticketmaster was compromised for five months before detection.

PCI DSS Got There First

The PCI Security Standards Council recognized this specific threat vector before OWASP did. Requirements 6.4.3 and 11.6.1, which became mandatory on March 31, 2025, address it directly. Requirement 6.4.3 mandates that organizations maintain a complete inventory of all scripts running on payment pages, justify the business purpose of each one, and implement methods to confirm each script is authorized. Requirement 11.6.1 requires automated change detection and real-time alerting when payment page scripts are modified.

These requirements exist because the Council saw what e-skimming was doing to payment pages and concluded that traditional server-side security wasn't enough. Organizations needed visibility into what was actually executing in the browser.

The parallel with OWASP is instructive. PCI DSS identified a narrow but critical slice of the client-side supply chain problem — scripts on payment pages — and responded with specific, auditable mandates. OWASP has now elevated the broader supply chain threat to #3, recognizing that client-side script risk applies site-wide, not just on checkout pages. Both bodies arrived at the same conclusion from different directions: you cannot secure the software supply chain by looking only at what happens before deployment.

What Organizations Need to Do Differently

If your supply chain security strategy stops at the build pipeline, you're covering half the attack surface. The OWASP signal and the PCI DSS mandates point in the same direction: organizations need runtime visibility into client-side code.

Concretely, this means maintaining a continuously updated inventory of every script executing on your web pages — not just your own code, but every third-party tag, pixel, and externally loaded resource. It means monitoring the behavior of those scripts in real time, not just checking their versions at build time. And it means having granular controls that can block unauthorized behaviors without breaking legitimate functionality.

This isn't something you can solve with a spreadsheet or a quarterly audit. Third-party scripts change with every vendor update. They load other scripts dynamically. Pages behave differently depending on geography, user preferences, or which payment method a customer selects — meaning the scripts executing in one session may not match what you observed in another. A point-in-time scan captures a single snapshot, but the actual attack surface shifts continuously. That's what makes runtime monitoring essential: it reflects what actually executes in the browser, not just what was supposed to.

How Jscrambler Addresses the Gap

Jscrambler's Webpage Integrity (WPI) module was built specifically for this problem. It provides real-time visibility into all scripts running on a website — first-party and third-party — with behavioral monitoring that detects unauthorized modifications, data exfiltration attempts, and malicious injections as they happen. Its rules engine gives security teams granular control over what each script is allowed to do, including which data it can access and which form fields it can read, without requiring the script to be removed entirely.

For organizations subject to PCI DSS, Jscrambler maps directly to requirements 6.4.3 and 11.6.1 — automated script inventory, authorization workflows, and real-time change detection on payment pages. As a member of the PCI SSC Board of Advisors and a Principal Participating Organization, Jscrambler is regularly consulted on standards development and has provided feedback throughout the v4 lifecycle.

On the first-party code protection side, Jscrambler's Code Integrity module applies polymorphic obfuscation and anti-tampering measures to your own JavaScript. Each build produces a unique transformation, making systematic reverse engineering impractical. This addresses the other half of the client-side supply chain equation: protecting the code you ship from being modified after deployment.

Time to Close the Gap

The OWASP Top 10 doesn't change often, and when it does, the shifts reflect years of accumulated evidence. Elevating supply chain to #3 — with the strongest community consensus ever recorded — is not a theoretical warning. It's a recognition that the attacks are already happening, at scale, across the entire software supply chain.

PCI DSS already mandates client-side script monitoring for payment pages. OWASP is now telling the broader application security community that software supply chain risk extends far beyond server-side dependencies.

If you're a security leader reading this, here's the question worth asking internally: Do we have the same level of visibility into what runs in our users' browsers as we do into what runs on our servers? For most organizations, the honest answer is no. Closing that gap — with runtime monitoring, script-level behavioral controls, and continuous inventory of client-side code — is how you turn OWASP's signal into an operational improvement rather than another line item on an awareness slide.

The tooling exists. The regulatory precedent is set. The attacks aren't waiting.

KEEP LEARNING

Join Jscrambler for SecurityWeek’s 2026 Supply Chain & Third-Party Risk Security Summit, where top security experts will unpack the biggest software supply chain risks, the complexity of modern threats, and proven strategies to mitigate risk.

Gareth Bowker, Jscrambler's Head of Security Research, will examine what OWASP’s shift means for application security leaders. Drawing on newly released research into third-party scripts, Gareth will reveal not only the security risks of client-side dependencies but also the data governance implications, including how third-party scripts gain real-time access to user input, behavioral signals, and sensitive session data.