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.

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.