Key Takeaways
- A study found 2,827 candidate weaknesses across 126 satellite software repositories.
- Most findings appeared in project-developed code rather than external dependencies.
- Procurement rules could require software inventories, test evidence, and remediation plans.
Satellite Flight Software Security Enters the Procurement Process
A September 14, 2026 satellite flight software security study examined 126 public repositories containing software relevant to onboard spacecraft functions. After removing duplicate, irrelevant, and out-of-scope scanner results, the researchers retained 2,827 candidate security and code-quality findings. Ninety-two repositories contained at least one retained finding, and 71.8% of the findings received a medium-or-higher severity classification from the analysis tools.
Those numbers do not prove that 92 satellites can be compromised. Public repositories may differ from the code loaded onto operational spacecraft, and automated findings require human review. The study expressly states that it does not establish mission-specific exploitability. Its contribution is a structured picture of recurring software weaknesses across an open-source sample.
That distinction matters for satellite procurement. Government agencies and commercial buyers increasingly purchase spacecraft as integrated services rather than reviewing every component themselves. Software can control attitude, power, communications, payloads, propulsion, and fault management. New Space Economy’s examination of essential space infrastructure describes spacecraft and ground facilities as connected cyber-physical systems. A defect in onboard code can affect several physical functions even when the satellite’s hardware performs as designed.
What the Researchers Actually Measured
The research team combined several automated methods. These included software bill of materials generation, software composition analysis, static code testing, configuration review, and secret scanning. A software bill of materials identifies incorporated software components and their versions. Static testing examines source code without executing it, looking for patterns associated with programming errors or security weaknesses.
The pipeline initially produced 28,274 candidate findings. Filtering removed documentation, test files, ground-only software, generated artifacts, duplicate detections, and other material outside the onboard scope. The remaining 2,827 entries included 1,330 security-focused source-code alerts, 1,157 correctness or quality warnings, 263 dependency or advisory matches, 42 possible exposed secrets, and 35 configuration findings.
Severity labels require restraint. A tool may identify code that could become dangerous under certain conditions without showing that an attacker can reach it. Configuration, processor architecture, communication paths, permissions, and mission operations all affect exploitability. The researchers found that one scanning tool heavily influenced some aggregate categories, although flight software remained the largest subsystem group after sensitivity testing.
The study offers a repeatable method for comparing repositories. It does not provide a failure probability for an operational mission. Buyers could use such analysis as one input to assurance, combined with architecture review, testing, operational monitoring, and evidence from the actual flight configuration.
Why Project-Developed Code Deserves More Attention
Project-developed code accounted for 81.4% of the retained findings. External dependencies accounted for 18.6%. That result challenges procurement approaches that focus almost entirely on third-party libraries and published vulnerability databases.
A component inventory remains useful. The Cybersecurity and Infrastructure Security Agency promotes software bills of materials as a way to improve visibility into software supply chains. An inventory can help an operator identify whether a spacecraft uses a library affected by a newly disclosed vulnerability. It cannot reveal every logic error, unsafe memory operation, or inadequate trust boundary written inside the mission’s own code.
Memory safety and code quality formed the two largest weakness families in the study. Input validation and injection came next. Nearly half of all retained findings appeared in onboard computers, command-and-data-handling software, or general flight software. Communications and telemetry software formed another significant group.
New Space Economy’s guide to the SPARTA threat framework shows how software exploitation can connect with command interference, data corruption, and loss of spacecraft control. Buyers need evidence that developers examined their own source code, rather than assuming that managing external packages resolves the main exposure.
What Buyers Could Request From Suppliers
Procurement documents can translate software security from a broad expectation into deliverable evidence. The NIST Secure Software Development Framework provides a general structure for secure development practices. Spacecraft contracts can adapt that structure to long mission lifetimes, constrained processors, intermittent links, radiation effects, and limited opportunities for physical repair.
Useful contract deliverables can include a software component inventory, source-code analysis results, documented remediation decisions, and evidence that high-consequence command paths received manual review. Buyers can request a description of the secure update mechanism and the circumstances under which an operator can roll back faulty software. Test evidence should cover malformed commands, lost communications, corrupted data, memory exhaustion, and unexpected subsystem states.
A supplier also needs a process for handling newly disclosed vulnerabilities after launch. Some spacecraft can receive software patches. Others have limited bandwidth, storage, redundancy, or operational flexibility. Patch deployment itself can create mission risk, so operators need validation environments that reproduce the flight configuration.
Procurement requirements should remain proportional. A university CubeSat and a strategic communications satellite carry different consequences. A graded assurance model can connect documentation and testing depth to mission value, service dependency, command authority, and expected operational life.
Why Open Source Is Not the Main Problem
Open-source software makes code available for inspection, modification, and reuse. Visibility can help defenders locate defects and verify fixes. It can also help adversaries study an implementation, although closed code can contain the same weakness without public scrutiny.
New Space Economy’s review of small spacecraft technology notes that modern small satellites increasingly use software-defined functions and commercial ground services. Open-source frameworks can reduce development time and permit smaller teams to reuse tested components. The security result depends on engineering practice, configuration, maintenance, and review rather than the licensing model alone.
The new study found more retained findings in locally developed code than in external dependencies. That does not establish that open-source components are safer. Public repositories gave the researchers access to a sample that proprietary programs rarely provide, creating a selection effect. Closed spacecraft software could contain similar patterns without appearing in the dataset.
Treating secrecy as the main defense also creates operational problems. Contractors change, maintainers leave, and missions outlive their original development environments. Documented code, reproducible builds, and controlled access can improve continuity. Security depends on limiting command paths, verifying identities, monitoring behavior, and designing spacecraft to enter safe states when software behaves unexpectedly.
Commercial and Regulatory Consequences
Satellite operators increasingly sell services to defense agencies, telecommunications companies, weather offices, insurers, and infrastructure managers. Customers may ask for stronger evidence when the service supports public safety, military communications, navigation, or time-sensitive observation. Software assurance could become part of contract qualification alongside spectrum authorization, launch integration, and orbital-debris compliance.
Insurers may also seek evidence about development controls and incident response. Reliable loss statistics for spacecraft cyber incidents remain limited, so insurers cannot price software exposure with the confidence available in mature terrestrial markets. Standardized assurance documents could improve underwriting even if they do not produce a simple security score.
New Space Economy’s analysis of the space countermeasures market identifies protective cybersecurity services as an accessible commercial segment. Code assessment, penetration testing, monitoring, secure ground operations, and incident exercises can support operators that lack large internal security teams.
Regulators face a narrower question. Prescriptive rules can become obsolete as software and threats change. Outcome-based requirements may permit flexibility but produce inconsistent evidence. Procurement can move sooner than regulation because buyers can define assurance deliverables for each mission and adjust them as experience accumulates.
Summary
The September 2026 study provides empirical evidence that candidate security weaknesses occur throughout publicly available onboard satellite software. Its 2,827 retained findings identify recurring concerns in memory handling, code quality, input validation, dependencies, and configuration. The research does not demonstrate that operational spacecraft using these repositories are vulnerable to attack.
Its strongest implication concerns purchasing behavior. A software inventory can expose dependency risk, yet the concentration of findings in project-developed code means buyers also need evidence about source-code review, threat modeling, testing, remediation, and post-launch maintenance. These requirements should reflect mission consequences and should distinguish scanner warnings from verified, reachable flaws.
Satellite flight software security is becoming a product-assurance issue rather than a topic confined to specialist engineering teams. Operators, government buyers, insurers, and service customers can influence development practices by asking suppliers for evidence that survives beyond a proposal or design review. That evidence will not eliminate software defects. It can make responsibility, unresolved risk, and maintenance planning more visible before a spacecraft becomes unreachable hardware in orbit.
