TL;DR: OWASP’s 2025 Top 10 now places software supply chain failures at number 3, after the community ranked the issue first with exactly 50% of respondents, while third parties were responsible for a third of breaches in Verizon’s 2025 DBIR, according to ColorTokens. Microsegmentation can reduce blast radius, but it does not remove upstream dependency risk or lifecycle control gaps.
At a glance
What this is: This article argues that software supply chain failures have moved into OWASP’s 2025 Top 10 and that microsegmentation is a compensating control for limiting blast radius, not a fix for upstream dependency weakness.
Why it matters: It matters because IAM, PAM, and NHI programmes increasingly have to govern third-party software and machine connections as part of the attack surface, not just user access.
By the numbers:
- Software supply chain failures were ranked number 3 in OWASP’s proposed 2025 Top 10 after exactly 50% of respondents placed the issue first.
- Third parties were responsible for a third of breaches in Verizon’s 2025 Data Breach Investigations Report.
Context
Software supply chain failure is a governance problem as much as a technical one. When upstream components, build artefacts, or third-party dependencies are compromised, the resulting risk extends beyond patching into containment, segmentation, and access scope. In identity terms, those dependencies often behave like non-human identities because they authenticate, connect, and move data without human review at runtime.
The article’s core argument is that microsegmentation can limit lateral movement and shrink blast radius when vulnerable third-party software cannot be immediately replaced or patched. That does not remove dependency risk, but it changes how security teams manage exposure while lifecycle fixes are still pending.
Key questions
Q: What breaks when vulnerable software is left unpatched or poorly prioritized?
A: Unpatched vulnerabilities let attackers use known weaknesses to gain control, move laterally, and compromise data or services at scale. In practice, the failure is usually not a single flaw but the combination of missed visibility, slow remediation, and weak prioritization. That gap turns routine defects into persistent exposure across applications, users, and third-party dependencies.
Q: Why do software supply chains create a higher risk of lateral compromise than isolated applications?
A: Software supply chains connect code, build systems, third-party dependencies, and update channels, so one weak point can affect many downstream customers or environments. That interconnectedness gives attackers more leverage than a single application flaw. Security teams should assume compromise can propagate across trust boundaries and design controls for dependency verification, integrity checks, and release review.
Q: What are the signs that microsegmentation is failing to contain supply chain exposure?
A: The warning signs are broad reachability, unrestricted east-west traffic, and vulnerable components that can still contact systems outside their intended scope. If a compromised library or host can laterally probe multiple services, the segmentation policy is too permissive. Good containment should leave only the minimum required upstream and downstream paths open.
Q: Should teams prioritise segmentation or replacement for vulnerable third-party components?
A: They should do both, but not confuse them. Replacement addresses the root cause, while segmentation reduces exposure while replacement is delayed or impossible. If the component is unmaintained or cannot be updated safely, containment becomes the immediate control, but it should never become the permanent excuse for leaving the dependency in place.
Technical breakdown
Why software supply chain failures create blast-radius problems
Software supply chain failures occur when a dependency, update path, build artefact, or distributed component is compromised before it reaches production. The operational issue is not only trust in code, but trust in the path that delivers and runs the code. Once a vulnerable library or malicious update is present, every system that consumes it can inherit the same exposure unless connections, execution paths, and east-west reachability are constrained.
Practical implication: Treat dependency trust as a runtime control problem, not only a build-time assurance problem.
How microsegmentation limits lateral movement around vulnerable software
Microsegmentation breaks broad network reachability into tightly scoped communication paths. In practice, that means a compromised component or host cannot freely talk to every adjacent system, which reduces attacker mobility after initial compromise. The control is strongest when paired with least privilege and explicit allowlists for known upstream and downstream dependencies. It does not cleanse the vulnerable software, but it can confine the damage while remediation is underway.
Practical implication: Use segmentation to confine known vulnerable systems to the smallest possible communication set.
Why patching alone is not enough for unmaintained or unupdateable components
Some supply chain failures persist because the affected component is end of life, unmaintained, or technically impossible to update quickly. In those cases, patch-first strategies become unrealistic, especially in operational technology and legacy environments with long refresh cycles. Microsegmentation becomes a compensating control that buys time, but the governance challenge remains: teams still need inventory, exposure visibility, and a replacement plan for the dependency itself.
Practical implication: Combine exposure reduction with asset inventory and retirement planning for unmaintained dependencies.
Threat narrative
Attacker objective: The attacker aims to turn one compromised dependency or update path into broader execution, lateral movement, or multi-system access.
- Initial exposure occurs when vulnerable third-party software, an obsolete function, or an unmaintainable component is present in the environment and reachable by other systems.
- Escalation happens when the affected component can be used to execute code or access adjacent resources across overly broad trust boundaries.
- Impact follows when the compromise spreads laterally, allowing attackers to extend control beyond the original vulnerable workload or software path.
Breaches seen in the wild
- 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.
- LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
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
Software supply chain failures are now an access-governance problem, not just a build-assurance problem. The article correctly places third-party dependency risk alongside OWASP’s evolving view of the attack surface. For identity teams, the important shift is that software components and update channels increasingly behave like privileged non-human actors because they can alter runtime behaviour without human approval. Practitioners should govern that trust boundary explicitly.
Microsegmentation is a blast-radius control, not a dependency-control strategy. It can slow propagation after a vulnerable package, obsolete function, or unmaintainable component is exploited, but it does not remove the upstream weakness. That distinction matters because security programmes often overstate the value of containment when the real gap is inventory, ownership, and lifecycle enforcement. The right conclusion is to use segmentation as a compensating control, not as a substitute for remediation.
Third-party software risk is converging with non-human identity governance. When applications, libraries, and update mechanisms are trusted to act inside production environments, they occupy a governance space similar to service identities and machine credentials. That means access scope, provenance, and revocation logic all matter. The practitioner takeaway is to align software supply chain controls with NHI governance patterns rather than treating them as separate disciplines.
OWASP’s new category signals that upstream trust has become a board-level exposure metric. The article shows why teams can no longer discuss dependency risk only as vulnerability management. The material question is whether the environment can contain the failure when patching is delayed, impossible, or incomplete. Practitioners should measure how quickly they can reduce reachable blast radius for high-risk dependencies.
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: Ultimate Guide to NHIs — Standards
What this signals
Dependency containment is becoming part of identity governance. When software components and update channels can act with production reach, they need the same discipline that teams apply to service identities: scope, ownership, and revocation. Microsegmentation helps shrink the reachable surface, but the governance win comes from knowing exactly which upstream dependencies can touch which downstream systems.
OWASP’s inclusion of software supply chain failures confirms that upstream trust has become a primary control question. Security teams should expect more scrutiny on where third-party software can execute, communicate, and persist in production. The practical response is to build containment decisions into architecture reviews rather than waiting for a vulnerability to force them.
Blast-radius control now sits alongside patching as a core supply chain metric. According to the Ultimate Guide to NHIs 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. Teams should treat that exposure pattern as a warning that dependency governance and NHI governance are converging in the same operational risk surface.
For practitioners
- Map vulnerable dependencies to communication paths Identify which third-party libraries, update services, and unmaintainable components can talk to which internal systems, then remove any unnecessary east-west reachability.
- Apply segmentation to unpatchable assets Place legacy or technically unupdateable components into tightly restricted network segments so only known upstream and downstream connections remain permitted.
- Pair least privilege with dependency containment Restrict service and workload access so a compromised component cannot reuse broad trust to move laterally across the environment.
- Track retirement for end-of-life components Maintain an inventory of third-party software that is no longer maintained and give it an explicit exit plan instead of relying on indefinite compensating controls.
Key takeaways
- Software supply chain failures are no longer a niche build issue. They now represent a governance and containment problem that affects runtime exposure as well as patching.
- The central evidence in the article is that OWASP’s 2025 release candidate ranks the issue number 3 and that third parties were responsible for a third of breaches in Verizon’s 2025 DBIR.
- Microsegmentation can reduce lateral movement and contain blast radius, but it does not remove the upstream dependency weakness that caused the exposure in the first place.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | Third-party software dependencies create the upstream trust risk discussed throughout the article. |
| NHI-05 — Overprivileged NHI | Compromised software only becomes broadly dangerous when it can reach too much of the environment. | |
| Recommendation — Review third-party dependencies for trust and containment gaps before they reach production. Reduce reachable scope so compromised components cannot use excessive access to spread. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The article focuses on how vulnerable dependencies enable attacker movement after compromise. |
| Recommendation — Map exposed dependency paths to credential abuse and lateral movement opportunities. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Microsegmentation is an authorization control over which systems can communicate. |
| Recommendation — Constrain entitlements so vulnerable workloads can only reach approved peers. | ||
| CIS Controls v8 | CIS-5 — Account Management | Third-party and service access paths need ownership and lifecycle oversight in the same way accounts do. |
| Recommendation — Inventory and govern service access paths so stale trust does not persist. | ||
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.
- Microsegmentation: A network control approach that divides environments into small security zones with explicit rules between them. Its purpose is to limit lateral movement and reduce blast radius when an identity, workload, or device is compromised.
- Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.
- Third-Party Application Risk: Third-party application risk is the exposure created when external platforms or delegated services hold sensitive data or connect to critical workflows. The risk is not limited to vendor security. It also depends on how much access the organisation granted and whether that access is still appropriate.
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 for practitioners building stronger access controls. It helps security and identity teams connect identity governance to the broader security decisions their programmes depend on.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org