Telecom operators spent the last decade tearing purpose-built hardware out of their networks and replacing it with software running on commodity servers and Kubernetes clusters. That shift — network function virtualization (NFV) paired with Open RAN's disaggregated, multi-vendor radio stack — cut costs and unlocked faster feature rollout. It also quietly turned the mobile network into a software supply chain problem. A 5G core or radio access network today is assembled from hundreds of open-source packages, container base images, and third-party virtualized network functions (VNFs), each pulled from a registry or repository the operator does not control. 5G NFV supply chain risk is no longer a theoretical concern raised at standards meetings — it is the practical reality of running critical infrastructure on code nobody fully audits before deployment. This post breaks down where that risk actually lives, why Open RAN makes it worse, and what operators and vendors can do about it.
What is 5G NFV supply chain risk, exactly?
5G NFV supply chain risk is the exposure created when network functions that used to run on dedicated, vendor-sealed appliances are re-implemented as software — VNFs and cloud-native network functions (CNFs) — assembled from third-party code, open-source libraries, and container images pulled from external registries. A single vendor's virtualized EPC or 5G core release can depend on a few hundred to over a thousand open-source packages once you count transitive dependencies in the container base images, orchestration layer (Kubernetes, Helm charts), and the NFV MANO (management and orchestration) stack itself. Every one of those packages is a potential entry point: a compromised maintainer account, a typosquatted package, or an unpatched CVE sitting three layers deep in a base image. Unlike a hardware appliance with a fixed bill of materials, a cloud-native network function's dependency graph changes with nearly every CI/CD build, which means the attack surface is not static — it is re-created on every release.
How does Open RAN's multi-vendor model expand the attack surface?
Open RAN expands the attack surface by deliberately splitting what used to be one vendor's sealed radio unit into interoperable components — RU, DU, CU, RIC (RAN Intelligent Controller), and xApps/rApps — built by different vendors and connected over open interfaces defined by the O-RAN Alliance (founded in 2018 by AT&T, Deutsche Telekom, NTT DOCOMO, China Mobile, and Orange). That disaggregation is the whole point of Open RAN: it breaks vendor lock-in and lets operators mix best-of-breed suppliers. But it also means an operator's RAN security posture is only as strong as the weakest link across potentially five or more independent software supply chains feeding a single cell site, plus the RIC's third-party xApp marketplace, which is explicitly designed to let outside developers deploy code with access to real-time radio control data. The Enduring Security Framework — a joint NSA/CISA public-private working group — flagged this exact concern in its 2023 Open RAN security guidance, noting that multi-vendor integration increases both the number of trust boundaries and the difficulty of assigning accountability when something goes wrong. Open RAN security therefore has to be evaluated at the level of the whole integrated stack, not vendor by vendor.
What are the most common virtualized network function vulnerabilities?
The most common virtualized network function vulnerabilities fall into three buckets: inherited open-source CVEs, insecure orchestration configuration, and unverified provenance. Because CNFs are built on general-purpose Linux distributions, container runtimes, and shared libraries, they inherit the same vulnerability classes that hit every other cloud-native workload — the December 2021 Log4Shell vulnerability (CVE-2021-44228), for instance, showed up in OSS/BSS and management-plane tooling across multiple telecom vendors' stacks, not because telecom code was uniquely flawed but because Log4j was buried deep in shared Java tooling almost nobody had inventoried. Orchestration-layer misconfiguration is the second bucket: NFV MANO platforms and Kubernetes-based CNF deployments frequently ship with overly permissive service accounts, exposed management APIs, or default credentials in Helm charts — findings that show up repeatedly in operator security assessments of ONAP and OpenStack-based VNF managers. The third and fastest-growing bucket is provenance: VNFs and CNFs assembled from public container registries with no signed software bill of materials (SBOM), meaning an operator often cannot say with confidence which package versions — and which known CVEs — are running in a given network function at a given moment. The 2024 discovery of a deliberately planted backdoor in the widely used xz-utils compression library is a sobering preview of what a targeted upstream compromise of a telecom-adjacent dependency could look like.
Why does telecom cloud-native security need a different playbook than ordinary IT security?
Telecom cloud-native security needs a different playbook because the consequences of compromise are physical, regional, and immediate — a compromised CNF in the 5G core or RAN can affect emergency calling, public safety networks, and critical infrastructure customers riding on the same slice, not just a single enterprise's data. Ordinary enterprise IT can often tolerate a rollback or a few hours of downtime; a carrier-grade network function is held to five-nines availability expectations and regulatory obligations (in the US, CALEA and FCC network reliability rules; in the EU, the NIS2 directive explicitly names telecom as essential infrastructure). That changes the calculus for patching: security teams can't simply push a hotfix to a VNF the way they would a web service, because RAN and core changes go through vendor certification and interoperability testing cycles that can take weeks. This is also why telecom operators have been slower than hyperscalers to adopt continuous dependency scanning and SBOM-driven patching — the tooling built for web-scale DevOps doesn't map cleanly onto NFV MANO, ETSI-defined VNF packaging, or O-RAN's own certification labs. Closing that gap means bringing software supply chain security practices — dependency inventories, signed builds, provenance attestation — into a release process that was designed around hardware certification, not weekly container rebuilds.
Has this risk already caused real incidents, or is it still theoretical?
It is not theoretical — regulators and standards bodies have already responded to concrete, documented exposure. The UK's Telecommunications Security Act (2022) and its accompanying Telecommunications Security Code of Practice specifically call out supply chain risk in virtualized network functions and require providers to maintain oversight of third-party software dependencies. In the US, the FCC's ongoing Covered List actions and the Enduring Security Framework's 2022 and 2023 Open RAN security reports were both prompted by documented gaps: undocumented open-source dependencies in shipped VNFs, insufficient isolation between multi-tenant RIC xApps, and inconsistent vulnerability disclosure practices among smaller Open RAN suppliers competing to get to market. Separately, general-purpose cloud-native incidents have repeatedly demonstrated the mechanism carriers should worry about: Log4Shell in December 2021 forced emergency patching across telecom OSS/BSS estates worldwide within days, and the 2020 SolarWinds compromise showed how a single trusted build pipeline can silently distribute malicious code to hundreds of downstream customers — a scenario directly analogous to a compromised VNF vendor's CI/CD system pushing a poisoned image to every operator using that release.
How Safeguard Helps
Safeguard is a software supply chain tool built for exactly this problem: securing the software supply chain behind the virtualized and containerized workloads that increasingly run critical infrastructure, including 5G NFV and Open RAN deployments. Rather than treating a VNF or CNF release as a black box, Safeguard generates and continuously verifies software bills of materials across the full dependency graph — base images, open-source libraries, orchestration manifests, and the build pipelines that produce them — so operators and vendors can see exactly what is running before it reaches a live network element. Safeguard tracks provenance and build attestation so a signed CNF image can be cryptographically traced back to its source commit and build environment, closing the exact gap that made incidents like the xz-utils backdoor and SolarWinds so hard to catch. For multi-vendor Open RAN environments specifically, Safeguard's continuous monitoring flags newly disclosed CVEs against the components already deployed across RU, DU, CU, and RIC software from different suppliers, correlating known virtualized network function vulnerabilities with what is actually running in production rather than what shipped at certification time. And because telecom cloud-native security has to fit into certification and change-control cycles rather than web-speed deployment, Safeguard integrates into existing CI/CD and NFV MANO pipelines to enforce policy gates — blocking unsigned images, unverified dependencies, or components with known critical CVEs — before they are promoted to production, giving security and network engineering teams a shared, auditable view of supply chain risk across every network function in the stack.