How a 5G Base Station Is Made: Radios, Baseband, Fronthaul and Timing

A 5G base station (a gNB in 3GPP terms) is a set of boxes joined by standard interfaces: antennas and radio units on the mast, baseband split into a Distributed Unit (DU) and a Central Unit (CU), a fronthaul link carrying radio samples over Ethernet, a timing source good to a microsecond or so, and a large software stack that runs and manages it all. Each part comes from a different supply chain and is secured in a different way.

This post goes one level deeper than our explainers on the 5G core, NFV and Open RAN software supply chain risk, PTP and GPS timing as a hidden dependency. It follows a base station from raw material to a working cell site, then explains how the interfaces are protected and what an operator or private 5G owner should check. Requirements come from 3GPP, the CPRI cooperation, ITU-T, GSMA and guidance from CISA, NSA, the European Union and the UK government. No equipment vendor is named, nothing here is a ranking, and everything is written for defenders who own or run the equipment.

Key takeaways

• A 5G cell site holds antennas or active antenna units, radio units, baseband, power, a site router, backhaul and a timing source. In many networks the baseband is no longer at the site at all; it sits in a hub or a data centre.
• 3GPP TS 38.401 lets a gNB be split into a gNB-CU and one or more gNB-DUs joined by the F1 interface. The CU can be split again into a control plane part and user plane parts joined by E1, which carries signalling only.
• The O-RAN "7.2x" split puts the lower part of the physical layer in the radio unit and carries frequency domain samples to the DU over Ethernet, using eCPRI framing. That link is the Open Fronthaul, with control, user, synchronisation and management planes.
• TDD cells must be phase aligned. 3GPP TS 38.133 requires cell phase synchronisation accuracy better than 3 microseconds between cells with overlapping coverage. GNSS receivers, PTP telecom profiles such as ITU-T G.8275.1 and good holdover oscillators deliver that.
• 3GPP TS 33.501 makes IPsec mandatory to implement on F1 and E1 (with DTLS also supported for the control plane), but whether to use it is the operator's decision. CISA and NSA's Open RAN security considerations stress fronthaul access control, strong management plane authentication, xApp and rApp onboarding, and SBOMs for open source components.
• Most of what runs a modern RAN is ordinary software: Linux, containers, Kubernetes, open source RAN stacks and PTP daemons. Inventory it, keep SBOMs and patch it.

A short timeline of the parts in this post

What is at a 5G cell site?

Walk up to a typical macro site and you see a mast or rooftop frame, a cabinet or two at the base, a power feed and cables running up. What is on the end of those cables has changed a lot since 4G.

The biggest change is where the baseband lives. In a distributed RAN it sits in the cabinet at the foot of the mast. In a centralised RAN, DUs for many sites sit in a hub and fronthaul fibre runs from each mast to it. In a virtualised or cloud RAN, the DU and CU are software on commercial servers, often with an accelerator card for the heaviest physical layer work.

Base station types in the 3GPP radio specification

3GPP TS 38.104 sets the radio transmission and reception requirements for NR base stations and sorts equipment into types by how those requirements are measured. That classification is a good map of the physical forms you see on masts.

Conformance is shown against TS 38.141-1 (conducted testing) and TS 38.141-2 (radiated testing). That split matters for manufacturing: a 1-O or 2-O unit cannot be tested by plugging an analyser into a connector, so the factory needs over the air test chambers.

Massive MIMO and active antenna units

Mid-band 5G is where massive MIMO is common, for example in band n78, which TS 38.104 lists as 3300 to 3800 MHz, TDD. An active antenna unit places a grid of antenna elements behind a radome, wired to many independent transmit and receive chains. Instead of radiating one fixed pattern, the radio applies amplitude and phase weights to each chain so the energy forms beams toward users, and it can serve several users on the same frequency at the same time by sending them different beams.

Power, backhaul and site management

Two things at a cell site are easy to forget: the site router, a general purpose IP device with a management interface, routing protocols and often a boundary clock, and the site controller and power system, which are frequently reachable over the same management network as the radio. Both run firmware that needs inventory and patching.

How is radio hardware made?

A radio unit is a stack of components from different industries, assembled, calibrated and tested by the equipment maker. This is a general description of the stages, not a claim about any one product.

The last two stages before the mast matter most here. Once software and identity are loaded, the hardware is a software asset with a version, a certificate, a management address and an update history, and those are what operators manage for the next decade.

Baseband processing (channel coding, FFTs, channel estimation, MIMO detection, scheduling) can run on FPGAs, custom chips or commercial servers, often in combination. FPGA bitstreams are software and need version tracking; server routes inherit the whole server supply chain of BIOS, BMC, NIC firmware, operating system, container runtime and Kubernetes. The OpenAirInterface 7.2 fronthaul tutorial gives a feel for the server route: it says the network card should support hardware PTP time stamping, notes that demanding configurations need either a CPU clock speed above 4 GHz or an accelerator for layer 1, and lists the operating systems and kernels it was tested on.

How is the gNB split?

CU, DU and RU in 3GPP TS 38.401

3GPP TS 38.401 describes the NG-RAN architecture. The NG-RAN is a set of gNBs connected to the 5G core over the NG interface; gNBs can connect to each other over Xn. A gNB may consist of a gNB-CU and one or more gNB-DUs connected by F1, and one gNB-DU connects to only one gNB-CU (an implementation may connect a DU to several CUs for resiliency). The specification defines the roles precisely:

• The gNB-CU hosts RRC, SDAP and PDCP and controls one or more DUs.
• The gNB-DU hosts RLC, MAC and PHY. One DU supports one or more cells, and each cell is supported by only one DU.
• The gNB-CU-CP hosts RRC and the control plane part of PDCP, and terminates E1 and F1-C.
• The gNB-CU-UP hosts the user plane part of PDCP and SDAP, and terminates E1 and F1-U.

A gNB can have one CU-CP, several CU-UPs and several DUs. NG, Xn and F1 are logical interfaces, and for a split gNB the NG and Xn-C interfaces terminate in the CU, so the rest of the network sees one gNB.

Two security consequences follow. First, PDCP sits in the CU, so air interface ciphering and integrity protection terminate in the CU, not at the mast. Below the CU, user data on F1-U is already ciphered by PDCP when air interface ciphering is on, but F1-C signalling and management traffic need their own protection. Second, F1 carries both signalling and user data, while E1 carries signalling only, as TS 33.501 notes. Both appear in the security specification, covered below.

The O-RAN 7.2x split

3GPP did not standardise an interface between the DU and the radio unit. Historically that link used the CPRI specification, which carried digitised time domain samples over a point to point link and, in practice, tied a radio to the same supplier's baseband. The O-RAN Alliance specifies an Open Fronthaul between an O-DU and an O-RU so that the two can come from different suppliers.

O-RAN chose a split inside the physical layer, called 7.2x. The O-RU does the lower PHY: FFT and inverse FFT, cyclic prefix handling, PRACH filtering and, depending on the radio category, precoding and digital beamforming. The O-DU keeps the upper PHY: channel coding, scrambling, modulation and layer mapping. Frequency domain samples cross the link instead of time domain samples, they can be compressed, and only the subcarriers in use are sent, so the bandwidth needed is far lower than with classic CPRI. That matters a great deal for massive MIMO, where a CPRI style link per antenna chain would be impractical.

Radio units for this split come in two categories. In Category A, precoding happens in the O-DU. In Category B, precoding happens in the O-RU, which reduces fronthaul load further for large arrays. The OpenAirInterface tutorial, for example, says its lab tested Category A radio units.

The four Open Fronthaul planes

CISA and NSA describe the Open Fronthaul as two real time interfaces that move 5G air interface messages, a third that provides timing, and a fourth, not real time, that manages radio configuration and security policy. O-RAN calls these the C, U, S and M planes.

eCPRI framing

eCPRI comes from the CPRI cooperation. It defines a light message format for carrying radio data and real time control over packet networks such as Ethernet and IP, rather than over a dedicated serial link. The cooperation's site lists eCPRI 1.0, 1.1, 1.2 and 2.0 for download, alongside the classic CPRI versions up to 7.0. eCPRI 1.0 was made available on 31 August 2017, and eCPRI 2.0 (announced 10 May 2019) added support for carrying CPRI 7.0 over Ethernet so classic CPRI and eCPRI can interwork. The cooperation also publishes a document on eCPRI transport network requirements. O-RAN's C-plane and U-plane messages reuse the eCPRI transport header and define their own payloads on top.

The practical consequence is that the fronthaul is now a switched Ethernet network with tight latency, jitter and timing requirements, and it must be treated as a sensitive segment: as CISA and NSA put it, an unauthorised device on it could launch denial of service attacks on the RAN.

What software runs a base station?

A modern base station runs more software than most people expect: even an integrated single supplier radio contains an embedded Linux system, a management agent, a PTP stack, FPGA bitstreams and a command line or web interface. A virtualised RAN adds the full cloud stack on top.

The layers of the RAN software stack

The near real time RIC, xApps and rApps

The O-RAN architecture adds RAN Intelligent Controllers. In CISA and NSA's description, xApps run on the Near-Real Time RIC with control loops as low as 10 milliseconds, while rApps run on the Non-Real Time RIC with loops longer than one second and can work with each other through the R1 interface. The two RICs are linked by the A1 interface, for which the guidance recommends mutual authentication and confidentiality and integrity protection, so nobody can snoop on, change or inject policy messages.

xApps and rApps are third party code that can change how the RAN behaves. The guidance names the supply chain challenge directly and calls for secure development guidelines, independent evaluation, vulnerability assessment, SBOMs, software integrity mechanisms and a common approach to secure onboarding. It also flags AI and ML models in the RAN as exposed to data poisoning, and recommends that supervised models are trained offline on known data before deployment.

Cloud native RAN on commercial servers

In a virtualised deployment, CUs and DUs run as virtual machines or containers on commercial servers. The DU workload needs CPU isolation, huge pages, SR-IOV network functions, a polling data plane and a precise PTP feed into the server's network card. In practice that means a Kubernetes cluster at a hub or edge site, a tuned operating system, container images for each RAN function and operators for lifecycle management. CISA and NSA's Open RAN guidance points readers to the NSA and CISA Kubernetes hardening guide, NIST SP 800-190 on container security and NSA and CISA's earlier guidance on 5G cloud infrastructures for this layer.

Open source RAN stacks

Two open source efforts are widely used for research, testing and some private networks.

• OpenAirInterface, run by the OpenAirInterface Software Alliance, publishes 4G and 5G RAN and core software. Its openairinterface5g repository on EURECOM's GitLab was created on 18 June 2015. Its 7.2 fronthaul tutorial makes the S-plane mandatory, uses a configuration with an external grandmaster and a switch acting as a boundary clock (LLS-C3), and runs ptp4l and phc2sys from linuxptp to discipline the server clock.
• srsRAN, from Software Radio Systems, published the srsRAN Project, an open source 5G CU and DU. Its site now says the srsRAN Project has become the OCUDU Project. OCUDU describes itself as a permissively licensed, open source CU and DU project with the full layer 1 to layer 3 stack, hosted by the Linux Foundation's OCUDU Ecosystem Foundation, with its source on GitLab.

These are serious codebases with many third party dependencies, so lab and private network builders who compile them need the same dependency tracking and patching habits as any other software team.

Why do base stations need phase synchronisation?

TDD needs every cell to switch at the same moment

Much of 5G mid-band spectrum, including n78, is TDD: the same frequency carries downlink and uplink at different times. If one cell transmits while its neighbour, or another operator in the adjacent block, is listening, the strong downlink signal swamps the weak uplink signals from phones. So all cells in an area must agree on when each frame starts.

3GPP TS 38.133 states the requirement. Cell phase synchronisation accuracy for TDD is the largest absolute difference in frame start timing between any pair of cells on the same frequency with overlapping coverage, and it must be better than 3 microseconds, measured at the base station antenna connectors or radiated interface boundaries. In practice that is often expressed as every cell staying within 1.5 microseconds of a common reference such as UTC, since two cells each 1.5 microseconds off in opposite directions are 3 microseconds apart.

The ITU-T time error budget

ITU-T G.8271 covers time and phase synchronisation aspects of telecom networks, and G.8271.1 sets network limits for time synchronisation in packet networks with full timing support from the network (the 11/22 edition is in force with amendments up to 05/25). The idea is a budget: the total time error allowed at the radio is shared between the primary reference time clock, every boundary clock along the path, link asymmetry that PTP cannot measure, the end application and an allowance for holdover. ITU-T G.8272 (07/25 edition in force) specifies the timing characteristics of primary reference time clocks, the GNSS fed clocks at the top of the chain.

A fibre whose two directions differ in length by 2 metres has an asymmetry that light in glass covers in roughly 10 nanoseconds, which PTP turns into about a 5 nanosecond time error, because it assumes both directions are equal. Several boundary clocks plus a few such links quickly use a meaningful share of the budget, which is why operators calibrate asymmetry and limit hop counts.

GNSS at the site

The simplest approach is a GNSS receiver at each site with an antenna on the mast. It gives frequency, phase and time with no dependency on the transport network. Its weaknesses are well known: jamming, spoofing, indoor and street canyon sites without a view of the sky, damaged antenna cables, and receiver firmware bugs around leap seconds and week number rollovers. Our post on GPS timing as a hidden dependency covers those in detail.

PTP telecom profiles

The alternative is to deliver time over the network. ITU-T G.8275.1 is the PTP telecom profile for phase and time synchronisation with full timing support from the network: every node on the path takes part in PTP as a boundary or transparent clock, and Synchronous Ethernet provides a stable frequency underneath. The current edition is 02/26, with Amendment 1 (08/26) prepublished. Its companion G.8275.2 covers partial timing support, for networks where not every node is PTP aware, at a cost in accuracy. Our PTP explainer covers the protocol itself.

The O-RAN fronthaul work defines synchronisation topologies (LLS-C1 to LLS-C4) that say where the grandmaster sits relative to the O-DU and O-RU. The OpenAirInterface tutorial describes two of them in plain terms: LLS-C3, with an external grandmaster and a fronthaul switch as boundary clock, and LLS-C1, where the DU feeds time directly to the radio and support depends on the network card. Its sample ptp4l configuration uses layer 2 transport, hardware timestamping and domain 24, and tells readers to match the domain to their grandmaster.

Holdover

Holdover is what a clock does when it loses its reference. A good oscillator drifts slowly enough that the cell stays within budget for a known period, which turns a GNSS outage into an alarm the operations team has time to act on. A worked example: an oscillator holding a frequency error of 1 part in 10 to the 11 accumulates 0.01 nanoseconds of time error per second, about 36 nanoseconds per hour, so it can ride through many hours of outage before using up a 1.5 microsecond allowance, temperature permitting. A cheap crystal with a frequency error of 1 part in 10 to the 8 accumulates 10 nanoseconds per second and burns through the same allowance in about two and a half minutes. Real holdover also depends on drift and temperature, so test it.

How are the interfaces secured?

3GPP security for F1 and E1

3GPP TS 33.501 is the security architecture for the 5G system. Its requirements for split gNBs are specific:

• F1-C must support confidentiality, integrity and replay protection, and so must all management traffic carried over the CU to DU link.
• The gNB must support the same protection on F1-U for user plane traffic, but F1-C and management traffic must be protected independently from F1-U, so F1-U can be configured differently, including with encryption or integrity off.
• E1, between CU-CP and CU-UP, carries signalling only and must be confidentiality, integrity and replay protected.
• The mechanism is IPsec ESP with IKEv2 certificate based authentication, which is mandatory to implement on both DU and CU (and on CU-CP and CU-UP); a security gateway may terminate the tunnel on the CU side.
• DTLS must also be supported for F1-C and E1, with mutual authentication using DTLS or IKEv2.

Then comes the line that matters most for audits. The specification notes that using cryptographic protection on F1 and E1 is an operator's decision, and that if the gNB is in a physically secured environment, that secure environment includes other nodes and links. The standard requires equipment to support protection, not operators to switch it on.

Security assurance for gNB products

3GPP defines Security Assurance Specifications (SCAS) for network products. TS 33.511 is the SCAS for the gNodeB product class, and TS 33.117 is the catalogue of general security assurance requirements that apply across product classes. GSMA's Network Equipment Security Assurance Scheme (NESAS) builds on this: GSMA describes it as a security framework for mobile network equipment in which vendors and their equipment are audited and tested against a security baseline defined through GSMA and 3GPP, covering both product development and lifecycle management processes, with independent auditing and testing partners selected under criteria agreed by a NESAS Oversight Board.

O-RAN management plane and fronthaul protection

CISA and NSA's guidance gives the clearest public summary of O-RAN fronthaul security objectives: confidentiality and integrity of subscriber data, availability of the fronthaul to carry air interface messages, and authenticity on the fronthaul. Subscriber data is protected end to end by 3GPP air interface security, which terminates in the CU, so the fronthaul carries it already ciphered when that security is on. Availability and authenticity are the fronthaul's own problems.

On availability, the guidance names unauthorised devices on the fronthaul network as a key concern and lists network access control, radio hardening and physical security, and access control on radio management functions as mitigations, with network access control as the first line of defence. It also says plainly that cryptographic protection for the real time C and U planes at fronthaul speeds still needs further industry study.

On authenticity, it notes that the O-RAN management interface for the radio lets the operator choose certificate based authentication with mutual TLS or password based authentication with SSH. It calls password based authentication weak and open to brute force, warns that a foothold on a radio can be used to move toward northbound systems, and recommends mutual TLS 1.2 or 1.3 with X.509 certificates from a PKI.

Government guidance in the EU and the UK

The EU toolbox of risk mitigating measures for 5G cybersecurity, published in January 2020, sets out a common set of strategic and technical measures for member states, including security requirements for operators and an assessment of supplier risk. In the UK, the Electronic Communications (Security Measures) Regulations 2022 were published in September 2022 and the Telecommunications Security Code of Practice was added to the same government page in December 2022. A revised Code of Practice was published on 3 June 2026 and updated to version 1.1 on 14 July 2026. Operators in scope should read the current text directly rather than relying on summaries.

Component, function, interface and main security control

Step by step for an operator or private 5G owner

Most of this is ordinary infrastructure hygiene applied to equipment that is not ordinary. These steps are defensive and assume you own or operate the equipment. Run anything that changes state in a lab or a maintenance window first.

1. Build a software inventory for every RAN element

For each radio unit, DU, CU, RIC, SMO component, server and site router, record the hardware model, serial number, software and firmware versions, FPGA bitstream version where exposed, certificate expiry dates and the supplier's support status. O-RAN radio units expose their software slots through the o-ran-software-management YANG module (namespace urn:o-ran:software-management:1.0 in the published model), so any NETCONF client can read it. A read only request looks like this:

<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get>
    <filter type="subtree">
      <software-inventory xmlns="urn:o-ran:software-management:1.0"/>
    </filter>
  </get>
</rpc>

The reply lists each software slot, whether it is active and running, and the build and version of the files in it. Collect it on a schedule and store it with the date.

For containerised CU, DU and RIC workloads on Kubernetes, list every image actually running, not the ones the deployment manifests say should be running:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .status.containerStatuses[*]}{.imageID}{" "}{end}{"\n"}{end}' | sort

Using imageID gives the digest that is really running, which is what you need when a vulnerability is announced.

2. Collect or generate SBOMs

Ask each supplier for an SBOM in CycloneDX or SPDX for every software release you install, and keep it with the release record. CISA and NSA's Open RAN guidance calls verified SBOMs and software composition analysis valuable for finding vulnerable open source components in Open RAN deployments. For software you build yourself or container images you run, generate your own. With the Safeguard CLI, for example:

# Scan a container image by tag
safeguard scan --image registry.example.internal/ran/cu-cp:24.3.1

For an SBOM a supplier delivered with a DU release, or the source of an open source RAN stack you build in the lab, use the repository and SBOM paths in the CLI docs. Compare two releases and see which components changed before you schedule an upgrade.

3. Separate the networks

Put fronthaul, management, backhaul user traffic and timing on separate VLANs or VRFs, with filtering between them. Management should be reachable only from the operations network through a jump host with strong authentication. Turn on port based network access control on fronthaul switch ports where supported, and disable unused ports.

4. Check that F1 and E1 protection is actually on

Read configuration and live state, not the design document. On each CU and DU, confirm that IPsec security associations or DTLS sessions are up and that traffic counters on the protected interfaces are moving. If a link is left unprotected because it sits inside a secured building, record that decision and who made it, since TS 33.501 treats it as the operator's choice.

5. Lock down the management plane

Move radio M-plane access to mutual TLS with certificates where your equipment supports it, as the CISA and NSA guidance recommends, and disable password authentication over SSH where you can. Remove default and vendor support accounts, restrict which hosts may connect, log every configuration change and remove web interfaces you do not use.

6. Watch and test timing

On Linux based DU servers that use linuxptp, pmc reads the PTP daemon's state over its local socket without changing anything:

# Read only: current offset from the grandmaster and the parent clock
pmc -u -b 0 'GET TIME_STATUS_NP'
pmc -u -b 0 'GET PARENT_DATA_SET'
pmc -u -b 0 'GET PORT_DATA_SET'

Then, on a lab system or in a maintenance window, disconnect the GNSS antenna feed or the upstream PTP link on one site and record how long the clock stays within budget in holdover, which alarms fire and how long it takes to relock when the source returns. Repeat after firmware updates to timing equipment.

7. Patch on a schedule, with rollback

Agree a patch cadence with each supplier, stage updates in a lab running the same versions as production, and keep the previous image in an inactive software slot for rollback. Track firmware on site routers, power controllers and server BMCs like RAN software.

Common mistakes

• Flat site management networks. The radio, site router, power controller and door alarm share a subnet with no filtering, so one weak device exposes all of them.
• Unpatched radio unit firmware. Radios are installed and forgotten because a mast climb feels expensive, even though many updates can be pushed remotely.
• GNSS only timing with no holdover. A jamming event or a damaged antenna cable can take TDD cells off air when the oscillator cannot hold time.
• Assuming IPsec is on because the specification mentions it. TS 33.501 requires equipment to support F1 and E1 protection; using it is the operator's decision.
• Password based SSH on the radio management plane. CISA and NSA call it weak and recommend mutual TLS with certificates.
• No SBOM for RAN software. When a widely used library has a vulnerability, nobody can say which DU or CU release carries it.
• Treating xApps like configuration. They are third party code with influence over the RAN. Review, approve and inventory them as code.
• Letting certificates expire. Certificate based authentication on F1, E1 and the M-plane fails closed when a certificate lapses, which turns a security control into an outage.

FAQ

What is inside a 5G base station?

Antennas or active antenna units, one or more radio units, baseband processing split into DU and CU, a fronthaul link, a timing source, power, a site router and backhaul, plus the software that runs and manages them.

What is the difference between a gNB, a CU and a DU?

The gNB is the logical 5G base station. 3GPP TS 38.401 lets it be split into a central unit hosting RRC, SDAP and PDCP, and one or more distributed units hosting RLC, MAC and the physical layer, connected by the F1 interface.

What is the O-RAN 7.2x split?

A split inside the physical layer. The radio unit performs lower PHY functions such as FFT and cyclic prefix handling, the DU performs the upper PHY, and frequency domain samples cross the Open Fronthaul over Ethernet.

Why does 5G TDD need such precise timing?

Neighbouring TDD cells must switch between transmitting and receiving at the same moment. TS 38.133 requires frame timing between overlapping cells on the same frequency to differ by less than 3 microseconds, or downlink signals interfere with uplink reception.

Are the F1 and E1 interfaces encrypted?

Equipment must support IPsec on F1 and E1, and DTLS for F1-C and E1, under TS 33.501. Whether protection is switched on is the operator's decision, so check the live configuration.

What are xApps and rApps?

Applications on the O-RAN RAN Intelligent Controllers. xApps run on the near real time RIC with control loops as fast as 10 milliseconds; rApps run on the non-real time RIC with loops longer than one second.

Is Open RAN less secure than traditional RAN?

CISA and NSA describe Open RAN as bringing benefits and new considerations: more open interfaces, third party applications, open source software and cloud infrastructure to secure. How it is configured and operated decides the outcome.

Can I build a 5G base station with open source software?

For research, testing and some private networks, yes, subject to spectrum licensing. OpenAirInterface and the OCUDU Project (formerly the srsRAN Project) publish 5G RAN software that runs on commercial servers with radio units or software defined radios.

Where Safeguard fits

Safeguard does not analyse radio hardware, FPGA bitstreams, firmware images or RF behaviour, and it does not monitor timing or fronthaul networks. Those stay with your equipment suppliers, your timing and transport teams and the 3GPP, O-RAN and GSMA assurance processes described above. Safeguard's fit is the software around the RAN that looks like any other software estate: container images that run CUs, DUs, RICs and SMO components, the SBOMs suppliers hand over with each release, and the source of open source stacks and in-house xApps, rApps and tools. It scans repositories, container images and SBOM files, matches components against vulnerability databases, shows which projects contain a given component and version, applies policies and gates in CI, and can open fix pull requests for dependencies in code you build yourself.

Tracking the open source components in a RAN software release, and closing the gap between a published fix and the version you actually run, is the part of base station security that is ordinary software supply chain work.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency scanning and remediation, not radio or timing analysis. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Run on a lab server, the same flow scans the container images of a CU, DU or RIC deployment, or a supplier's SBOM, so you know which components each RAN release carries before you upgrade.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: asked to fix the lodash CVE in a repository, the assistant reads the finding and the advisory, edits package.json to lodash 4.17.21 and runs npm install and npm test, asking before any command that changes something and pushing nothing. The same flow applies when an in-house xApp, an rApp or a site automation tool needs a dependency bump.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once your RAN images and SBOMs are scanned, you can ask which projects ship a given library version and get the answer from your own data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• 3GPP TS 38.401: NG-RAN; Architecture description
• 3GPP TS 38.470: NG-RAN; F1 general aspects and principles
• 3GPP TS 38.460: NG-RAN; E1 general aspects and principles
• 3GPP TS 33.501: Security architecture and procedures for 5G System
• 3GPP TS 38.133: NR; Requirements for support of radio resource management
• 3GPP TS 38.104: NR; Base Station radio transmission and reception
• 3GPP TS 33.511: SCAS for the gNodeB network product class
• 3GPP TS 33.117: Catalogue of general security assurance requirements
• CPRI cooperation: CPRI and eCPRI specifications
• ITU-T G.8275.1: PTP telecom profile with full timing support from the network
• ITU-T G.8271: Time and phase synchronization aspects of telecommunication networks
• ITU-T G.8271.1: Network limits for time synchronization with full timing support
• ITU-T G.8272: Timing characteristics of primary reference time clocks
• CISA and NSA: Open Radio Access Network Security Considerations (PDF)
• GSMA: Network Equipment Security Assurance Scheme (NESAS)
• European Commission: Cybersecurity of 5G networks, EU Toolbox of risk mitigating measures
• GOV.UK: Electronic Communications (Security Measures) Regulations and Telecommunications Security Code of Practice
• GOV.UK: Revised Telecommunications Security Code of Practice 2026 (version 1.1)
• O-RAN Alliance: Specifications
• O-RAN Software Community: o-ran-software-management YANG model
• OpenAirInterface Software Alliance
• OpenAirInterface: openairinterface5g repository
• OpenAirInterface: 7.2 Fronthaul Interface Tutorial
• srsRAN Project
• OCUDU Ecosystem Foundation
• linuxptp: pmc(8) PTP management client