Telecom Software Supply Chain Security: Rules, Incidents and 90 Days

Telecom software supply chain security means knowing which code runs in your radio network, 5G core, routers, OSS/BSS and vendor clouds, keeping it patched, and proving it to regulators and partners. For a US carrier in October 2026 that runs through FCC rules, CISA's Salt Typhoon guidance and vendor contracts. This guide covers the rules, recent incidents, the owners and a 90-day plan.

The first two thirds of this post work with whatever tools you already have. Safeguard appears only in the section headed "How Safeguard does this", near the end.

Key takeaways

• A carrier's software supply chain is wider than most: radio units and RAN software, cloud native 5G core network functions, router and switch operating systems, NFV and Kubernetes platforms, OSS and BSS, lawful intercept systems, customer premises equipment firmware and the vendors who host customer data.
• The US rules that touch this software today are the FCC Covered List (47 CFR 1.50002), the CPNI breach notification rule (47 CFR 64.2011) and FCC enforcement on vendor oversight. The January 2025 CALEA Declaratory Ruling on carrier cybersecurity was rescinded by an Order on Reconsideration in November 2025, so do not build a program on it.
• The most useful federal guidance is technical, not regulatory: CISA's Enhanced Visibility and Hardening Guidance for Communications Infrastructure (December 2024), the joint advisory AA25-239A (2025), NIST SP 800-161 Rev. 1 (updated November 2024) and CISA's 2026 Minimum Elements for an SBOM (29 July 2026).
• The incidents of the last three years share a pattern the official sources describe plainly: known vulnerabilities in network edge software, long dwell times, and customer data sitting with vendors after contracts ended.
• Six people own pieces of this: the CISO, the head of network engineering or cloud platform, the head of product security, the regulatory and GRC lead, the vendor risk and procurement owner, and network operations.
• A 30/60/90-day plan can get a carrier from "we think we know" to an inventory, a vendor evidence process, a patch clock for edge software and a gate on in-house builds.
• Safeguard capabilities covered in this post, all GA: SBOM generation and analysis, software composition analysis and vulnerability management, reachability analysis, policies and gates, TPRM (Third-Party Risk Manager), CSAF and VEX upload, license compliance, autonomous remediation (ships switched off), the local runner CLI, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

The situation

The usual trigger: a joint advisory names router flaws used against providers worldwide, the board asks whether "we are exposed", regulatory asks what the FCC now expects, and procurement is mid renewal on a RAN software contract with no idea what open source sits inside it.

That is the trigger for most of the people reading this. The question is rarely "do we have a supply chain program". It is "can we answer, by Friday, which of our network functions and vendor systems carry the affected component, who owns each one, and when each will be fixed".

A bad week looks like this. The inventory lives in a CMDB, a network planning database and vendor spreadsheets, and none of them lists software components. Vendor contracts say "timely" patching with no clock. And customer data a marketing vendor received years ago may still sit in its cloud.

What software a telecom carrier runs

Telecom is unusual because most of its critical software is bought, not built, and much of what is built is glue between vendor systems. The table below is the inventory most carriers end up with once they start counting.

Two things stand out. First, the share of software the carrier compiles itself is small, but it touches everything: OSS integrations, BSS customizations, automation scripts and the platform. Second, for the bought software, the carrier's main lever is the contract and the evidence the vendor provides. Both matter for the plan later in this post.

The regulations and frameworks that apply

This section summarizes primary sources as of 25 October 2026. It is not legal or regulatory advice; your counsel decides what applies to your licenses and operations.

FCC Covered List (47 CFR 1.50002)

Under 47 CFR 1.50002, the FCC's Public Safety and Homeland Security Bureau publishes and maintains the Covered List. Equipment or services go on it when a listed national security body (for example the Federal Acquisition Security Council or the Department of Commerce under Executive Order 13873) determines they pose an unacceptable risk, and when they are capable of things such as routing or redirecting user traffic or giving visibility into user data. For software supply chain purposes, the practical point is simple: you need an inventory precise enough to show which vendors and products are in your network, so that a Covered List addition becomes a lookup rather than a project.

CPNI breach notification (47 CFR 64.2011)

The current eCFR text of 47 CFR 64.2011 requires a telecommunications carrier to notify the US Secret Service and the FBI through the FCC's central reporting facility "as soon as practicable, and in no event later than seven (7) business days" after reasonably determining a breach of customers' CPNI. Customer and public notice generally waits until seven full business days after that law enforcement notice, and an investigating agency can ask for a delay of an initial 30 days. The eCFR page also carries a cross reference to amendments published at 89 FR 10002 on 12 February 2024, which come from the FCC's 2023 data breach order; check the current effective text with counsel. For supply chain work this rule matters because many CPNI exposures start at a vendor, and the clock starts when you reasonably determine the breach, not when the vendor tells you everything.

FCC enforcement on vendor oversight

On 17 September 2024 the FCC released a consent decree with AT&T (DA 24-892, adopted 16 September 2024) settling an investigation into a January 2023 breach of a vendor's cloud environment. The FCC's order says AT&T customer information shared with the vendor should have been returned or destroyed under the contracts, and remained in the vendor's environment for years instead. The decree requires improved data governance, vendor oversight and data retention and disposal controls. This is the clearest recent signal that the FCC treats vendor management as part of a carrier's own CPNI duties.

The CALEA Declaratory Ruling, and its rescission

In January 2025 the FCC adopted a Declaratory Ruling stating that CALEA affirmatively requires carriers to secure their networks against unlawful access or interception, together with a proposed rulemaking. The FCC's fact sheet dated 30 October 2025 describes an Order on Reconsideration that rescinds the Declaratory Ruling and withdraws the proposed rules, citing providers' agreement to take extensive steps. Trade press and law firm alerts report the order was adopted at the FCC's November 2025 open meeting. As of this writing, there is no FCC rule that prescribes specific software supply chain controls for carriers. That makes the technical guidance below, and your own contracts, the real backbone of a program.

CISA and partners: hardening guidance and advisories

CISA and partner agencies published "Enhanced Visibility and Hardening Guidance for Communications Infrastructure" on 3 December 2024 (the page shows 4 December 2024). Among its recommendations: monitor vendor end of life announcements and upgrade as soon as possible, run change management that anticipates routine and emergency patching, test patches, and verify software image hashes against the vendor's published values. Joint advisory AA25-239A, last revised 3 September 2025, lists known CVEs exploited by the actors behind the campaign and states that exploitation of zero days had not been observed. The pattern is known flaws in edge and network software, which is exactly what an inventory and a patch clock address.

NIST SP 800-161 Rev. 1 (C-SCRM)

NIST SP 800-161 Rev. 1, "Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations", was published in May 2022 and updated on 1 November 2024. It integrates supply chain risk into enterprise risk management at three levels, with C-SCRM strategy, policies, plans and assessments. It is not binding on carriers, but it is the framework most US auditors and federal customers recognize, and it gives you vocabulary for board reporting.

CISA 2026 Minimum Elements for an SBOM

On 29 July 2026 CISA, with US and international partners, published the 2026 Minimum Elements for a Software Bill of Materials. CISA's bulletin says it builds on the NTIA minimum elements from 2021 and incorporates feedback from a 2025 public comment period. If your vendor contracts still reference the 2021 NTIA list, update them to the 2026 document when you next touch them.

3GPP security specifications

3GPP TS 33.501, "Security architecture and procedures for 5G System", defines the 5G security architecture your core and RAN vendors implement. TS 33.117, "Catalogue of general security assurance requirements", is the base of 3GPP's security assurance specifications for network products. These are product requirements on vendors, not an operator compliance regime, but they are useful in procurement: ask vendors which assurance specifications their products were evaluated against and when.

Open RAN

In September 2022 NSA and CISA published "Open Radio Access Network Security Considerations" through the Enduring Security Framework (CISA's alert announcing it is dated 16 September 2022). The working panel compared Open RAN with traditional RAN and examined how security differs. What that means for a supply chain program is covered in its own section below.

Outside the US

Carriers with EU or UK operations face their own regimes, which are broader than the US rules above. Treat them as context for this US-first guide and work them with local counsel.

Real public incidents from the last three years

These summaries stay within what the official sources say. They do not judge what any named organization should have done.

Salt Typhoon and the 2025 joint advisory

On 13 November 2024 the FBI and CISA said their investigation had found PRC-affiliated actors had compromised networks at multiple telecommunications companies. The statement lists theft of customer call records, compromise of private communications of a limited number of individuals mostly in government or political activity, and copying of certain information subject to US law enforcement requests under court orders.

The joint advisory AA25-239A, issued with many international partners and last revised on 3 September 2025, describes the activity in more depth. It says the actors focus on large backbone routers of major telecommunications providers and on provider edge and customer edge routers, and that they often modify routers for persistent access. It lists CVEs the actors exploited, including CVE-2024-21887 (a VPN gateway web component command injection, commonly chained after CVE-2023-46805), CVE-2024-3400 (a firewall operating system flaw allowing unauthenticated remote code execution in some configurations), CVE-2023-20198 and CVE-2023-20273 (a router and switch operating system web management interface, chained for root access) and CVE-2018-0171. It also states that exploitation of zero days had not been observed to date.

The advisory points at known vulnerabilities in vendor edge software. Those are fixed by vendor upgrades, so the carrier's job is knowing which versions run where and running a short clock from advisory to upgrade.

Volt Typhoon

Advisory AA24-038A, published on 7 February 2024 by CISA, NSA and FBI with partners, says Volt Typhoon compromised IT environments of multiple critical infrastructure organizations, primarily in Communications, Energy and other sectors, and assesses with high confidence that the actors were pre-positioning for disruption rather than espionage. For carriers it reinforces the edge software point and adds the risk of living off the land on management systems your own teams run.

XZ Utils

On 29 March 2024 CISA reported malicious code in XZ Utils versions 5.6.0 and 5.6.1, tracked as CVE-2024-3094, and recommended downgrading to an uncompromised version such as 5.4.6 Stable, hunting for malicious activity and reporting findings. XZ Utils is a compression library that ships in many Linux distributions, which means it can appear in container base images for network functions, OSS servers and build systems. The first question that week was simply which images and hosts had 5.6.0 or 5.6.1, and only a component level inventory answers it quickly.

The AT&T vendor cloud consent decree

The FCC's order describes a January 2023 breach in which threat actors accessed a vendor's cloud environment and exfiltrated AT&T customer information that AT&T had shared with the vendor. The FCC says the information should have been returned or destroyed under the contracts and remained in the vendor's environment for years. The September 2024 consent decree requires AT&T to improve data inventory, vendor controls and oversight, and data retention and disposal by vendors. It is a supply chain story about data flowing to software you do not run, and it belongs in the same program.

The personas who own the problem

Each of these people owns a slice. The plan only works when each knows what they need and when.

A few notes the table cannot hold. The CISO needs a one page exposure view with owners and dates, not tool mechanics, and NIST SP 800-161 Rev. 1 gives the board narrative its structure. Network engineering worries about change risk more than anyone, because a bad upgrade on a core function is an outage, so their win is one process for vendor advisories instead of four. Product security owns more code than most carriers expect (OSS integrations, BSS extensions, automation, customer apps) and feeds component findings back to the network team when a common library turns up in platform images. The GRC lead needs dated evidence by rule: the Covered List check, a CPNI breach procedure that includes vendors, and the vendor oversight records the FCC's 2024 order points at. Procurement holds the most contractual power and often the least technical support. Network operations carries the change and loses patience with lists of thousands of findings; give them the twenty that matter this window.

Step by step: a 30/60/90-day plan

This plan works with spreadsheets and open source tools or with a platform. A regional carrier might cover everything in 90 days; a national carrier might start with edge and core.

Days 1 to 30: see what you run

1. Name the owners. Write down one accountable owner for each domain in the inventory table above. Get the CISO to sign it.
2. Build the element inventory. Pull network element and function lists from your planning and management systems: vendor, product, software version, location, role (edge, core, transport, RAN), and internet exposure. Start with the edge: provider edge and customer edge routers, VPN gateways, firewalls and management interfaces.
3. Cross check the CVEs in AA25-239A. For each CVE the advisory lists, mark every element running an affected product, and record its version and upgrade status. This is your first board ready view.
4. Generate SBOMs for what you build and deploy. For in-house repos and for container images on your NFV or Kubernetes platform, generate SPDX or CycloneDX SBOMs with whatever tool you use. Images matter as much as repos, because base layers carry libraries like XZ Utils.
5. List vendors that hold customer data. From procurement and privacy records, list every vendor that has received CPNI or customer data in the last several years, contract end date and whether return or destruction was confirmed.
6. Check the Covered List. Compare your vendor and product inventory with the FCC Covered List and record the date and result.
7. Write the patch clock. Set target times from vendor advisory to upgrade by tier. Use your own numbers; an illustrative starting point is shown below.

These are illustrative targets for planning, not regulatory deadlines. Pick numbers your network team agrees it can meet, then hold to them.

Days 31 to 60: get evidence from vendors and gate what you build

1. Tier your vendors. Critical (RAN, core, transport, lawful intercept, signalling security, BSS holding CPNI), high, medium, low. The tier sets the evidence you ask for.
2. Send evidence requests. Ask critical vendors for an SBOM per product and version, their advisory feed (CSAF if they publish it), VEX statements for CVEs they say do not affect you, and their end of life schedule. Use the template below.
3. Ingest what comes back. Load vendor SBOMs and advisories into one place and match them against vulnerability data, including CISA KEV and EPSS. Flag the components that also appear in your own images.
4. Add build gates. In CI for in-house code and images, block known exploited vulnerabilities and disallowed licenses, warn on the rest, and require a written, expiring exception for anything that must ship anyway.
5. Fix the data trail. For vendors holding customer data after contract end, request written return or destruction confirmation and record it.
6. Rehearse a vendor CPNI breach. Run a tabletop where a vendor reports exfiltration of CPNI on a Friday afternoon. Time how long it takes to determine the breach and file with the Secret Service and FBI.

Template: vendor software evidence request

Use this as a starting point for procurement. It is not contract language; your counsel adapts it.

Days 61 to 90: prioritize, fix and report

1. Prioritize by exposure and use. For in-house code, rank findings by whether the vulnerable function is reachable, exploited (KEV) and likely (EPSS). For vendor software, rank by element tier and exposure.
2. Run the first fix wave. Upgrade the edge elements on the AA25-239A list, then the highest ranked in-house findings. Use pull requests for in-house fixes so changes are reviewed and tested.
3. Verify images before install. Follow CISA's step: compare the image hash with the vendor's published value from an authenticated source before every network OS install.
4. Set continuous monitoring. Re-check vendor SBOMs when new CVEs or KEV additions land, not just at renewal.
5. Report. Give the CISO a one page view: inventory coverage, open exploited CVEs on the edge by owner and date, vendor evidence coverage by tier, exceptions open and expiring.
6. Plan the next quarter. Extend from the edge and core to RAN, customer premises and the long tail of BSS vendors.

Decision table: a new CVE lands in a common component

How is Open RAN different for supply chain risk?

Open RAN splits what used to be one vendor's stack across several vendors and a shared cloud platform. The ESF paper looks at how its security differs from traditional RAN. In supply chain terms you gain more components and more vendors: radio unit firmware from one supplier, distributed and centralized unit software from another, a RAN intelligent controller with third-party xApps and rApps, all on a Kubernetes platform you may run yourself. Each layer needs its own SBOM, its own patch clock and its own owner. The platform layer is yours outright, so treat it like any in-house build.

Do SBOMs work for closed network appliances?

Partly. A vendor can provide an SBOM for a router OS or network function image even if you never see the source. You cannot verify it as deeply as your own code, but it answers the incident question: does this product and version contain the affected component. Pair it with the vendor's VEX statements and advisories. Where a vendor will not provide one, record that in its risk tier and fall back to version matching against advisories.

What about end of life network software?

CISA's hardening guidance tells operators to monitor vendor end of life announcements and upgrade as soon as possible. End of life elements are a supply chain risk because no fixed version will ever come. Track them as their own category, with a replacement date and a compensating control (isolation, disabled management services, restricted access) until they are gone.

How Safeguard does this

Safeguard maps to the plan above in the places where software and evidence meet. Each step below uses capabilities from Safeguard's offering files and docs, and every capability named is GA. Commands are as docs.safeguard.sh shows them; they were not run for this post.

1. Inventory what you build and deploy. SBOM generation and analysis (GA) produces SPDX and CycloneDX SBOMs, and software composition analysis with deep transitive dependency scanning (GA) covers application code and container layers. From the Safeguard CLI the docs show one target per scan:

   # A local directory
   safeguard scan --dir .
   # A container image
   safeguard scan --image nginx:latest
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   Results land as JSON files (including vuln.json and license.json) under ./output by default. The docs note that safeguard scan does not fail on findings and has no severity threshold flag; gating is done by policy gates in the platform.

2. Keep source inside your perimeter. Many carriers will not give a cloud service OAuth access to OSS and BSS repos. The local runner built into the CLI (GA) runs scan jobs on your own machine, opens only outbound HTTPS, and uploads only the resulting SBOM and findings, never source code. Install is the documented one-line installer:

   curl -fsSL https://cli.safeguard.sh/install | bash
   

   For networks that cannot reach any cloud service, on-prem and air-gapped deployment (GA) runs the platform inside your perimeter. The air-gapped docs describe signed snapshot bundles delivered by one-way diode, signed removable media, a scheduled DMZ sync or a pull replica, at a cadence from hourly to quarterly, with no component inside the perimeter calling outbound. Zero AI mode (GA) runs the platform with no LLM at all, and bring your own model (GA) lets you use a model your policy already approves.

3. Match against vulnerability data and rank it. Vulnerability management (GA) matches components against vulnerability sources and enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks the vulnerable code paths your in-house applications actually call, so the first fix wave in days 61 to 90 starts with the findings that matter most.

4. Request and track vendor evidence. TPRM (GA) keeps the vendor directory and tiers vendors by criticality. The docs suggest a tier model where critical vendors provide SBOMs with quarterly updates and high risk vendors annual updates. To request an SBOM, the docs show: open the vendor, click Request SBOM, select products, choose a request template, set a deadline and send; bulk requests work from the Vendors list. The standard template covers SPDX or CycloneDX format and required fields. Request status runs from Sent through Viewed, In Progress, Submitted, Validated or Rejected, with reminders seven days before the deadline, at the deadline and an escalation seven days after. Received SBOMs are checked for format and completeness and scanned for vulnerabilities, and you can send a Request Revision when a submission falls short.

5. Load vendor advisories and VEX. CSAF and VEX upload (GA) takes CSAF 2.0, CycloneDX VEX, OpenVEX and the CSAF VEX profile. The docs path is Integrations, filter by Upload, then Connect on the Upload CSAF/VEX card, name the upload, add the file and set the project name and version. This is where a RAN or core vendor's VEX statements sit next to their SBOM.

6. Watch vendors continuously. TPRM monitoring watches for new vulnerabilities affecting vendor SBOMs, severity changes and CISA KEV additions. Alerts are configured under Settings, then Monitoring, and can go to email, Slack, Microsoft Teams, PagerDuty or a webhook. Re-scans can run daily for critical vendors, or weekly, monthly or quarterly, and re-assessment can be triggered by contract renewals or security incidents. Reports export as PDF or Excel for the GRC lead.

7. Gate in-house builds. Policies and gates (GA) turn the patch clock into enforcement. Policies are created under Settings, then Policies, with conditions such as vulnerability severity, CVSS, EPSS, license, component age and maintenance. Each policy's action is Block (the gate fails), Warn (passes with a warning) or Notify (passes and sends a notification). With policy outcomes on for your workspace, safeguard ci scan --wait --fail-on-gate <gate> fails a CI job when the gate fails. Exceptions are requested with a business justification and an expiration date, go to approvers, and leave an audit trail. Plain English policy creation (GA) helps the GRC lead draft a policy without YAML. License compliance (GA) covers the license side of the same gate.

8. Open fixes as pull requests. Autonomous remediation (GA) can open tested, policy gated pull requests for in-house repos. It ships switched off, with every category set to Manual, so your team decides what runs on its own.

9. Share evidence outward. The Portal (GA), in its role as the SBOM publish and share surface, lets a carrier that sells to enterprises or government share its own SBOMs and audit trails. The compliance and GRC suite (GA) holds frameworks, controls and evidence when the GRC lead needs to map this work to NIST SP 800-161 Rev. 1 or internal policy.

On posture: Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress.

What Safeguard does not do

• It does not patch closed network operating systems. When the flaw is in a vendor's router OS, firewall image or network function binary, the fix is the vendor's release. Safeguard can show which products and versions are affected from the SBOM and advisory data you have; your network team still schedules and installs the upgrade.
• It does not replace the vendor's evidence. If a RAN or core vendor will not supply an SBOM or VEX, Safeguard cannot invent one for a closed appliance. That gap stays in the vendor's risk tier and in your contract negotiation.
• It does not file regulatory notices. CPNI breach notification to the Secret Service and FBI, Covered List decisions and any FCC correspondence are your legal and regulatory team's work.
• It does not hunt adversaries in your routers. The configuration review, log analysis and threat hunting in AA25-239A and the hardening guidance belong to your network security and incident response teams.
• It does not verify vendor image hashes on your routers. The pre-install hash check CISA recommends happens in your change process on your management workstations.
• It does not decide your risk appetite. The patch clock, exception approvals and vendor tiers are decisions your CISO and network leadership make; Safeguard enforces and records them once made.

Common mistakes

• Treating the CALEA Declaratory Ruling as current. It was rescinded. Citing it in a board pack or vendor letter undermines the rest of the document.
• Inventorying network elements but not components. A version list answers "which routers run release X". It does not answer "where is XZ Utils 5.6.1". You need both.
• Asking vendors for "an SBOM" with no format, fields or refresh cycle. You get a PDF once. Name the format, point to the 2026 Minimum Elements and tie refresh to each release.
• Forgetting the platform layer. The Kubernetes or NFV platform under the core is the carrier's own software, with its own open source and its own base images.
• One patch clock for everything. The edge needs a shorter clock than an internal reporting tool. Tier it.
• Ignoring vendors that only hold data. The FCC's 2024 AT&T order is about a vendor that held customer data, not one that ran network software.
• Exceptions with no expiry. An exception without an end date is a permanent risk acceptance nobody signed.

FAQ

Does the FCC require telecom carriers to have a software supply chain security program?

Not in those words. The binding rules that touch it are the Covered List (47 CFR 1.50002) and CPNI breach notification (47 CFR 64.2011), and the FCC has enforced vendor oversight through consent decrees such as the 2024 AT&T order. The January 2025 CALEA Declaratory Ruling was rescinded. Ask counsel what applies to you.

What did Salt Typhoon exploit?

The joint advisory AA25-239A lists known CVEs in network edge software, including CVE-2024-21887, CVE-2024-3400, CVE-2023-20198, CVE-2023-20273 and CVE-2018-0171, and states that zero day exploitation had not been observed to date. The agencies describe the actors modifying routers to keep long term access.

Is an SBOM useful for a router or network function I cannot see inside?

Yes, as long as the vendor provides one per product and version. It lets you answer whether an affected component is present within minutes of a new CVE. Pair it with the vendor's VEX statements and advisories.

Which SBOM standard should carriers ask vendors to follow?

Ask for SPDX or CycloneDX and point to CISA's 2026 Minimum Elements for an SBOM, published 29 July 2026, which replaces the 2021 NTIA minimum elements as the baseline.

How do Open RAN deployments change vendor risk?

They add vendors and software layers, each of which needs an owner, an SBOM and a patch clock. See the Open RAN section above.

How fast should carriers patch edge routers?

No federal rule sets a number for carriers. CISA's hardening guidance asks for timely patching, emergency change readiness and upgrades away from end of life software. Set internal clocks by tier, shortest for exposed edge elements with known exploited CVEs.

What is NIST SP 800-161 and do carriers need it?

It is NIST's guidance for cybersecurity supply chain risk management, Rev. 1, updated 1 November 2024. It is voluntary for carriers, but it gives a structure auditors and federal customers recognize.

Who should own telecom software supply chain risk?

The CISO is accountable; the work splits across network engineering, product security, GRC, procurement and network operations, as the persona table shows.

What does the CPNI breach rule mean for vendor incidents?

Under 47 CFR 64.2011 the carrier must notify the Secret Service and FBI within seven business days of reasonably determining a CPNI breach, including breaches at vendors holding CPNI. Make sure your vendor contracts require prompt notice to you.

Fix vulnerable open source in what you build

Most of what this post covers is vendor software you cannot patch yourself, but the carrier's own OSS, BSS and platform code is full of open source you can fix directly. The section below describes how to close the gap between a published fix, or a missing one, and your own builds.

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

This demo is a real Safeguard CLI session: install, run safeguard to open the interactive terminal, ask it to "fix the lodash CVE in this repo", and watch it read the finding and advisory, ask before any command that changes something, edit package.json to lodash 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. It ends with /permissions, /model and /scan . The same flow applies to a vulnerable library in an OSS or BSS integration repo.

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

This one sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. It is the route for carrier teams that will not give a cloud service access to their repositories, since only the SBOM and findings leave the machine.

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

The last demo connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. A GRC or vendor risk lead could use the same setup to ask questions about the inventory in plain language, with access limited to the tools you allow.

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

To try it on your own code, download Safeguard from https://safeguard.sh/download and read the docs at https://docs.safeguard.sh/docs .

Quick check

Related reading

• Salt Typhoon and the telecom supply chain campaign
• FCC and CISA guidance on telecom software supply chain security
• Managing open source risk in telecom OSS/BSS stacks
• Third-party risk management for telecom equipment vendors
• A telecom network hardening checklist from joint guidance
• Vulnerabilities in Open RAN and 5G core software

Sources

• eCFR: 47 CFR 1.50002, Covered List
• eCFR: 47 CFR 64.2011, CPNI breach notification
• FCC: AT&T consent decree, DA 24-892
• FCC fact sheet: Order on Reconsideration, PS Docket No. 22-329 (30 October 2025)
• FBI and CISA joint statement on PRC targeting of commercial telecommunications (13 November 2024)
• CISA advisory AA25-239A
• CISA: Enhanced Visibility and Hardening Guidance for Communications Infrastructure
• CISA advisory AA24-038A, Volt Typhoon
• CISA alert on XZ Utils, CVE-2024-3094
• NIST SP 800-161 Rev. 1, update 1
• CISA bulletin: 2026 Minimum Elements for an SBOM
• CISA: NSA and CISA publish Open RAN security considerations
• 3GPP TS 33.501
• 3GPP TS 33.117
• Safeguard docs: Third Party Risk Manager
• Safeguard docs: SBOM Requests
• Safeguard docs: TPRM Monitoring
• Safeguard docs: Vendor Management
• Safeguard docs: Policies and Gates
• Safeguard docs: CLI usage
• Safeguard docs: Local Runner
• Safeguard docs: Air-Gapped Deployment
• Safeguard docs: CSAF/VEX Upload

Last reviewed: 25 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.