CM0020 Threat modeling Threat modeling is a structured analytical process that identifies, enumerates, and prioritizes potential threats to a system by systematically examining assets, trust boundaries, data flows, and adversary capabilities relative to the system's architecture. Applied in combination with attack surface analysis and vulnerability analysis, threat modeling produces an integrated picture of where the system is most exposed and what the consequences of successful exploitation would be. Analysis should draw on findings from similar systems, components, or services where applicable, leveraging documented threat experience from comparable missions or architectures to avoid re-learning known lessons. The outputs of threat modeling must directly inform design decisions throughout the development process, with attack surface reduction treated as a design objective rather than a post-development hardening activity: interfaces, services, protocols, and code paths that are not necessary to mission function should be eliminated or constrained before they become embedded in the architecture. Threat model artifacts should be treated as living documents, updated as the system design evolves and as new threat intelligence becomes available.
CM0022 Criticality Analysis Criticality analysis is a structured engineering process that identifies the mission functions, system components, and data flows whose compromise, degradation, or loss would most severely impact mission success, crew safety, or operational continuity. The outputs of this analysis directly drive security investment prioritization: components and functions assessed as most critical receive the most rigorous design-phase protections, supply chain scrutiny, and operational security controls, while lower-criticality elements are protected proportionately. Criticality analysis findings should inform the application of complementary security design principles, including network and functional segmentation and least-privilege access control, to isolate critical components from less-trusted system elements and reduce the consequence of compromise elsewhere in the system. Supply chain protection resources and oversight rigor should be explicitly allocated in proportion to component criticality, ensuring that the most mission-essential hardware and software receive the most intensive sourcing controls, provenance verification, and supplier oversight. Criticality analysis must be initiated early in the system design process and updated as the architecture evolves, threat intelligence changes, or operational experience reveals previously unrecognized dependencies.
CM0024 Anti-counterfeit Hardware Counterfeit electronic components represent a direct supply chain threat to space mission integrity, introducing hardware that may fail prematurely, perform outside specification, or contain malicious functionality deliberately embedded by an adversary during manufacture or distribution. A formal anti-counterfeit program must establish policy and procedures that span the entire component acquisition and integration lifecycle, from supplier qualification and procurement through incoming inspection, storage, and installation. The program must address two distinct but related risks: counterfeit components that fail to perform their intended function, degrading mission reliability; and deliberately tampered components that introduce malicious hardware functionality or create pathways for malicious code execution. Anti-counterfeit controls must include measures appropriate to component criticality and supply chain risk to authenticate components, detect evidence of tampering, and resist unauthorized modification. Detection and prevention must be treated as complementary objectives: prevention through qualified sourcing and procurement controls, detection through inspection and authentication techniques applied before components enter the system.
CM0004 Development Environment Security A secure development environment requires a current and sufficiently complete inventory of the people, devices, software, services, credentials, and automated identities capable of accessing or influencing the environment. The development environment includes source-code repositories, developer workstations, build servers, CI/CD runners, compiler and linker toolchains, container and virtual machine images, package registries, artifact repositories, signing systems, test environments, integration laboratories, and release-staging systems.
For space systems, these environments may produce or manage flight software images, firmware, FPGA bitstreams, software-defined radio waveforms, command and telemetry databases, configuration tables, ephemerides, calibration products, fault-management logic, and on-orbit update packages. Unmanaged assets, unauthorized access, compromised dependencies, altered toolchains, and untrusted build services are significant pathways through which adversaries may maliciously modify software or other mission artifacts during development and build activities.
All personnel and assets touching the development environment must be inventoried and actively managed. MFA shall be enforced for human access, while non-human identities shall use managed workload identities, scoped credentials, protected secrets, and defined rotation or expiration period, with particular rigor applied to code repositories, where threat actors may attempt to inject malicious code into software under development without detection. Zero-trust access controls should govern repository access, with protected branch and tag policies shall restrict direct modification, prohibit unauthorized force pushes or deletion, require successful security checks, and require independent review before merging or releasing critical code. Effective development environment security also requires integrated change management, privilege management, comprehensive audit logging, and continuous in-depth monitoring across all components of the environment.
CM0007 Software Version Numbers Software version information for commercial off-the-shelf (COTS), open-source software (OSS), firmware, operating systems, libraries, middleware, bootloaders, software-defined radios, and other software-enabled components used in spacecraft and ground systems must be protected from unauthorized or unnecessary disclosure. Exact component versions can allow adversaries to correlate an identified product or library with public vulnerability databases, vendor advisories, exploit repositories, known configuration weaknesses, and software-specific backdoor or supply-chain opportunities.
Version information may be exposed directly through telemetry fields, network and service banners, diagnostic commands, management interfaces, error messages, log outputs, crash reports, configuration files, package manifests, filenames, firmware headers, debug symbols, update metadata, and publicly released documentation. Versions may also be inferred indirectly through protocol behavior, command responses, file hashes, default configurations, timing characteristics, or software-specific error conditions. These disclosure paths should be identified and controlled according to mission risk.
Authoritative version information must remain available through controlled mechanisms to authorized developers, maintainers, operators, assessors, and incident responders. CM0007 is intended to limit unauthorized disclosure of exact software versions, not to eliminate internal software identification, configuration tracking, or diagnostic capability. Version-number protection increases the effort required for adversary reconnaissance but does not prevent active fingerprinting or mitigate vulnerabilities present in the software.
CM0010 Update Software Regular software and firmware updates are a primary mechanism for reducing exploitation risk by remediating known vulnerabilities before adversaries can leverage them against mission systems. Updates must undergo suitable regression testing to verify that security patches do not introduce functional defects or degrade safety-critical behaviors before deployment to operational systems. Release cadence should be governed by a mission-defined update frequency that balances vulnerability severity, exploitability, mission risk tolerance, testing requirements, and operational constraints. The program should define maximum allowable remediation or deployment timeframes (e.g., 30 days) for applicable vulnerability severities rather than applying a single update interval to all software and firmware. Update scheduling must account for operational constraints, coordinating patch deployment with mission downtime windows to avoid disrupting critical operations. Following a successful update, superseded software versions should be removed from active operational use unless retained as an authorized recovery image. Verified restoration images, commonly referred to as gold images, should be retained under access and integrity controls to support recovery when an update introduces unacceptable system behavior or an authorized rollback is operationally required.
CM0012 Software Bill of Materials A software bill of materials (SBOM) is a structured inventory of software components, libraries, dependencies, and associated metadata comprising a delivered system, spanning first-party code and available third-party and open-source supply-chain information. The SBOM serves as the foundational reference for continuous vulnerability management: by cross-correlating the component inventory against known vulnerability databases, such as those cataloging common vulnerabilities and exposures (CVEs), mission owners and operators can rapidly identify which specific system components are affected by newly disclosed vulnerabilities and prioritize remediation accordingly. SBOM generation must cover the full software supply chain, including transitive dependencies that are not explicitly declared in top-level manifests, as these indirect inclusions represent a persistent and frequently exploited blind spot in software inventory programs. An SBOM may reveal component composition and vulnerability-relevant information that could assist adversary reconnaissance. Its classification, sensitivity, dissemination, and handling requirements shall be determined using applicable mission guidance, contractual requirements, and a documented disclosure-risk assessment. If deemed to have sensitive information then the handling controls applied should align to other mission-critical security documentation as defined in CM0001.
CM0017 Coding Standard A formally defined coding standard establishes the rules, conventions, and constraints that govern how software is written across the mission's development program, directly influencing the security, maintainability, and verifiability of the delivered system. The standard must specify acceptable programming language types, with language selection driven by a documented evaluation of security requirements, application complexity, scalability needs, available development resources, schedule constraints, and the availability of security-relevant language features such as memory safety, type safety, and bounds checking. Language choices that introduce classes of vulnerability by design, such as languages without memory safety guarantees used in contexts where memory corruption is a plausible attack vector, require explicit justification and compensating controls. The coding standard must include security-relevant rules for input validation, error handling, cryptographic usage, memory management, and concurrency, as applicable to the selected languages and system design. Adherence should be evaluated through automated means where supported, supplemented by manual review for requirements that cannot be reliably automated.
CM0006 Cloaking Safe-mode Safe-mode entry represents a high-risk transition point at which a spacecraft enters a reduced-capability state to preserve vehicle safety and support anomaly recovery. This transition must not create a less secure command, telemetry, or onboard processing environment. To the extent permitted by mission safety and recovery requirements, the spacecraft should avoid unnecessary or uniquely identifying changes in transmission characteristics, beacon content, communication cadence, and externally observable behavior that would allow an adversary to reliably identify and exploit the safe-mode state.
Safe-mode shall preserve the mission-defined minimum security posture for every communication path and command mechanism that remains active. This posture should include authentication, data integrity, anti-replay protection, command authorization, command validation, cryptographic key protection, security-relevant logging, and encryption where confidentiality is required. The spacecraft shall not enter a crypto-bypass or unauthenticated command state solely because safe-mode has been activated.
The safe-mode software and configuration baseline shall explicitly define the security controls, command dictionaries, alternate receivers, contingency communication paths, rate and size limits, command counters, time tag requirements, interlocks, logging functions, and monitoring capabilities that remain active during safe-mode. These protections shall be designed and verified as part of the safe-mode baseline rather than treated as discretionary functions that may be removed without security impact analysis.
CM0044 Cyber-safe Mode Cyber-safe mode is a dedicated, configuration-controlled spacecraft operating state entered autonomously or by authorized ground command when mission-defined conditions indicate a credible threat to platform integrity. In this state, nonessential functions are shut down or isolated and the spacecraft operates from an integrity-protected, validated software and configuration baseline. Unlike traditional safe mode, which addresses hardware faults and operational anomalies, cyber-safe mode is specifically designed to respond to cyber threats, providing a secure recovery baseline from which the spacecraft can reconstitute compromised functions. Authentication and encryption must remain enabled within cyber-safe mode, ensuring that the reduced operational state does not degrade the security posture of the vehicle. The cyber-safe mode software and configuration must be stored onboard using hardware-based protections that prevent modification by nominal flight software, ordinary commands, and other untrusted execution paths. Where baseline updates are permitted, they must use a separately authorized and integrity-verified maintenance process that preserves a recoverable trusted version. Following entry into cyber-safe mode, the spacecraft must be capable of reconstituting firmware and software functions to pre-attack capability levels, either autonomously through self-healing mechanisms or with ground assistance, and must be capable of replanning operations based on whatever equipment remains available after the cyber event. The primary recovery objective is restoration of full mission capability; where that is not achievable, the spacecraft should attain the maximum reduced mission capability available given the post-attack system state.
CM0014 Secure boot Secure boot establishes and enforces a cryptographically verified chain of trust from a hardware-anchored root of trust (RoT) through each applicable stage of the startup sequence to the operating system or flight software image. Each stage in the chain must verify the integrity and authenticity of the next before transferring execution control. The boot policy must also prevent execution of unauthorized or revoked images, including unauthorized rollback to an older but validly signed software version. The trust anchor and initial verification function should be immutable after provisioning or protected by hardware-enforced mechanisms that prevent unauthorized modification and preserve their integrity. Components implementing the RoT must also be qualified for the expected mission radiation environment. Radiation tolerance addresses the reliability of the trust anchor, while immutability or protected update mechanisms address its resistance to unauthorized modification. This is particularly critical where radiation-induced bit flips and the physical inaccessibility of on-orbit hardware make a tamper-resistant, immutable hardware anchor essential to sustained boot integrity across the mission lifetime.