TL;DR: OWASP’s 2025 Top 10 ranked software supply chain failures #3 with 106 first-place votes, a consensus signal that the category has moved beyond patched dependencies to compromised build systems, poisoned pipelines, and client-side runtime risk, according to Jscrambler. The practical shift is clear: visibility must extend from CI/CD inventories into what actually executes in users’ browsers, where conventional appsec controls still leave major blind spots.
At a glance
What this is: OWASP’s latest ranking elevates software supply chain failures into a broader runtime exposure problem, not just a dependency management issue.
Why it matters: IAM, NHI and application security teams need to treat build provenance, third-party script governance and browser runtime visibility as one control surface.
By the numbers:
- Software Supply Chain Failures received 106 first-place votes out of 212 respondents in OWASP’s 2025 Top 10 update.
- OWASP surveyed 225 security practitioners for the 2025 Top 10 update.
Context
Software supply chain risk is now a governance problem as much as a build integrity problem. Security teams have long focused on patched dependencies and signed artifacts, but that model misses what happens after deployment, especially when third-party code executes inside the browser with access to user sessions and page data.
The article argues that the boundary between CI/CD security and runtime security has blurred. That matters for identity and access programmes because third-party scripts, tokens, service integrations and non-human identities can all become part of the trust chain that determines what code can do at runtime.
Key questions
Q: What breaks when software supply chain controls are not built into DevSecOps pipelines?
A: When supply chain controls sit outside the pipeline, teams lose visibility into what actually enters builds, and malicious or vulnerable dependencies can pass through as trusted inputs. The result is delayed detection, weaker release governance, and a false sense of security around applications that depend heavily on third-party code.
Q: Why do browser-executed third-party scripts create supply chain risk?
A: Because they run inside the user’s session with access to page content, form fields and behavioural signals. That means the script is not just delivered content. It is governed code with real runtime privileges, so compromise can become data theft or session manipulation.
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: When should organisations prioritise runtime script governance over dependency scanning?
A: When customer-facing pages rely on third-party tags, CDNs or browser-loaded content that can change independently of the release pipeline. In that situation, dependency scanning remains necessary, but runtime governance becomes the control that protects the live attack surface.
Technical breakdown
Why software supply chain risk now includes browser runtime
Software supply chain security traditionally focused on manifests, dependency trees and build provenance. That approach helps with known vulnerable components, but it does not see injected scripts, swapped CDN resources or third-party tags that appear only after deployment. In browser-heavy applications, the effective supply chain continues into runtime because code executed in the client inherits the user’s trust context and can read or alter sensitive page content. This is why runtime exposure has become a separate control problem rather than a subcase of dependency scanning.
Practical implication: Inventory and monitor the scripts that execute in production, not just the packages that were approved at build time.
Why CI/CD controls miss client-side compromise
CI/CD security tools work from declared assets, which means they are excellent at checking what should ship. They are weaker at detecting what an attacker or vendor update introduces later through dynamic loading, tag managers or remote resources. This creates a blind spot where the build pipeline looks clean while the live page is already executing unapproved code. For identity teams, the same pattern appears when delegated access or machine credentials are reviewed at issuance but not governed once third-party execution begins.
Practical implication: Pair build-time validation with real-time script governance and behavioural monitoring in production.
How client-side third-party code expands the trust boundary
Third-party scripts running in a browser are not passive assets. They can read form fields, observe user behaviour, load additional resources and exfiltrate data through ordinary page interactions. That makes them part of the application trust boundary, even when they are delivered through external vendors or CDNs. The governance challenge is not just whether a script is known, but whether its behaviour matches the access it has been granted inside the browser session. This is where conventional software supply chain thinking stops too early.
Practical implication: Treat browser-executed third-party code as governed runtime access and apply least-privilege controls to what it can observe or change.
Threat narrative
Attacker objective: The attacker aims to turn trusted software distribution and browser execution paths into a scalable path for code execution, data theft or session compromise.
- Entry begins when a trusted dependency, build pipeline or third-party browser script is compromised upstream rather than through the application server itself.
- Credential or execution access is gained through the trust that browsers, CI/CD systems and page workflows already extend to shipped code and loaded resources.
- Impact follows when the altered component executes inside user sessions, enabling data theft, page manipulation or large-scale compromise across downstream applications.
Breaches seen in the wild
- Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Runtime exposure is now the real supply chain problem: the category no longer ends at dependency hygiene or signed builds. Once third-party code executes in the browser, security ownership shifts to behaviour, trust scope and live control. Practitioners should stop treating client-side execution as a presentation-layer detail.
Software supply chain governance and identity governance are converging: third-party scripts, delegated access paths and non-human identities all create trust relationships that outlive the build pipeline. If the organisation cannot answer who or what can execute inside a user session, it does not yet have control of the supply chain boundary.
Build assurance without runtime assurance creates false confidence: a clean SBOM or dependency scan cannot detect a malicious script injected after deployment or loaded dynamically through a tag manager. The named concept here is browser runtime exposure, the gap between approved software and what actually runs. Practitioners should govern that gap explicitly.
Client-side supply chain risk is now an application security and data governance issue: scripts can read personal data, payment fields and behavioural signals in real time. That means the security team and the privacy or data governance team are looking at the same exposure from different angles. Organisations should align controls so that runtime script behaviour is reviewed as a governed access path.
OWASP’s ranking is a signal of operational consensus, not theory: when practitioners elevate this category so sharply, it usually means the failure mode is already visible in the field. The response should be to close the oversight gap between what is approved, what is deployed and what is actually executed. Practitioners need a runtime control model, not a static inventory model.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: AI Supply Chain Security and AI-BOM Guide
What this signals
Browser runtime exposure: the category now includes everything that executes in the client after deployment, which means security teams need a control model that follows live behaviour instead of release artefacts. That shift matters because third-party tags, CDNs and injected scripts can alter session trust without changing the approved build.
The governance question is no longer whether the dependency tree was clean at release. It is whether production pages still behave as expected once third-party code, dynamic loading and user-specific rendering have taken over. That is a materially different operational problem for application security and identity governance teams.
The broader signal for practitioners is that build-time security and runtime security now have to be managed as one chain. If the browser is part of the supply chain, then the monitoring plane has to extend there as well, especially for pages handling credentials, payments or personal data.
For practitioners
- Map the browser script estate Build a continuously updated inventory of every first-party and third-party script executing on high-risk pages, including tag managers and dynamically loaded resources.
- Monitor script behaviour at runtime Detect unauthorized modifications, data access patterns and suspicious script actions after deployment, not only at scan time or during release approval.
- Separate build assurance from execution assurance Keep SBOM and dependency scanning in place, but add runtime controls that confirm the live page matches the trusted build and its intended behaviour.
- Review third-party access as governed runtime access Treat third-party scripts and related non-human access paths as part of the trust boundary, with explicit approval for what they may read, load or modify.
Key takeaways
- Software supply chain risk now extends beyond dependency management into the runtime behaviour of code that executes in users’ browsers.
- The article’s central signal is that build-time assurance alone cannot see injected scripts, dynamic loaders or third-party resources that change after deployment.
- Practitioners need continuous inventory, runtime monitoring and governed access controls for client-side code if they want supply chain controls to hold in production.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and SLSA set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Injected scripts and swapped browser resources reflect runtime misconfiguration and control gaps. |
| Recommendation — Harden production script governance to prevent unauthorized runtime changes and unauthorised resource loading. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The article is about securing software supply chains and live application code. |
| Recommendation — Extend application security controls into production script inventory and runtime monitoring. | ||
| NIST CSF 2.0 | PR.DS-08 — Integrity of software, firmware and information is protected | Runtime script integrity and build provenance are central to the article’s risk model. |
| Recommendation — Protect software integrity from build through browser execution and verify live behaviour continuously. | ||
| MITRE ATT&CK | TA0003;TA0004;TA0010 — Persistence; Privilege Escalation; Exfiltration | The article discusses adversary paths from supply-chain compromise to runtime abuse and data theft. |
| Recommendation — Map supply chain compromise to persistence, escalation and exfiltration detections across the release pipeline. | ||
| SLSA | L3 — Build Integrity | Build provenance and tamper resistance are directly relevant to the compromised pipeline examples. |
| Recommendation — Apply SLSA-aligned provenance checks to reduce build tampering and downstream package compromise. | ||
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.
- Browser Runtime: The live execution environment inside a web browser where scripts, tags, and application code interact with data and user actions. It is the place where client-side privileges are exercised, which makes it a critical enforcement boundary for privacy and identity governance.
- Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.
- Client-Side Supply Chain: The set of third-party scripts, tags, widgets, and browser-delivered services that execute alongside first-party code. It matters because each component can observe or transmit data in-session, creating a runtime trust problem that contracts alone do not solve.
Deepen your knowledge
The NHI Foundation Level course covers NHI governance, machine identity security, IAM and secrets management in a practitioner-focused format. It helps security teams connect identity controls to wider trust boundaries across modern application environments.
Published by the NHIMG editorial team on August 20, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org