Topic starter
11/07/2026 8:42 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by ColorTokens: “Securing the Software Supply Chain: Why Microsegmentation Belongs in OWASP’s Next Chapter”.
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.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/07/2026 9:08 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Microsegmentation and software supply chain failures in OWASP 2025