Space and Satellite Supply Chain Security: Rules, Incidents, 90-Day Plan

Space and satellite operators secure their software supply chain by knowing which open source and commercial components run in the ground segment, the mission control stack and every flight software build, fixing flaws in those components on a schedule that fits contact windows and launch dates, and asking suppliers for the same records. In the United States the anchors are Space Policy Directive 5, NIST IR 8401 for the satellite ground segment, NIST IR 8270 for commercial operators and NASA's Space Security Best Practices Guide, with federal customer rules on SBOMs and secure development on top. A 90-day plan built around an inventory, a fix process and supplier evidence gets most operators to records they can show a government customer, a prime contractor or an insurer.

The plan works with whatever tools you already have. Safeguard appears only in "How Safeguard does this". Nothing here is legal or licensing advice; your license conditions, your contracts and your counsel decide what applies to you.

Key takeaways

• Most of the software risk sits on the ground. NIST IR 8401 applies the Cybersecurity Framework to the satellite ground segment, with an emphasis on command and control of the bus and payload. That is where Linux hosts, web consoles, databases and open source mission control frameworks live.
• The policy baseline is from 2020 and still names supply chains. Space Policy Directive 5 lists management of supply chain risks among its cybersecurity principles for space systems, including tracking manufactured products and sourcing from trusted suppliers.
• NIST has three space reports you can use today: IR 8401 for ground segment command and control (December 2022), IR 8270 for commercial satellite operations (July 2023) and IR 8441 for hybrid satellite networks (September 2023). All three predate CSF 2.0, so map them forward.
• NASA's guide is for everyone, not only NASA. NASA released the first iteration of its Space Security Best Practices Guide on 22 December 2023 for public and private missions of any size, to support the goals of SPD-5.
• Open source space software now gets regular CVEs. NVD lists flaws published since late 2023 in a space link security library, two open source mission control frameworks and their releases through September 2026. These are dependency problems as much as code problems.
• The FCC licenses; it does not run a software inventory rule. The FCC's Space Bureau leads satellite and earth station licensing and spectrum policy. We found no FCC rule that requires operators to keep an SBOM. Federal customers are the stricter driver today.
• Federal buyers can ask for an SBOM. OMB M-26-05 (23 January 2026) lets agencies require a current SBOM on request, and CISA's 2026 Minimum Elements for an SBOM (29 July 2026) define what it should contain.
• Safeguard capabilities covered here, all GA: SBOM generation and analysis, SCA with deep transitive dependency scanning, vulnerability management with EPSS and KEV, reachability analysis, policies and gates (Block, Warn and Notify, with approval handled through exceptions), autonomous remediation (ships switched off, every category set to Manual), license compliance, CSAF and VEX upload, the compliance and GRC suite with a NIST CSF 2.0 framework page, TPRM with SBOM requests, Trust Center, the Safeguard CLI and local runner, Zero AI mode, bring your own model, and on-prem and air-gapped deployment.

The situation

The trigger for most space operators is not a regulator. It is a customer, a partner or a researcher. A government program office asks for an SBOM for the ground software it is buying. A prime contractor sends a supplier questionnaire with a section on open source components. An insurer asks how the operator would know within a day whether a newly published vulnerability affects the mission control system. Or a researcher publishes CVEs in an open source framework the operations team built on years ago.

A bad week looks like this. A critical flaw lands in a library that sits underneath the telemetry archive, and nobody can say which ground stations run which version. The flight software team vendored a space link security library from a commit two years ago and cannot tell whether the new advisory applies to that commit. A ground station partner reports an incident, and the operator does not know whether the partner's software touches the command path.

None of this needs a new regulation to hurt. Each one is a software supply chain question, and each one is answerable with records you can build in 90 days.

What software space and satellite operators run

A satellite operator is a software company with antennas attached. The useful split for supply chain work follows the segments that NIST's space reports use: ground, link, space and user.

Ground segment and mission operations

• Mission control and command and control (C2) software. The system that builds and sends telecommands, receives and decommutates telemetry, raises alarms and keeps the command history. Many operators build on open source mission control frameworks rather than writing this from scratch.
• Telemetry, tracking and command (TT&C) front ends. Software that handles the space link protocols, framing and, where used, link layer security such as the CCSDS Space Data Link Security protocol.
• Flight dynamics and mission planning. Orbit determination, maneuver planning, conjunction screening, contact scheduling and tasking. Often Python, Java or C++ with deep scientific library trees.
• Ground station network software. Antenna control, scheduling across owned and leased stations, and the APIs that connect to ground station as a service providers.
• Software defined radios and modems. Signal processing chains that increasingly run on general purpose hosts with open source radio toolkits, plus vendor firmware in modems and baseband units.
• Payload data processing pipelines. Imagery, signals or communications data flowing from downlink to finished products.
• Customer portals and APIs. Tasking portals, data delivery APIs, billing and support systems that put the operator on the public internet.

Space segment

• Flight software. Onboard software for the bus and payload, often built on open source flight software frameworks, real time operating systems or embedded Linux, plus vendor board support packages and drivers.
• Onboard security libraries. Implementations of space link security protocols that protect commands and telemetry. The same library often runs on both ends of the link.
• Simulators and digital twins. Software in the loop and hardware in the loop test benches that run the same flight code on the ground. They often sit on less protected networks.

User segment

• User terminals and gateways. Firmware and management software for terminals.

Enterprise and cloud

• Build systems and CI. The pipelines that build flight and ground software, including compilers, toolchains, package mirrors and container registries.
• Cloud services. Mission data platforms, ground station as a service, and the identity systems that sit in front of operator consoles.

Why space makes this harder

Two facts make the space version of the problem harder than the terrestrial one.

First, onboard software can be expensive or impossible to patch after launch. A component chosen during integration can last the life of the mission.

Second, every change near the command path needs testing, scheduling and contact windows. You can only schedule so many changes, so ranking matters.

The regulations and frameworks that apply

There is no single space software security regulation in the United States. Operators work from a policy directive, NIST reports, NASA guidance, FCC licensing and the requirements their customers write into contracts. The sections below give the status of each as checked on 25 October 2026.

Space Policy Directive 5 (4 September 2020)

Space Policy Directive 5, "Cybersecurity Principles for Space Systems", was issued on 4 September 2020. It defines a space system broadly, to include ground systems, sensor networks and one or more space vehicles, and it sets principles for space system owners and operators. They include protecting ground systems, communications links and command and control functions, and applying cybersecurity hygiene and physical security to systems such as antennas, terminals, receivers and routers.

Its supply chain principle is specific. It calls for the management of supply chain risks that affect cybersecurity of space systems "through tracking manufactured products", sourcing from trusted suppliers, identifying counterfeit, fraudulent and malicious equipment, and assessing other available mitigations. For software, "tracking manufactured products" translates naturally into knowing what components and versions went into each build you field.

SPD-5 sets principles rather than penalties and reaches operators through agency guidance and contracts.

NIST IR 8401: the satellite ground segment (December 2022)

NIST IR 8401, "Satellite Ground Segment: Applying the Cybersecurity Framework to Satellite Command and Control", was published in December 2022 by authors from NIST and MITRE. Its abstract says it applies the NIST Cybersecurity Framework to the ground segment of space operations, with an emphasis on command and control of satellite buses and payloads.

For supply chain work, its asset, vulnerability and supply chain management categories apply directly to the C2 system. IR 8401 is a profile, not a checklist with pass marks.

IR 8401 predates CSF 2.0, which NIST published on 26 February 2024. CSF 2.0 added the Govern function and placed cybersecurity supply chain risk management in it, under the GV.SC category. Keep IR 8401's ground content and record evidence against CSF 2.0 outcomes.

NIST IR 8270: commercial satellite operations (July 2023)

NIST IR 8270, "Introduction to Cybersecurity for Commercial Satellite Operations", was published in July 2023 by authors from NIST and MITRE. Its abstract describes space as an emerging commercial critical infrastructure sector and says cybersecurity risks to commercial satellite vehicles need to be managed alongside other risks. It frames the whole commercial operation, including the space segment.

NIST IR 8441: hybrid satellite networks (September 2023)

NIST IR 8441, "Cybersecurity Framework Profile for Hybrid Satellite Networks (HSN)", was published in September 2023, again by NIST and MITRE authors. NIST's page notes that it references CSF 1.1. It covers architectures that aggregate independently owned and operated satellites and networks into one service. If your service rides on or resells another operator's capacity, or combines satellite and terrestrial links, this profile describes the shared risk, including the software and data you exchange with partners.

NASA's Space Security Best Practices Guide (22 December 2023)

NASA released the first iteration of its Space Security Best Practices Guide on 22 December 2023. NASA says the guide is meant to bolster mission cybersecurity for both public and private sector space activities, that it was designed to benefit international partners and industry as well as NASA, and that it provides guidance for missions, programs or projects of any size. NASA developed it to support the goals of SPD-5.

It is guidance, not a contract clause.

NASA also publishes some of the open source software the industry builds on, including the space link security library discussed in the incidents section below.

The FCC and its Space Bureau

The Federal Communications Commission licenses commercial satellite and earth station systems. Its Space Bureau, by its own description, leads policy and licensing for satellite and space based communications, authorizes satellite and earth station systems, and fosters efficient use of spectrum and orbital resources.

We found no FCC rule, as of 25 October 2026, that requires satellite operators to keep a software inventory or provide an SBOM. Individual licenses can carry conditions, so read your own authorizations. For now, federal customers are the stricter source of requirements.

Space ISAC

The Space Information Sharing and Analysis Center (Space ISAC) says its mission is to help the global space industry prepare for and respond to vulnerabilities, incidents and threats, and to share timely information among members. It runs a watch center and publishes public reports. Membership is voluntary.

Federal customer requirements

If you sell software or data services to federal agencies, two current documents shape the evidence they can ask for.

• OMB M-26-05 (23 January 2026), "Adopting a Risk-based Approach to Software and Hardware Security", rescinded OMB M-22-18 and M-23-16. Agencies must keep a complete inventory of software and hardware and set assurance policies that match their risk. They may use the government wide secure software development attestation form, and they may adopt contract terms that require a software producer to provide a current SBOM on request.
• CISA's 2026 Minimum Elements for a Software Bill of Materials (29 July 2026), released with the NSA, the FBI and international partners, updates and replaces the minimum elements NTIA published in 2021. When a program office asks for an SBOM, this is the reference for what it should contain.

NIST SP 800-218, the Secure Software Development Framework, remains the practice reference that attestations and contract terms draw on.

If you sell to the Department of Defense, CMMC and DFARS 252.204-7012 apply to contracts involving controlled unclassified information. Our aerospace and defense guide covers that path in detail, so this post does not repeat it.

How the pieces fit

Real public incidents from the last three years

The cases below come from NIST's National Vulnerability Database and a CISA alert. They show where space operators' software risk actually comes from. They describe published vulnerabilities, not attacks on any operator, and they are not a judgment of any project.

A space link security library: repeated CVEs from 2024 to 2026

NASA's CryptoLib implements the CCSDS Space Data Link Security protocol, extended procedures, to secure communications between a spacecraft running the core Flight System and a ground station. NVD shows a steady run of entries for it:

• 27 September 2024: CVE-2024-44910, CVE-2024-44911 and CVE-2024-44912, out of bounds reads in version 1.3.0 in the AOS, telecommand and telemetry subsystems.
• 17 March 2025: CVE-2025-29909 and related entries. NVD describes a heap buffer overflow in the function that applies security to telecommand frames, in versions 1.3.3 and earlier, where a crafted frame can cause out of bounds writes, leading to denial of service or, under certain conditions, remote code execution.
• 27 April 2025: CVE-2025-46672 through CVE-2025-46675, for versions before 1.3.2, covering unchecked return status in over the air rekeying, use of a security association that is not in an operational state, and key state not checked before use.
• 10 January 2026: a further batch of entries rated high to low.
• 18 September 2026: CVE-2026-79954, an authentication downgrade in the telecommand receive path of version 1.5.0, where the receiver selects the security association from a field in the incoming frame without checking that it is authorized for that frame's channel.

The supply chain lesson is about tracking, not blame. A library like this often sits in both the flight build and the ground TT&C stack. It is often vendored or pinned to a commit, so a dependency scanner may not see it unless someone records it.

Open source mission control frameworks: Yamcs (2023 and 2026)

Yamcs is an open source mission control framework. On 20 November 2023 NVD published entries for Yamcs 5.8.6 including cross site scripting via a crafted telecommand (CVE-2023-46470) and an issue that allows sending arbitrary telecommands in a command stack via clickjacking (CVE-2023-47311). In July and August 2026 NVD published a much larger batch for versions before 5.12.7 and 5.12.8. One of them, CVE-2026-44632, describes server side code injection in the algorithm evaluation engine: an authenticated user with the privilege to change the mission database could override an algorithm's text and run Java code on the host.

Open source mission control frameworks: OpenC3 COSMOS (2024 to 2026)

OpenC3 COSMOS describes itself in its CVE entries as providing the functionality needed to send commands to and receive data from embedded systems. NVD lists three entries published on 2 October 2024, a batch on 13 June 2025 for versions before 6.0.2 and 6.1.0, and further batches in January, May and September 2026. The June 2025 entries include a credential leak where service credentials were exposed as environment variables in all containers (CVE-2025-28381), hardcoded credentials for a service account (CVE-2025-28388), and remote code execution through the plugin management component (CVE-2025-28386).

Mission control frameworks are exactly the command and control layer IR 8401 is about. They are also modern web applications with container images, scripting engines, authentication modules and their own third party libraries.

A backdoor in a widely used compression library (March 2024)

On 29 March 2024 CISA warned that malicious code had been embedded 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. XZ Utils is not space software. It is included because ground systems run on Linux, and the question that week was which hosts and images carry this component, at which version.

All four involve components the operator did not write, and in each the first useful action was an inventory lookup.

The personas who own the problem

No single person owns software supply chain security at a space operator. The table shows who usually holds each piece, what they need, and when.

What each role is really asking

The CISO is asking whether the company can answer three questions on demand. Which systems run a given component and version? Which of those touch the command path? How fast can we fix or isolate them? That inventory is what an insurer or program office will probe.

The VP Engineering or flight software lead cares about engineering time and launch dates. This lead needs to see vulnerable components early, at design and integration, and needs a clean way to record "known, assessed, not exploitable in this configuration" for findings that cannot be fixed before launch.

The ground segment or mission operations lead lives by contact windows. This persona needs findings ranked by whether the vulnerable code is actually used and whether the system is reachable, so the few changes they can schedule are the right ones.

The GRC or compliance lead needs dated, attributable records: SBOMs per system and release, scan results with timestamps, pull requests or tickets that show fixes, and exceptions with reasons and expiry dates. Mapping those records to IR 8401 categories and CSF 2.0 outcomes is the work an auditor or customer will sample.

The DevSecOps or platform engineer needs tools that run where the code is. Flight and mission control builds often happen in isolated networks. Scans and gates need to work there, fail builds for clear reasons, and not add minutes to every merge.

The procurement or supplier risk owner needs a contract and a record. The contract is where SBOM delivery, vulnerability notification timelines and support periods get set, and the record shows who delivered what and when.

Product security for terminals and customer facing services needs to publish what is and is not affected when a CVE drops, so customers do not flood support with the same question.

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

This plan works with any tooling: open source SBOM generators and scanners, spreadsheets and your existing CI. It assumes a small security team and engineering teams who are already busy. Adjust the scope to your mission count and the number of ground sites.

Days 1 to 30: scope and inventory

1. Draw the system boundary on one page. List ground systems (mission control, TT&C front ends, flight dynamics, scheduling, ground station software, data pipelines, customer portals), flight software builds per mission, simulators and test benches, and the CI systems that build all of them. Mark which ones sit on the command path and which face the internet.
2. List every repository and build. For each system, record the repositories, build system, languages and container images. Include forks and vendored code. Flight frameworks and protocol libraries are often copied into the tree; list them as components anyway, with the upstream project and the version or commit.
3. Generate an SBOM per build. Use SPDX or CycloneDX. Produce one for each ground system release and each flight software build. Where package managers cannot see vendored C and C++ code, add those components to the SBOM by hand or with a manifest your build reads.
4. Run a first vulnerability pass. Match the SBOMs against vulnerability sources. Do not fix anything yet. Count findings by system and command path.
5. Pick your reference profile. Choose IR 8401 for ground C2, IR 8270 for the whole operation, or IR 8441 if you run a hybrid network, and decide which CSF 2.0 outcomes you will record evidence against. Write down which categories your inventory and scanning will evidence.
6. Subscribe to the right feeds. Watch advisories from the upstream projects you depend on, CISA's Known Exploited Vulnerabilities catalog, and an ISAC feed if you are a member.

Days 31 to 60: fix, gate and ask suppliers

1. Rank the backlog. Sort findings by exploitation evidence (KEV listing, EPSS score), whether the vulnerable function is reachable from your code, and whether the system is on the command path or internet facing. Take the top slice to the ground and flight leads.
2. Fix what you can on the ground first. Ground systems can usually be patched in a maintenance window. Keep a rollback.
3. Record decisions for what you cannot fix. For flight builds after freeze, or for findings that do not apply in your configuration, write an exception with a reason, an owner and an expiry date. If you deliver software or terminals to customers, turn these into VEX statements.
4. Add a gate to CI. Start with Warn on new critical findings for ground repositories and on new dependencies with no fix path. After two weeks of tuning, move the most important rules to Block.
5. Send SBOM requests to suppliers. Start with the bus manufacturer, payload suppliers, ground station providers and any vendor whose software sits on the command path. Ask for an SBOM per delivered version and a vulnerability notification commitment.
6. Lock down the build. Pin dependencies, use lockfiles, mirror packages into an internal registry for isolated networks, and record which mirror and which versions each build used.

Days 61 to 90: prove it and keep it running

1. Rehearse an advisory. Pick a real recent CVE in a component you use. Time how long it takes to answer which systems are affected, which are on the command path, and what the fix plan is.
2. Map evidence to your profile. For each IR 8401 category or CSF 2.0 outcome you chose, link the SBOMs, scan records, exceptions and pull requests that evidence it.
3. Write the supplier clause. Work with procurement and counsel on standard contract language for SBOM delivery, notification timelines and support periods.
4. Set a cadence. SBOM per release, rescans against stored SBOMs on a schedule (new CVEs arrive after you ship), monthly exception review, and quarterly supplier review.
5. Brief leadership. One page: inventory coverage, open critical findings on the command path, time to answer the rehearsal question, and supplier coverage.

Template: evidence checklist for a customer or auditor sample

Template: supplier SBOM request (plain text you can adapt)

"For each software or firmware version you deliver to us under this agreement, please provide a software bill of materials in SPDX or CycloneDX format that meets CISA's 2026 Minimum Elements for a Software Bill of Materials. Please notify us within an agreed number of business days when a vulnerability affecting a delivered component becomes known, with your assessment of exploitability in our configuration and your fix plan. Please state the support period for each delivered version."

Your counsel should adapt the timing and remedies. The point is to ask for the same three things every time: an SBOM, notification and a support commitment.

Decision table: what to do with a finding

Illustrative scenario: one advisory, 48 hours

This is an illustrative scenario with invented round numbers. An advisory lands on a Tuesday for a mission control framework the operator uses. Because there is an SBOM per release, the security team finds the framework in three ground systems and one simulator within an hour. Two of the three are on the command path, and the vulnerable function is reachable in one. The ground lead schedules an upgrade for that one in the next maintenance window, restricts network access to it until then, and records exceptions with expiry dates for the other two while the team tests the upgrade. The GRC lead saves the records.

How Safeguard does this

Safeguard is a software supply chain security platform. The steps below follow the plan above and use only flows described in Safeguard's offering documentation and docs.safeguard.sh. Every capability named here is generally available (GA).

1. Choose where Safeguard runs. For isolated mission networks, Safeguard offers on-prem and fully air-gapped deployment (GA). The air-gapped deployment docs describe a signed snapshot bundle that ships on a cadence you choose, through a receiver in your DMZ that verifies signatures and pushes deltas to the control plane. The docs say no component inside the perimeter ever calls outbound, and that each bundle carries vulnerability feed deltas including CISA KEV and daily EPSS. If you want no AI in the loop at all, Zero AI mode (GA) runs the platform deterministically; bring your own model (GA) is the other option.

2. Keep source on your machines with the local runner. The Safeguard CLI and local runner (GA) scan on your own systems. The CLI docs show one target per scan:

   # A local directory (your own or proprietary code)
   safeguard scan --dir .
   
   # A container image in a private registry
   safeguard scan --image myregistry.azurecr.io/myapp:v1 \
     --registry-username "$REGISTRY_USER" \
     --registry-password "$REGISTRY_PASSWORD"
   
   # An SBOM you already have (SPDX or CycloneDX)
   safeguard scan --sbom sbom.json
   

   The docs say a signed in scan from the interactive terminal uploads the SBOM and findings, never the source. These snippets are copied from the docs and were not run for this post.

3. Build the inventory. SBOM generation and analysis (GA) produces SPDX and CycloneDX, and SCA with deep transitive dependency scanning (GA) covers application dependencies and container layers. For vendored flight libraries that no package manager declares, add them to the SBOM you feed in with --sbom; a scanner can only match what the SBOM names.

4. Validate what suppliers send. The CLI docs show a validator for SBOM and VEX documents:

   safeguard validate sbom.json --strict -o report.json
   

   It checks CycloneDX, SPDX and VEX (CSAF and OpenVEX) documents against their specifications, and --strict treats warnings as errors.

5. Prioritize flaws. Vulnerability management (GA) enriches findings with EPSS and CISA KEV. Reachability analysis (GA) ranks findings by whether your code calls the vulnerable path, which is the ranking the ground lead needs for scarce maintenance windows.

6. Gate new risk in CI. Policies and gates (GA) evaluate SBOMs and findings. Each policy's action is Block (the gate fails), Warn (the gate passes with a warning) or Notify (the gate passes and a notification is sent). When a legitimate exception is needed, a developer requests it with a business justification and an expiration date, approvers decide, and the docs describe an audit trail. To fail a CI job on a gate, the docs show:

   safeguard ci scan --wait --fail-on-gate <gate>
   

   License compliance (GA) applies license policy to the same components.

7. Open fix pull requests, under your control. Autonomous remediation (GA) has Griffin open tested, policy gated pull requests that move a dependency to a fixed version, one repository at a time or in bulk. It ships switched off, with every category set to Manual, so your team decides what runs on its own. For flight builds after freeze, leave it on Manual and record an exception instead.

8. Map evidence to frameworks. The compliance and GRC suite (GA) has a NIST CSF 2.0 framework page. The docs list scan checked requirements against a product's SBOM, including supplier and product risk understanding under GV.SC-07, SBOMs as supply chain evidence, and vulnerability identification under ID.RA-01. Record your IR 8401 ground segment content against those CSF 2.0 outcomes; the mapping from IR 8401 to CSF 2.0 is your work.

9. Request SBOMs from suppliers. TPRM (GA) lets you send a single SBOM request from a vendor record or a bulk request to several vendors, using a template that sets format requirements (SPDX or CycloneDX), submission instructions and a deadline. The docs describe status tracking and automatic reminders.

10. Publish transparency for delivered products. CSAF and VEX upload (GA) records exploitability statements for terminal firmware and customer software. Trust Center (GA) gives customers a page for your security posture.

Need, what Safeguard does, what you still own

What Safeguard does not do

• It does not secure the RF link. Link encryption, authentication of telecommands, key management and anti jamming measures are radio and protocol engineering.
• It does not patch spacecraft. Whether and how to upload a software change to a spacecraft is a mission decision with its own testing, verification and risk process.
• It does not see code nobody declared. A vendored library with no manifest only appears in results if your SBOM names it. Building that record for flight code stays with your team.
• It does not scan modem firmware or vendor appliances you cannot build. Fixes for those come from the vendor; your part is the SBOM request and the contract.
• It does not license you or certify you. FCC authorizations, customer accreditation and any audit outcome stay with the relevant body.
• It does not report incidents for you. Notifying customers, agencies, insurers or an ISAC stays with your team.
• Safeguard's own posture. Safeguard is designed for FedRAMP High, and its SOC 2 Type II audit is in progress. Neither says anything about your environment.

Common mistakes

• Treating flight software as out of scope because it is embedded.
• Forgetting vendored code. If the package manager cannot see it, the SBOM must name it.
• Scanning once and never again. New CVEs land against old versions. Rescan stored SBOMs on a schedule, especially for missions already in orbit.
• Leaving simulators and test benches off the inventory.
• One queue for everything. A finding on the command path and a finding in the marketing site should not compete for the same maintenance window.
• Exceptions without expiry dates.
• Asking suppliers for "an SBOM" with no format or content standard. Name SPDX or CycloneDX and CISA's 2026 minimum elements, or you will receive a PDF.
• Waiting for the FCC. Federal customers and insurers are already asking.

FAQ

Is there a US regulation that requires satellite operators to keep an SBOM?

Not a general one that we found as of 25 October 2026. SBOM requirements reach space operators through customers. OMB M-26-05 lets federal agencies adopt contract terms that require a current SBOM on request, and primes increasingly pass similar terms down.

What is NIST IR 8401?

NIST IR 8401 is a December 2022 NIST report, written with MITRE, that applies the NIST Cybersecurity Framework to the satellite ground segment with an emphasis on command and control of buses and payloads.

Does the FCC regulate satellite cybersecurity?

The FCC licenses satellite and earth station systems through its Space Bureau, which focuses on licensing, spectrum and orbital resources. We found no FCC rule that requires a software inventory or SBOM from satellite operators.

What does SPD-5 say about supply chains?

Space Policy Directive 5 lists management of supply chain risks that affect cybersecurity of space systems among its principles. It names tracking manufactured products, sourcing from trusted suppliers, identifying counterfeit, fraudulent and malicious equipment, and assessing other mitigations.

Does NASA's Space Security Best Practices Guide apply to commercial operators?

It is guidance, not a regulation. NASA says it was designed to benefit industry and international partners as well as NASA, for missions of any size.

Is flight software part of the software supply chain?

Yes. Flight frameworks, operating systems, board support packages and protocol libraries are third party components.

How do we handle vulnerabilities in software that is already in orbit?

Record an exception with the reason, an owner and an expiry date, describe the compensating controls on the ground and the link, and plan the fix for the next update opportunity if the mission has one. Rescan the stored SBOM on a schedule so new advisories against old versions do not go unnoticed.

What should we ask ground station providers and other suppliers for?

An SBOM per delivered software version in SPDX or CycloneDX, a vulnerability notification commitment with a timeline, a support period for each version, and a description of how their systems connect to yours.

Which framework should a commercial satellite operator use?

Use NIST CSF 2.0 as the backbone, IR 8401 for ground command and control, IR 8270 to frame the whole commercial operation, and IR 8441 if you run or join a hybrid network. Add whatever your customers' contracts require on top.

Related reading

• Software supply chain security for aerospace and defense: regulations, incidents and a 90-day plan
• Software supply chain security for telecommunications
• Satellite terminals and the KA-SAT lessons
• How satellites are built: bus, payload, testing and flight software
• Why embedded and space code still uses C

Where the NVD entries above name a fixed release, the work was finding every place the old version ran and moving it forward without breaking the command path. The section below covers the parts of that work that apply to the open source dependencies and container images in your ground software, and what to do when no fix exists yet.

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

The first demo sets up the local runner on your own machine, approves it with its device code, and then scans from the terminal. This is the pattern for an isolated mission network: the scan happens where the code lives, and only results leave the machine.

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

The second demo is a real CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE in a repository. The assistant reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, and runs npm install and npm test with approval. It prints a summary and pushes nothing. The same flow suits a ground software repository where the mission operations lead wants a fix prepared for review and scheduled for the next maintenance window, not merged on its own.

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

Quick check

Sources

• The White House (archived): Memorandum on Space Policy Directive 5, Cybersecurity Principles for Space Systems
• NIST: IR 8401, Satellite Ground Segment
• NIST: IR 8270, Introduction to Cybersecurity for Commercial Satellite Operations
• NIST: IR 8441, Cybersecurity Framework Profile for Hybrid Satellite Networks
• NIST: CSWP 29, The NIST Cybersecurity Framework 2.0
• NASA: NASA Issues New Space Security Best Practices Guide
• FCC: Space Bureau
• Space ISAC
• OMB: M-26-05, Adopting a Risk-based Approach to Software and Hardware Security
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Reported Supply Chain Compromise Affecting XZ Utils, CVE-2024-3094
• CISA: Known Exploited Vulnerabilities Catalog
• NIST: SP 800-218, Secure Software Development Framework
• NVD: CVE-2024-44911 (CryptoLib)
• NVD: CVE-2025-29909 (CryptoLib)
• NVD: CVE-2025-46673 (CryptoLib)
• NVD: CVE-2026-79954 (CryptoLib)
• NVD: CVE-2023-47311 (Yamcs)
• NVD: CVE-2026-44632 (Yamcs)
• NVD: CVE-2025-28381 (OpenC3 COSMOS)
• NVD: CVE-2025-28386 (OpenC3 COSMOS)
• Safeguard docs: Air-gapped deployment
• Safeguard docs: CLI usage
• Safeguard docs: Policies and gates
• Safeguard docs: TPRM SBOM requests
• Safeguard docs: NIST CSF 2.0 framework

To try the flows above, download Safeguard at safeguard.sh/download and read the documentation at docs.safeguard.sh/docs.

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