OWASP A03 now frames software supply chain risk as runtime exposure

At a glance

What this is: OWASP’s 2025 Top 10 update redefines supply chain risk as an end-to-end problem, with client-side runtime exposure now part of the attack surface.

Why it matters: IAM and NHI teams should care because modern software supply chains increasingly depend on secrets, scripts, tokens, and delegated access that can be abused long before traditional controls notice.

By the numbers:

• OWASP’s 2025 Top 10 update gave Software Supply Chain Failures 106 first-place votes out of 212 respondents.
• 92% of webpages load third-party resources, which means most browser sessions execute code beyond the organisation’s direct control.
• 50% of JavaScript on e-commerce sites comes from third-party sources, widening the runtime attack surface beyond first-party code.

👉 Read Jscrambler’s analysis of OWASP’s software supply chain category shift

Context

Software supply chain security now spans more than dependency patching. The real governance gap is that code can be trusted at build time yet still become unsafe when third-party scripts, compromised pipelines, or injected browser code execute at runtime. That matters to identity teams because the same delivery chain often carries secrets, tokens, and delegated access into production.

OWASP’s 2025 update reflects a broader industry correction. Security teams have focused heavily on manifests, dependency scans, and provenance, but the article shows that the threat also sits in what users’ browsers actually load and run. For IAM, NHI, and application security programmes, that makes runtime visibility a control issue, not just a software engineering concern.

Key questions

Q: What breaks when software supply chain controls rely only on post-build scanning?

A: Post-build scanning often finds problems after risky code, secrets, or malicious dependencies have already entered repositories, images, or deployment pipelines. By then, the issue may have propagated across multiple environments. Continuous upstream enforcement is needed because late detection does not stop distribution.

Q: Why do third-party scripts create governance risk similar to non-human identities?

A: Third-party scripts execute inside a live session with inherited privileges, broad context, and little lifecycle oversight. Like unmanaged non-human identities, they can behave beyond their declared purpose, change after deployment, and access sensitive data without human approval. That makes runtime privilege, not just vendor intent, the control problem.

Q: How can security teams measure whether supply chain controls are actually working?

A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise. If malicious releases still reach trusted build paths before detection, the controls are not containing trust inheritance.

Q: Who should own risk when a trusted dependency or script is compromised?

A: Ownership should be shared across application security, platform engineering, and identity governance, with clear accountability for the credentials, scripts, and build paths each team controls. If no one owns the runtime trust boundary, detection becomes fragmented and response slows. The accountable team is the one that can approve, revoke, or isolate the compromised asset.

Technical breakdown

Why build-time dependency scanning misses client-side compromise

Traditional software composition analysis reviews manifests, lockfiles, and package trees to identify known vulnerable components before deployment. That works for declared dependencies, but it does not observe what happens after a page loads or a pipeline promotes code into production. A compromised CDN, injected tag, or malicious third-party script can bypass pre-deployment checks entirely because it is not represented in the inventory the scanner reviewed. The result is a gap between what security teams believe is present and what users’ browsers actually execute.

Practical implication: extend control coverage from declared dependencies to runtime observation of executed scripts and delivered assets.

How client-side supply chain attacks evade normal appsec controls

Client-side supply chain attacks exploit the browser as an execution environment with access to page content, session signals, and form inputs. The attacker does not need to compromise the core application if they can modify a third-party script, CDN response, or tag manager payload. Because the malicious code runs in the user session, server-side controls such as WAFs, dependency scanners, and build provenance do not see the full behaviour. This is why payment-page skimming and CDN poisoning remain so effective.

Practical implication: treat client-side script inventory and script behaviour as production controls, not optional telemetry.

Why supply chain governance now overlaps with identity and secrets handling

Software supply chains increasingly move secrets, API tokens, and delegated access paths through build systems, developer tools, and browser sessions. That creates an identity problem as much as a software integrity problem, because exposed credentials can be used to impersonate services, access pipelines, or pivot into downstream systems. When a compromised script can observe input or a poisoned build can leak credentials, the boundary between application security and identity governance disappears. The control question becomes who and what is trusted to act in the software delivery chain.

Practical implication: map secret exposure, script trust, and service identity ownership into one governance model.

Threat narrative

Attacker objective: The attacker wants to turn a trusted delivery channel into a scalable path for credential theft, data exfiltration, or silent manipulation of user sessions.

1. Entry occurs when a trusted dependency, build system, CDN asset, or third-party script is compromised before or after deployment.
2. Escalation happens when injected code executes in the browser or pipeline with the privileges of the trusted integration point.
3. Impact follows when the malicious component steals secrets, skims data, or alters application behaviour across many downstream sessions.

NHI Mgmt Group analysis

Software supply chain failures are now an identity-adjacent governance problem, not just an appsec category. The article makes clear that build integrity alone does not protect the software delivery chain once secrets, scripts, and delegated access are present at runtime. That matters because identity controls fail when trust is granted to components that can change outside normal review windows. Practitioners should treat software delivery as a governed trust chain, not a static dependency list.

Client-side runtime visibility is the named concept the industry has been missing. The useful distinction is not simply server-side versus client-side code, but declared code versus executed code. Security teams can scan manifests all day and still miss injected tags, compromised CDN content, or dynamic third-party payloads in the browser. The practical conclusion is that organisations need controls that monitor behaviour after deployment, because that is where many supply chain attacks now live.

The strongest supply chain programmes will increasingly look like identity governance programmes. When service credentials, tokens, and browser-executed scripts all participate in the same delivery path, accountability has to span software engineering, security operations, and identity ownership. That aligns closely with NIST CSF and OWASP Non-Human Identity Top 10 thinking, because trust boundaries must be explicit. Practitioners should collapse the gap between application security and identity governance before adversaries do it for them.

OWASP’s category shift signals a market correction toward runtime control, not more static scanning. The consensus behind A03 shows practitioners no longer see patching and SBOMs as sufficient answers. The next phase of the market will reward tools and programmes that can prove what is running, not just what was intended to run. Teams should re-evaluate whether their current controls can observe execution, not just inventory code.

What this signals

Client-side supply chain risk is becoming a governance baseline, not an edge case. Security teams that still separate code scanning, script monitoring, and identity governance will miss the way modern delivery chains blend them together. The immediate programme signal is to extend visibility into runtime execution and tie it to secrets handling, privileged build access, and third-party script ownership.

Runtime inventory will become a control expectation rather than a mature-option capability. The organisations that can prove what executes in the browser, what can read user input, and which third parties can alter code paths will have a materially better risk posture than teams relying on quarterly attestations. This is where OWASP Non-Human Identity Top 10 thinking becomes useful: trust must be explicit, scoped, and revocable.

Security leaders should expect more overlap between application security and identity governance roadmaps. As software supply chain failures expand into browser runtime and delegated access, teams will need shared policies for secret exposure, script trust, and privileged pipeline access. The programmes that close that gap early will be easier to audit and harder to bypass.

For practitioners

• Inventory executed scripts, not just declared dependencies Maintain a continuously updated record of every first-party and third-party script that actually runs in production browsers, including tags loaded dynamically after page render. Use that inventory to identify unapproved runtime changes and scripts that can access session or form data.
• Add runtime behaviour controls to client-side governance Monitor what scripts do after load, including access to DOM elements, form fields, and network destinations. Where possible, block unauthorised behaviours without removing legitimate scripts so you can reduce risk without breaking site functionality.
• Map secrets and delegated access paths across the delivery chain Trace where API keys, tokens, and service credentials enter build systems, package registries, tag managers, and browser-delivered code. Classify which identities can alter or observe those assets and remove standing trust where it is not required.
• Reconcile appsec controls with identity governance Bring application security, IAM, and NHI owners into the same review process for supply chain risk so that credential exposure, script trust, and privileged build access are assessed together rather than in separate silos.

Key takeaways

• OWASP’s 2025 Top 10 shows that software supply chain failures have moved from dependency hygiene into runtime trust and execution risk.
• The practical blind spot is client-side code, where third-party scripts and injected payloads can bypass build-time scanning and still access live sessions.
• Security teams should align runtime script governance with identity and secrets control if they want supply chain assurance to mean anything in production.

Key terms

• Software Supply Chain Failure: A software supply chain failure is any breakdown in the build, dependency, signing, or distribution chain that allows tampering, compromise, or unauthorized access. For NHI security, the concern is not only corrupted code but also the credentials and machine identities that move that code through the pipeline.
• Client-Side Code Exposure: Client-side code exposure is the security condition that arises when logic, configuration, or sensitive values are delivered to the browser and become visible to users and attackers. It matters because anything shipped to the client must be treated as inspectable, copyable, and potentially modifiable.
• Third-Party Script Trust: The assumption that external scripts loaded into a page or application are safe to execute and access data. In practice, this trust is fragile because the script, its hosting location, or the chain that delivers it can be modified without the application owner immediately noticing.
• Delivery Chain Governance: The discipline of assigning ownership, monitoring, and revocation rights across the software path from commit to execution. It matters because build systems, CI/CD platforms, tag managers, CDNs, and browser-delivered assets all participate in the trust boundary.

What's in the full article

Jscrambler's full article covers the operational detail this post intentionally leaves for the source:

• Runtime script integrity controls for browser-executed third-party code
• How Webpage Integrity maps to payment-page monitoring and PCI DSS requirements
• First-party JavaScript protection with polymorphic obfuscation and anti-tampering
• The article's observations on data governance implications for user input and session signals

👉 Jscrambler’s full post covers runtime script monitoring, client-side controls, and the data governance implications of browser-executed code.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a structured way to connect identity control to the wider security programme.