Using knowledge of the software composition on-board, the adversary maps components and versions to publicly or privately known defects and then crafts inputs to trigger them. Typical targets include standard libraries (libc, STL), cryptographic and compression libraries, protocol stacks (CCSDS implementations, IP over space links, SpaceWire bridges), filesystems and parsers (FITS/CCSDS packetization, custom table formats), and vendor SDKs for radios, sensors, or payloads. Triggers arrive as well-formed but malicious packets, frames, or files whose edge-case fields exercise version-specific bugs, overflowing a parser, bypassing an authentication check, or causing a kernel/driver fault that reboots into a more permissive mode. Because these flaws are documented somewhere, exploitation emphasizes matching the exact build and build-time options used on the mission.
| ID | Name | Tiering | Description | NIST Rev5 | ISO 27001 | Onboard SV | Ground | |
| CM0008 | Security Testing Results | Penetration testing, vulnerability scanning, fuzzing, code analysis, adversarial testing, and other security assessment activities are essential for validating the security posture of space systems. However, the artifacts generated by these activities are themselves sensitive mission information requiring protection. Security testing artifacts may include final reports, raw scanner output, working notes, exploit code, proof-of-concept scripts, packet captures, RF recordings, screenshots, logs, memory or core dumps, test credentials, command sequences, telemetry mappings, architecture diagrams, test configurations, remediation records, and copies of software or data collected during testing. Security testing artifacts may reveal exploitable weaknesses, attack paths, security-control gaps, spacecraft and ground-system interfaces, command and telemetry behavior, link characteristics, safety interlocks, test accounts, and system-specific vulnerability conditions. Detailed evidence identifying an exploitable weakness, affected interface, and validated attack method may provide an adversary with much of the information needed to reproduce an attack. Security testing results shall be categorized, marked, handled, stored, transmitted, shared, retained, and disposed of according to their information classification, CUI category, proprietary restrictions, contractual requirements, and mission sensitivity. Protection shall address both unauthorized disclosure and unauthorized modification, because alteration or deletion of test results could conceal vulnerabilities, misrepresent remediation status, or undermine security decisions. Access shall be limited by role and need to know throughout the artifact lifecycle, beginning when the data is generated and continuing through authorized disposition. | AC-3(11) CA-8 CA-8(1) CM-4 CP-4 IR-3 IR-3(1) IR-3(2) IR-6(2) RA-5 RA-5(11) SA-11 SA-11(3) SA-11(5) SA-4(5) SA-5 | A.8.4 A.8.9 A.5.29 A.5.30 A.8.8 7.5.1 7.5.2 7.5.3 A.5.37 A.8.29 A.8.30 | ||||
| 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. | CM-3(2) CM-3(7) CM-3(8) CM-4 CM-4(1) CM-5(6) CM-7(5) SA-10(4) SA-11 SA-3 SA-8 SA-8(30) SA-8(31) SA-8(8) SA-9 SI-2 SI-2(6) SI-7 | A.8.9 A.8.9 A.8.9 A.8.31 A.8.19 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30 A.6.8 A.8.8 A.8.32 | ||||
| CM0011 | Vulnerability Scanning | Vulnerability scanning systematically identifies known security weaknesses in commercial off-the-shelf (COTS) and open-source software (OSS) components, including vulnerable dependencies and outdated software versions, across spacecraft and ground system environments. Custom-developed code requires separate analysis approaches, such as static and dynamic code analysis, that fall outside the scope of this countermeasure; however, COTS, OSS, and third-party dependencies incorporated into custom-developed software remain within the scope of vulnerability scanning and SCA. Scanning programs should incorporate software composition analysis (SCA) to detect vulnerabilities introduced through third-party libraries and dependency chains, which represent a significant and frequently underestimated attack surface in modern space systems. Scanning tools and processes should conform to recognized interoperability standards that support enumeration of platforms, software flaws, and configuration weaknesses; standardized formatting of checklists and test procedures; and consistent measurement of vulnerability impact. Adherence to these standards enables automation of key vulnerability management workflow steps, facilitates tool interoperability across the mission ecosystem, and produces outputs that are comparable across programs and organizations. Vulnerability scanning shall be performed against the approved as-built or deployed software baseline using methods that do not jeopardize mission operations. Active scanning of live spacecraft, safety-critical ground systems, or operational technology should occur only after the scanning method has been authorized and evaluated for operational impact. Where live scanning presents unacceptable risk, scanning should be performed against representative software images, firmware packages, or test environments that match the approved operational baseline. | CM-10(1) RA-3 RA-5 RA-5(11) RA-5(3) RA-7 SA-11 SA-11(3) SA-15(7) SA-3 SA-4(5) SA-8 SA-8(30) SI-3 SI-3(10) SI-7 | 6.1.2 8.2 9.3.2 A.8.8 A.8.8 6.1.3 8.3 10.2 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 A.8.7 | ||||
| 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. | CM-10 CM-10(1) CM-11 CM-11(3) CM-2 CM-5(6) CM-7(4) CM-7(5) CM-8 CM-8(7) PM-5 RA-5 RA-5(11) SA-10(2) SA-10(4) SA-11 SA-11(3) SA-3 SA-4(5) SA-8 SA-8(13) SA-8(29) SA-8(30) SA-8(7) SA-9 SI-7 | A.8.9 A.8.19 A.8.19 A.5.9 A.8.9 A.5.32 A.8.19 A.8.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.5.2 A.5.4 A.5.8 A.5.14 A.5.22 A.5.23 A.8.21 A.8.29 A.8.30 | ||||
| CM0039 | Least Privilege | The principle of least privilege requires that every process, user account, service, and system component be granted only the permissions and access rights necessary to perform its defined function, with no additional privileges retained beyond what the assigned task requires. Applied to spacecraft and ground systems, this means that processes executing on flight computers, operating system services, ground system applications, and inter-system communication handlers are each confined to the minimum privilege level needed for their specific function, preventing a compromised or malfunctioning component from leveraging excess permissions to affect other system resources or functions. Separate execution domains should be used where supported to reinforce least privilege and contain process failures or compromise. Process isolation does not replace explicit access controls, because authorized communication and shared resources may still cross execution-domain boundaries. Least privilege is a foundational design principle that reduces the consequence of any individual component compromise by limiting what an adversary can accomplish within that component's execution context. | AC-2 AC-3(13) AC-3(15) AC-4(2) AC-6 CA-3(6) CM-7 CM-7(5) CM-7(8) PL-8 PL-8(1) SA-17(7) SA-3 SA-4(9) SA-8 SA-8(13) SA-8(14) SA-8(15) SA-8(19) SA-8(3) SA-8(4) SA-8(9) SC-2(2) SC-32(1) SC-49 SC-50 SC-7(29) | A.5.16 A.5.18 A.8.2 A.5.15 A.8.2 A.8.18 A.8.19 A.8.19 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||
| CM0032 | On-board Intrusion Detection & Prevention | An on-board intrusion detection and prevention system (IDS/IPS) monitors mission-critical spacecraft components and systems, generates and stores audit records, and supports mission-approved responses to detected threats. Depending on the mission architecture, threat, and availability of ground support, responses may be autonomous, ground-directed, or a combination of both. The system should address both known attack patterns and previously unseen anomalous behavior through complementary signature-based and behavior- or anomaly-based detection methods. Machine learning or adaptive technologies may be used when their performance, resource consumption, and failure behavior have been validated for the mission environment. Detection and response coverage should address applicable adversary activities across the attack lifecycle, including initial access, execution, persistence, defense evasion, and exfiltration. The on-board IDS/IPS must be integrated with the spacecraft's traditional fault management system to provide a unified approach to anomaly response, ensuring that cyber-triggered responses are compatible with fault management logic and do not produce unintended effects or fratricide against the spacecraft's own systems; countermeasures that are incompatible with fault management are considered unsafe and must not be executed autonomously. The response hierarchy must prioritize vehicle safety and continued mission operations. Advanced containment or deception responses may be considered when they can be executed without unacceptable mission risk. The system should preserve evidence that supports post-event analysis, threat characterization, and potential attribution by authorized ground support. | AU-14 AU-2 AU-3 AU-3(1) AU-4 AU-4(1) AU-5 AU-5(2) AU-5(5) AU-6(1) AU-6(4) AU-8 AU-9 AU-9(2) AU-9(3) CA-7(6) CM-11(3) CP-10 CP-10(4) IR-4 IR-4(11) IR-4(12) IR-4(14) IR-4(5) IR-5 IR-5(1) PL-8 PL-8(1) RA-10 RA-3(4) SA-8(21) SA-8(22) SA-8(23) SC-16(2) SC-32(1) SC-5 SC-5(3) SC-7(10) SC-7(9) SI-10(6) SI-16 SI-17 SI-3 SI-3(10) SI-3(8) SI-4 SI-4(1) SI-4(10) SI-4(11) SI-4(13) SI-4(16) SI-4(17) SI-4(2) SI-4(23) SI-4(24) SI-4(25) SI-4(4) SI-4(5) SI-4(7) SI-6 SI-7(17) SI-7(8) | A.8.15 A.8.15 A.8.6 A.8.17 A.5.33 A.8.15 A.8.15 A.5.29 A.5.25 A.5.26 A.5.27 A.5.8 A.5.7 A.8.12 A.8.7 A.8.16 A.8.16 A.8.16 A.8.16 | ||||
| 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. | CP-10 CP-10(4) CP-12 CP-2 CP-2(5) IR-3 IR-3(1) IR-3(2) IR-4 IR-4(12) IR-4(3) PE-10 PE10 PL-8 PL-8(1) SA-3 SA-8 SA-8(10) SA-8(12) SA-8(13) SA-8(19) SA-8(21) SA-8(23) SA-8(24) SA-8(26) SA-8(3) SA-8(4) SC-16(2) SC-24 SC-5 SI-11 SI-17 SI-4(7) SI-7(17) SI-7(5) | 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.29 A.5.25 A.5.26 A.5.27 A.7.11 A.5.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 | ||||