Safeguard
Software Supply Chain Security

Software supply chain security for telecom network infras...

Why telecom network software supply chain security demands continuous SBOMs and vendor risk oversight — from 5G base stations to core networks — and how carriers are closing the gap.

James
Principal Security Architect
7 min read

Telecom carriers run some of the most consequential software on earth — the code that routes 911 calls, authenticates SIM cards, and steers 5G traffic between cell towers and core networks. Yet that code is rarely built from scratch. A single radio access network deployment can pull in firmware from three or four hardware vendors, open-source Linux kernels, third-party protocol stacks, and orchestration software from cloud partners, all stitched together under intense delivery pressure. Telecom network software supply chain security is the discipline of knowing what's actually inside that stack, verifying it hasn't been tampered with, and catching compromised components before they reach production network elements. The stakes are different from a typical enterprise: a backdoor in a base station doesn't just leak data, it can take down emergency communications for an entire region. Below, we break down why this problem has become urgent, what regulators are now demanding, and how carriers and vendors are closing the gap.

What Is Telecom Network Software Supply Chain Security?

Telecom network software supply chain security means having verified visibility into every software component — commercial, open-source, and vendor-proprietary — that runs across a carrier's radio access network (RAN), core network, and operational support systems, plus the ability to prove that none of it has been altered in transit. In practice this covers the firmware flashed onto a cell site router, the Linux distributions underlying a 5G core's containerized network functions, the OSS/BSS billing platforms, and even the build pipelines that vendors like Ericsson, Nokia, or Mavenir use to compile releases. Telecom networks are unusually exposed because they blend decades-old legacy protocols (SS7, Diameter) with brand-new cloud-native 5G cores, often sourced from dozens of subcontractors. When the U.S. Cybersecurity and Infrastructure Security Agency (CISA) and FBI jointly briefed carriers in late 2024 about a nation-state intrusion campaign, the entry points weren't exotic zero-days — they were unpatched, unmonitored network infrastructure devices that no one had a current software inventory for.

Why Are 5G Network Equipment Vendors a Prime Target for Attackers?

5G network equipment vendors are targeted because their products sit at the physical and logical center of national communications, giving a single implant enormous leverage. Unlike a compromised SaaS app that affects one company, a compromised gNodeB (5G base station) image or a tampered core network function can be replicated across thousands of cell sites through the vendor's own software update mechanism — turning trusted distribution channels into attack infrastructure, exactly as happened with SolarWinds' Orion updates in 2020. This is why the FCC's Covered List, first published in 2021 and expanded since, bars carriers from using federal subsidy dollars on equipment from vendors deemed national security risks, including Huawei and ZTE. It's also why the 2024 "Salt Typhoon" intrusions — in which state-linked actors reportedly accessed systems at multiple major U.S. carriers, including lawful-intercept infrastructure — became a wake-up call: investigators found the actors moved through routers and network infrastructure that had known, unpatched vulnerabilities sitting in production for months.

How Many Software Components Are Actually Hiding Inside a Single Base Station?

A modern 5G base station or core network function can easily contain hundreds to well over a thousand distinct open-source and third-party components once you count operating system packages, protocol libraries, and container base images. Vendors rarely build this software in-house from the ground up; a typical containerized 5G core network function might layer a Linux base image, a handful of Kubernetes operators, open-source crypto libraries, and vendor middleware — each with its own patch cadence and each capable of introducing a known CVE the carrier never sees. The March 2024 discovery of a deliberately planted backdoor in XZ Utils, a compression library embedded deep in countless Linux distributions, illustrated exactly this risk: a component so ubiquitous and so far downstream that almost no operator using it in a telecom OS image would have known it was there without an SBOM to check against. Telecom operators that lack a component-level inventory are, in effect, running infrastructure they cannot fully account for.

What Does Telecom Vendor Risk Management Actually Require in 2026?

Telecom vendor risk management in 2026 requires continuous, evidence-based verification of vendor software — not the point-in-time security questionnaires that dominated the last decade. Regulators have made this explicit: the UK's Telecommunications Security Act 2021, with obligations phased in through the Telecommunications Security Code of Practice, requires providers to understand and manage risks in vendor-supplied equipment and software across its lifecycle, with the largest carriers facing full compliance milestones through 2028. In the EU, the NIS2 Directive's transposition deadline of October 17, 2024 extended supply-chain risk-management obligations directly to telecom operators, requiring them to assess suppliers' secure development practices, not just their own. That shift matters because a questionnaire answered once a year can't catch a vendor pushing a compromised patch six months later. Effective telecom vendor risk management now means continuously ingesting vendor SBOMs, correlating them against live vulnerability feeds, and requiring cryptographic attestation that a given firmware build matches what was actually tested — turning vendor oversight from an annual audit exercise into an always-on control.

Can a Carrier-Grade Software SBOM Really Prevent the Next Network Outage?

A carrier-grade software SBOM can't prevent every outage, but it collapses the response time from weeks to hours when a critical vulnerability drops — which is often the difference between a contained incident and a cascading one. When Log4Shell was disclosed in December 2021, most large enterprises spent 4-6 weeks just identifying which applications used the vulnerable library; telecom operators, running vendor black-box appliances with no component manifests, often took even longer, because the vulnerable code was buried inside firmware they didn't control and couldn't inspect. A carrier-grade SBOM — one built to handle the scale of thousands of network elements, firmware variants, and vendor releases rather than a handful of web apps — lets a security team query "which of our 40,000 deployed radio units contain this vulnerable library" and get an answer in minutes. That's not a hypothetical convenience; it's the operational difference between isolating a handful of affected cell sites and having to assume your entire RAN footprint is exposed while you wait on vendor confirmation.

How Safeguard Helps

Safeguard gives telecom operators and network equipment vendors a single, verifiable source of truth for every software component running across their infrastructure — from cloud-native 5G core functions down to RAN firmware. Instead of relying on vendor-provided PDFs or annual attestations, Safeguard continuously generates and validates SBOMs across build pipelines, correlates them in real time against emerging CVEs and known exploited vulnerability catalogs, and flags unauthorized or tampered components before they ship to production network elements. For telecom vendor risk management, Safeguard lets security and compliance teams track supplier software posture continuously rather than point-in-time, mapping directly to NIS2, the UK Telecommunications Security Act, and CISA's telecom sector guidance. And because Safeguard is built to operate at carrier scale, it handles the reality of thousands of firmware variants and network elements without collapsing into spreadsheet chaos — giving operators the fast, component-level answers that turn the next XZ Utils or Log4Shell-style disclosure into a controlled response instead of an all-hands scramble. If you're responsible for securing telecom network infrastructure, Safeguard can show you exactly what's running in your network today, and prove it hasn't been altered since it left the vendor's build system.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.