The conversation about 5G security has been dominated by geopolitics. Which countries should build the hardware, which vendors to trust, how to prevent espionage. These are valid concerns. But they've overshadowed a more fundamental issue: 5G networks are, at their core, software platforms, and they carry all the supply chain risks that come with modern software development.
Previous generations of mobile networks ran on purpose-built hardware with proprietary firmware. 5G is different. The 5G core network is designed to run as software on commodity hardware, using containers, microservices, and cloud-native patterns. This is a massive improvement for flexibility and cost. It's also a massive expansion of the software supply chain attack surface.
The Open-Source Foundation of 5G
Modern 5G implementations lean heavily on open-source software. The Open RAN (Radio Access Network) movement is pushing to disaggregate the radio stack into open, interoperable components. Projects like O-RAN Software Community, ONAP (Open Network Automation Platform), and various Linux Foundation projects provide the building blocks.
Each of these projects has its own dependency tree. ONAP alone has hundreds of microservices, each with dozens of dependencies. A vulnerability in any of these dependencies is a vulnerability in the 5G network.
The 5G core network functions, like the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF), are increasingly implemented as containerized microservices. They run on Kubernetes, use standard service meshes, and depend on the same container base images and runtime libraries as any other cloud-native application.
This means the 5G core network is subject to every container supply chain risk that exists in enterprise cloud: base image vulnerabilities, compromised packages, malicious container registry entries, and vulnerable orchestration components.
Network Function Virtualization Supply Chains
Network Function Virtualization (NFV) replaces dedicated network appliances with software running on standard servers. A firewall that was once a physical box is now a virtual machine or container. The supply chain shifts from hardware components to software dependencies.
Virtual Network Functions (VNFs) from different vendors must interoperate. This means shared libraries, standard APIs, and common runtime environments. A vulnerability in a widely-used VNF framework affects every network function built on it, across multiple vendors.
The orchestration layer that manages these VNFs (typically based on ETSI MANO architecture) is itself a complex software system with its own dependencies. Compromising the orchestrator gives an attacker control over the entire network function lifecycle: deployment, scaling, configuration, and termination.
Specific Supply Chain Risks in 5G
Multi-vendor integration complexity. Open RAN's promise is vendor interoperability. But each vendor's components bring their own supply chains. When you assemble a 5G network from five different vendors' components, you're accepting five separate dependency trees, each with its own vulnerability surface. Integration testing typically focuses on functionality, not supply chain security.
Firmware update mechanisms. Radio units and baseband processors still require firmware. The update mechanisms for these components are often opaque, using vendor-specific protocols with limited verification. A compromised firmware update for widely-deployed radio units could intercept or manipulate mobile traffic at scale.
Subscriber data exposure. 5G core functions handle subscriber identity, location, and traffic. A supply chain compromise that reaches these functions could enable mass surveillance, traffic interception, or denial of service for entire city populations.
Network slicing trust boundaries. 5G network slicing creates logically separate networks on shared infrastructure. A supply chain compromise in the slicing management layer could break isolation between slices, allowing an attacker on a low-priority slice to access a critical infrastructure slice.
Edge computing integration. 5G and edge computing are deeply intertwined. Multi-access Edge Computing (MEC) platforms run at the network edge, processing data before it reaches the core. These platforms run software with their own supply chains, creating additional entry points.
The Standards Gap
5G standards (3GPP specifications) define security requirements for network interfaces and protocols but say relatively little about software supply chain security. The assumption is that implementations are secure, but the standards don't mandate SBOM generation, dependency scanning, or supply chain verification for network functions.
This gap means that a 5G deployment can be fully compliant with 3GPP security specifications while running network functions built on vulnerable dependencies.
Industry groups are starting to address this. The GSMA has published guidelines on network equipment security, and some operators are imposing supply chain requirements on vendors. But adoption is uneven, and smaller operators often lack the leverage or expertise to demand supply chain transparency from major vendors.
What Needs to Change
SBOM requirements for network functions. Every network function deployed in a 5G network should come with a complete SBOM. Operators should be able to query this data when vulnerabilities are disclosed and understand their exposure within hours, not weeks.
Vendor supply chain audits. Operators should audit their vendors' software development practices, including how they manage open-source dependencies, how they handle vulnerability notifications, and how quickly they produce patched releases.
Continuous monitoring. 5G networks need the same continuous dependency monitoring that enterprises apply to their application portfolios. When a critical vulnerability is found in a library used by a core network function, the operator needs to know immediately.
Standardized security testing. The O-RAN Alliance and similar bodies should develop supply chain security testing requirements that go beyond functional interoperability testing.
Runtime integrity monitoring. Deployed network functions should be continuously verified against known-good baselines. Any deviation from expected software composition should trigger alerts.
How Safeguard.sh Helps
Safeguard.sh provides the supply chain visibility and policy enforcement that 5G networks need. By generating and managing SBOMs for network functions and their complete dependency trees, Safeguard.sh enables operators to understand exactly what software runs in their infrastructure.
Our continuous monitoring capabilities alert operators when vulnerabilities are found in any component of their network function supply chain, not just the components they directly manage. Policy gates can enforce minimum security standards for any software entering the network, from core network functions to edge computing applications. For telecom operators building or operating 5G networks, Safeguard.sh provides the supply chain security layer that current standards don't yet require but operational reality demands.