Category: Software Supply Chain Security

When organizations tackled security risk in the past, they often overlooked runtime risk. After all, security measures deployed during the design and build phases of a software project should make for a secure product once the run command is issued. That’s not the case, however, as security teams are beginning to realize.

One of the problems with overlooking runtime risk is that the supply chain doesn’t end with deployment. Things like containers, serverless functions, orchestration platforms, infrastructure-as-code modules, and, of course, artificial intelligence extend it.

“[W]ithout proper testing, inspection, and overall adherence to an organization’s official software development life cycle (SDLC), AI-created code could introduce weaknesses and even cause outages,” Zscaler’s Director of CXO REvolutionaries & Community Christopher Jablonski wrote in a company blog.

“When bad code is made, put in a public repository, and others use it in their projects, the problems can quickly spread into the software supply chain,” he explained.

Not only do AI systems inherit traditional software supply chain risks, but they also introduce new attack surfaces through training data, pre-trained models, and fine-tuning pipelines, noted Joe Braidwood, CEO of Glacis, in his guide to AI supply chain security. He also pointed out that 97% of AI projects contain vulnerable dependencies, supply chain attacks have increased 3x year-over-year, and over 10,000 malicious packages target ML developers on PyPI alone.

Runtime Risk: Visibility Problem

Another problem with treating runtime risk lightly is the lack of visibility. Much of what’s done to secure the supply chain is done before or during the build process. That can create gaps during runtime. “A managed container runtime, a third-party service broker, or a plug-in library can introduce new risks without any direct change in your codebase,” warns Ox Security. “Every runtime agent, service mesh plug-in, or library loaded at runtime forms part of that chain.”

“What makes software supply chain risk so insidious is its near-invisibility that stems from limited direct oversight,” Jit Director of Product Marketing Charlie Klein wrote in an online article titled How to Manage and Reduce Software Supply Chain Risk.

“Each third-party integration and each nested dependency passes through multiple layers without undergoing the same scrutiny as in-house code,” he explained. “When a component reaches production, potential vulnerabilities may have already slipped through undetected. And since these risks don’t manifest immediately, they’re often ignored—until it’s too late.”

Third-party scripts are another source of risk obscured at runtime. They’re trusted by design and controlled by a third party, which can be a dangerous combination.  According to Osterman Research, those scripts and libraries—often added without approval or ongoing security validation—can introduce hidden risks into an organization.

“Collectively referred to as ‘Shadow Code,’ these scripts and libraries are used for tasks like ad tracking, payments, customer reviews, chatbots, tag management, social media integration, or other helper libraries that simplify common functions,” the Osterman white paper explained.

Data Leakage Threat

One of the greatest risks from third-party scripts is data leakage. According to the Princeton Web Transparency & Accountability Project, when someone browses the web, hidden “third parties” collect a large amount of data about their browser behavior. That data feeds algorithms for targeted advertising, tailored news recommendations, and sometimes varying prices of online products.

“The network of trackers comprises hundreds of entities, but consumers have little awareness of its pervasiveness and sophistication,” it explained.

Making matters worse, once a third-party script is added to a website, it can add its own script to the site. “These are called piggyback tags, and you have no visibility into or control over them,” the Legal Banner explains. According to the Banner, some typical ways scripts are used to leak data include:

• Using session replay tools to record form inputs, such as passwords and credit card numbers, and sending them to external servers.
• Using ad scripts to fingerprint users via Canvas, WebGL, and audio context APIs, even where cookies are blocked. ” The Canvas API is one of the sneakier ways that a seemingly benign interface provided by the browser can contribute to a unique fingerprint,” Princeton noted.
• Using chat widgets to load analytics scripts from multiple ad-tech partners.
• Using social media to embed widgets that track users even when they’re not interacting with the widget.
• Using tag managers to add scripts to pages without developer review.

The risks posed by third-party data leakage are considered very serious, so serious that they’re included in the OWASP’s Top 10 Client-Side Security Risks.

Exploiting scripts isn’t limited to cybercriminals. Large tech players have come under fire for their use of data-collecting scripts. Meta has been knocked for its scripts being found on hospital patient portals, telehealth sites, government service portals, and university financial aid pages. TikTok faces similar criticism, with the added risk that, since the company had Chinese connections, captured data could end up in an adversary’s hands.

Waking Up to Runtime Risk

Modern applications are executing more untrusted code, much of it third-party scripts that run at runtime in a browser. That code carries serious risk because it executes with full privileges, can be changed at any time without the user’s knowledge, can load other scripts, and can exfiltrate DOM data — the live, in-memory representation of a web page that a script can read, modify, or exfiltrate.

Security teams have an arsenal of security tools — SAST, DAST, SCA, CI/CD hardening — but none of them can see what happens after a page loads. They’re beginning to learn the limits of those tools and the need to address the attack surface exposed at runtime.

Closing the Runtime Control Gap

To effectively address the hidden risks in the modern software supply chain, organizations must move beyond pre-deployment checklists and adopt a strategy of continuous runtime enforcement. Here are the critical requirements for solving the structural control gap:

• Enforce Control at the Point of Creation: Security must extend to the browser, where data is first entered and assembled, rather than waiting until it reaches the backend, by which point risks have already materialized.
• Implement Least-Privilege Execution: Move beyond simple script inventories to granular rules that restrict exactly what a script can access, such as specific form fields, cookies, or browser storage, while blocking everything else.
• Govern AI Inputs Upstream: Prevent sensitive or proprietary data from being “leaked” into external AI models by controlling what contextual information AI agents can scrape from the page before it is transmitted.
• Detect and Block Behavioral Drift: Monitor third-party components for real-time behavioral changes —such as a trusted analytics script suddenly accessing a payment field — and block the action immediately without breaking the page.
• Harden Proprietary Business Logic: Protect first-party code from being reverse-engineered or manipulated by attackers using automation to probe for vulnerabilities in pricing, loyalty, or authentication workflows.
• Generate Continuous, Audit-Ready Evidence: Replace manual vendor questionnaires with real-time telemetry that proves security policies are being technically enforced during every live user session.

It used to be that the biggest worry for enterprise chief information security officers (CISOs) was protecting their companies at the edge of the corporate firewall – the original network edge – to keep intruders out of their infrastructure, applications, and data. Over time, that broadened as the network edge expanded to the cloud, IoT, mobile devices, and other edge technologies as they were added to the business security challenges battled daily by CISOs.

Today, all these cybersecurity targets continue to be closely scrutinized and protected by traditional enterprise security defenses. But one other technology that emerged back in 1994 – the ubiquitous web browser – is, ironically, still largely overlooked as an edge security and privacy danger for enterprises and their CISOs. And in recent years, as the use of third-party scripts and AI-powered agents has grown exponentially, web browser security continues to lag.

Wait a minute. Web browsers as a security threat? Are you kidding?

Well, it turns out that there is plenty of private and valuable business and customer data that browsers can unknowingly reveal through third-party scripts and AI-powered agents that are watching company and customer activities and transactions within the browsers themselves.

Nowadays, this critical need for browser security is part of the little-discussed and mysterious world of “client-side security.”

Why does this matter?

Because web browsers today have become the newest “security edge” for enterprises, they are  essentially reframing IT security for CISOs as the latest critical place where customers are entering their sensitive data, including credit card numbers, addresses, and other details.  With this personally identifiable information (PII) originating in the browser, it becomes a critical control point for CISOs, who may not realize that traditional security vendors lack specific controls for scripts and AI agents in browsers, leaving this sensitive information exposed.

Pixels and web trackers have been used by corporate marketing teams inside websites for quite a while to follow customer behaviors and transactions, providing important insights and information that are captured to increase future sales and revenue. But the expanded use of more audacious automated, AI-powered trackers by outside parties has risen dramatically inside consumer web browsers. These AI agents are scraping business websites for user and transaction data and are collecting it the moment it’s in the browser, often without enterprise knowledge or say over the use of that customer data. The ad trackers come in many forms from a wide range of well-known companies, including Meta Pixel, Google Ad Tag, Reddit Pixel, TikTok Pixel,  and many more.

The big problem is that this activity is happening within the browser runtime, where organizations lack enforcement capabilities due to insufficient controls. Security teams cannot clearly see which ad trackers and scripts are running and what they are collecting. At the same time, these glaring browser security shortcomings are not within the purview of the CISO, who is typically worried more about the bigger security issues, including the backend servers, databases, APIs, cloud, and other traditional sources.

This lack of browser security oversight occurs because, in the past, software supply chain security, the practice of ensuring the code is clean and secure as it is developed, has not directly focused on browser runtime enforcement. Instead, it focused on important application security components, including Software Bills of Materials (SBOMs), which inventory and list code packages, licensing details, and other critical metadata used to ensure application integrity and allow the parts to be traceable for security. But that only addresses part of the risk.

What software supply chain security has not covered in the past is the runtime supply chain in the browser, leaving it largely ungoverned. This is especially so today as modern websites are filled with dozens of third- and fourth-party scripts that are being added on by marketing teams and tag managers to collect more customer information and track customer behavior.. When customers browse those websites, the trackers monitor their shopping and purchasing behavior.

But many ad trackers and agents are also watching and collecting customer information outside of their original intent, and this is where the real problems arise.

Modern browser environments enable companies like Meta, Google, and TikTok to deploy AI agents that aggregate user data directly from your website—alongside data collected across the broader internet. This combined dataset can then be repurposed—without explicit consent—for competitive activities like price benchmarking and market analysis against your business. That’s likely far outside the intent of your marketing and data strategies.

This is all happening surreptitiously in the background. Your marketing team is not watching it because marketers are not in the business of keeping your company secure. The security team is not guarding against this ad-tracking behavior because they are likely not being informed about the trackers being used. This is where the gap, or miss, occurs 24/7 in the customer web browsers connecting with your company to do business. This is not the IT security and data privacy that you are aiming to achieve.

What enterprises can do to fight back against AI trackers

With little fanfare, web browsers have quietly become the most privileged yet least controlled enterprise environment at the edge.

As that original corporate edge has shifted over the years from the firewall to the cloud, IoT, mobile devices, and more, enterprise IT security teams responded by expanding their protections and monitoring to each new wave of edge innovations.

Now that same security expansion must be provided for browsers by IT security teams to enable them to effectively battle the latest data protection and privacy threat vectors that reside in these latest edge targets. When the issue was just trackers added by the marketing team, it may not have been a huge concern. But now, as more and more super-fast agentic AI agents and trackers are exploding across the scene, these hidden browser risks have become much larger and more automated security powder kegs for enterprises.

How Jscrambler can help

As the enterprise edge has shifted to browsers, CISOs must now take steps to protect their sensitive customer and business data, as well as privacy. They should also pay close attention to the third-party software supply chains bombarding their companies via AI-powered agents embedded in their websites and applications.

Even the Open Worldwide Application Security Project (OWASP), a nonprofit software security foundation, is emphasizing the importance of software supply chain security and client-side code security today, moving its importance up to number three on its Top 10 list of application security risks.

As the leader in Client-Side Security, Jscrambler provides the missing control layer for the modern, composable web. While traditional security stops at the infrastructure edge, Jscrambler extends protection into the browser—the point of creation where digital business actually executes and sensitive data is first assembled.

Powered by a Behavioral Enforcement Core, Jscrambler’s Client-Side Security Platform moves beyond passive monitoring to govern the runtime behavior of first-party code, third-party scripts, and AI agents in real time. By enforcing least-privilege access to specific DOM elements, form fields, and browser APIs, the platform ensures that data is controlled at the moment of entry, before it can be exfiltrated or ingested by unauthorized systems.

Jscrambler does not disrupt approved third parties and digital experiences; instead, it provides the technical guardrails necessary to neutralize malicious threats like digital skimming, formjacking, and unauthorized AI data collection while allowing legitimate marketing and analytics functions to operate safely. This approach converts documented enterprise policy into enforceable protection, providing continuous, audit-ready evidence that security and privacy controls are active during live customer sessions.

By closing the structural control gap in the browser runtime, Jscrambler enables organizations to protect their intellectual property, preserve customer trust, and accelerate regulatory compliance at the new operational edge.

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.