Background
A few weeks ago, I wrote about the findings in Verizon’s 2025 Data Breach Investigation Report, which found that third parties were responsible for a third of breaches. Examples cited included Solar Winds, GitHub, Snowflake, and MOVEit.
Source: Verizon 2025 Data Breach Investigations Report
In that article, I also wrote about using microsegmentation to limit the blast radius of 3rd-party software and about employing Internet security measures, such as a web application firewall (WAF), to defend against DDoS attacks and the risks identified by the OWASP Top Ten project.
Source: Unpacking the Verizon 2025 Data Breach Investigations Report
A Major Shakeup in the OWASP Top 10
The risks posed by third-party software have not been lost on the web security community. According to the OWASP team, software supply chain failures (a more technical term for third-party software issues!) were top-ranked in their community survey, with exactly 50% of respondents ranking it #1.
As a result, the proposed OWASP Top 10 for 2025 now has a new Software Supply Chain Failures category landing at number 3 on the list.
Source: OWASP Top 10: 2025 Release Candidate 1
OWASP defines software supply chain failures as “breakdowns or other compromises in the process of building, distributing, or updating software.” Most often caused by vulnerabilities, the injection of malicious code in third-party software or tools could also cause these failures.
According to OWASP, this new category includes these mapped common weakness enumerations (CWEs):
- CWE‑447: Use of Obsolete Function.
- CWE‑1104: Use of Unmaintained Third-Party Components.
- CWE‑1329: Reliance on Component That is Not Updateable.
- CWE‑1395: Dependency on Vulnerable Third-Party Component.
Let’s deep dive into these CWEs and see how microsegmentation can help as an interim or permanent solution. I say permanent mainly because nothing is more permanent than an interim solution that works!
CWE-447 (Use of Obsolete Function)
This CWE addresses the use of obsolete functions or functions that suggest implementing a particular security feature but are not fully implemented. For example, attackers used obsolete and unsafe printing APIs in the Windows Print Spool service to upload malicious drivers and achieve code execution across domain-joined systems (CVE-2021-34527, aka PrintNightmare).
In situations like this, microsegmentation can be used to isolate affected systems and limit access to them. In conjunction with least-privilege policies, microsegmentation can prevent attackers from using lateral movement to gain access to these vulnerable systems while awaiting a patch from the software vendor.
CWE-1104 (Use of Unmaintained Third-Party Components)
There are often cases in which third-party software components reach the end of life and are no longer maintained. However, it may be difficult to retire or upgrade the product using the unmaintained component, especially in operational technology systems with long refresh cycles.
A recent example of this CWE is the vulnerability (CVE-2024-11999) affecting some Schneider Electric Harmony HMI products. Schneider’s mitigation strategy outlined in their advisory is, in fact, a textbook example of using microsegmentation to reduce the attack surface of a vulnerable system.
CWE-1329 (Reliance on Component That is Not Updateable)
This situation arises when a vulnerability is found in a component, but the vendor deems a fix to be technically infeasible. The component may be un-updatable due to fundamental design choices or trade-offs made during development, or because the tools required are no longer available, among other reasons.
A great example of this is CVE-2022-34381, a widely used cryptographic component from Dell that was flagged as unmaintainable and not safely updateable; a textbook instance of CWE-1329.
As this is a component you cannot update, you can use microsegmentation to place it in a tightly restricted segment. Using Zero Trust policies, you mitigate exposure by allowing only known upstream/downstream connections.
CWE-1395 (Dependency on Vulnerable Third-Party Component)
This is a classic supply-chain weakness where you depend on a third-party component with known vulnerabilities. Some recent examples include CVE-2021-44228 (Log4Shell), CVE-2023-38545 (libcurl), and CVE-2023-4863 (libwebp). In all these cases, patches for the upstream libraries were available, but vulnerable applications continued to ship for several months. Furthermore, patching an entire fleet of servers at once is not practical. Microsegmentation can help isolate systems using the vulnerable component until the developer or security team can apply a patch.
Conclusion
It is very encouraging to see OWASP recognize software supply chain failures and third-party software risk as a significant concern. Patching or system replacement addresses the core issue. Still, microsegmentation offers a compelling compensating control in the interim, or perhaps for the long term, depending on the nature of the vulnerability.
If you want a closer look at how microsegmentation can reduce supply chain risk, connect with us or request a quick demo.
