SV-SP-7 - Operating System Attack

Software can be broken down into three levels (operating system and drivers’ layer, data handling service layer, and the application layer). Highest impact on system is likely the embedded code at the BIOS, kernel/firmware level. Attacking the on-board operating systems. Since it manages all the programs and applications on the computer, it has a critical role in the overall security of the system. Since threats may occur deliberately or due to human error, malicious programs or persons, or existing system vulnerability mitigations must be deployed to protect the OS.

ID: SV-SP-7

DiD Layer: SBC

CAPEC #: 186 | 312 | 313 | 532 | 638

NIST Rev5 Control Tag Mapping: CA-2(2) | CA-7 | CA-7(6) | CA-8 | CM-3 | CM-3(2) | CM-4 | CM-4(1) | CM-7 | CM-7(5) | CM-7(8) | CM-11 | CM-11(3) | CM-14 | RA-5 | RA-5(2) | RA-10 | SA-4 | SA-4(5) | SA-8 | SA-8(22) | SA-8(23) | SA-9 | SA-9(7) | SA-10 | SA-10(7) | SA-11 | SA-11(1) | SA-11(2) | SA-11(4) | SA-11(5) | SA-11(6) | SA-11(7) | SA-11(8) | SA-15 | SA-15(5) | SA-15(7) | SA-15(8) | SI-2 | SI-7 | SI-7(17) | SI-10 | SI-10(6) | SR-11

Lowest Threat Tier to
Create Threat Event: III

Notional Risk Rank Score: 19

Informational References

CENTRA Volume I - Cyber Content of Satellites

Low-Level Requirements

SPARTA ID	Requirement	Rationale/Additional Guidance/Notes
SPR-1	The [spacecraft] shall implement a reference monitor mechanism that mediates access between subjects and objects based on a defined set of rules, that is designed and configured to resist tampering or unauthorized alteration, providing a reliable and secure foundation for access control within the information system.{SV-AC-1,SV-AC-4,SV-SP-7}{AC-25}	A reference monitor provides the foundational enforcement point for all access control decisions within the spacecraft. Without a tamper-resistant mediation layer, compromised flight software or malicious code could directly access critical memory, processes, or hardware interfaces. The mechanism must be isolated from modifiable flight software to preserve integrity under adversarial conditions.
SPR-4	The [spacecraft] security implementation shall ensure that information should not be allowed to flow between partitioned applications unless explicitly permitted by the system.{SV-AC-6,SV-MA-3,SV-SP-7}{AC-3(3),AC-3(4),AC-4,AC-4(6),AC-4(21),CA-9,IA-9,SA-8(3),SA-8(18),SA-8(19),SC-2(2),SC-7(29),SC-16,SC-32}	Strict partitioning prevents compromise of one application from cascading into mission-critical subsystems. Many spacecraft attacks exploit flat architectures where subsystems implicitly trust one another. Explicit inter-partition authorization limits lateral movement and privilege escalation. This supports containment and fault isolation under both cyber and fault conditions.
SPR-54	The [spacecraft] shall retain the capability to update/upgrade operating systems while on-orbit.{SV-SP-7}{SA-4(5),SA-8(8),SA-8(31),SA-10(2),SI-3}	The operating system updates should be performed using multi-factor authorization and should only be performed when risk of compromise/exploitation of identified vulnerability outweighs the risk of not performing the update.
SPR-78	The [spacecraft] shall provide independent mission/cyber critical threads such that any one credible event will not corrupt another mission/cyber critical thread.{SV-AC-6,SV-MA-3,SV-SP-7}{SC-3,SC-32,SC-32(1),SI-3,SI-13}	Segregating mission-critical and cyber-critical execution paths prevents a single failure or compromise from corrupting other critical functions. Thread independence supports fault containment and resilience under attack. This ensures availability of essential functions even during partial compromise. Isolation strengthens both safety and cybersecurity.
SPR-81	The [spacecraft] shall perform an integrity check of software, firmware, and information at startup or during security- events.{SV-IT-3,SV-SP-7,SV-SP-3}{CM-3(5),SA-8(9),SA-8(11),SA-8(21),SI-3,SI-7(1),SI-7(10),SI-7(12),SI-7(17)}	Startup integrity checks detect boot-level compromise or unauthorized modification. Event-triggered checks provide additional protection when anomalies occur. This limits adversary persistence across reboots. Continuous validation reinforces trusted boot regimes.
SPR-85	The [spacecraft] trusted boot/RoT shall be a separate compute engine controlling the trusted computing platform cryptographic processor.{SV-IT-3,SV-SP-7}{SA-8(10),SA-8(11),SA-8(12),SI-7(9),SI-7(10)}	Separating the trust engine from general-purpose compute reduces attack surface. Independent control over cryptographic processors prevents compromised flight software from influencing trust validation. This architectural separation preserves chain-of-trust integrity. Isolation enhances resilience against firmware-level threats.
SPR-87	The [spacecraft] shall be configured to provide only essential capabilities.{SV-SP-7,SV-SP-1}{CM-6,CM-7,SA-8(2),SA-8(7),SA-8(13),SA-8(23),SA-8(26),SA-15(5)}	Minimizing enabled functionality reduces attack surface and complexity. Unused services create unnecessary exposure. Essential-only configuration aligns with least functionality principles. This simplifies validation and reduces exploit vectors.
SPR-153	The [spacecraft] operating system, if COTS or FOSS, shall be selected from a [organization]-defined acceptance list.{SV-SP-7}{CM-7(8),CM-7(5)}	Selecting OS from approved list reduces exposure to unvetted vulnerabilities. Controlled selection supports maintainability and patch governance. This mitigates risk from insecure or unsupported platforms. Trusted baselines simplify compliance verification.
SPR-155	The [organization] shall ensure that software planned for reuse meets the fit, form, and function, and security as a component within the new application.{SV-SP-6,SV-SP-7,SV-SP-11}{CM-7(5)}	Reused components may introduce hidden vulnerabilities. Validation ensures compatibility and security alignment with new mission context. Prior approval does not guarantee safe reuse. Rigorous assessment prevents latent risk inheritance.
SPR-236	The [organization] shall implement a verifiable flaw remediation process into the developmental and operational configuration management process.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-5,SA-3,SA-3(1),SA-11,SI-3,SI-3(10)}	The verifiable process should also include a cross reference to mission objectives and impact statements. Understanding the flaws discovered and how they correlate to mission objectives will aid in prioritization.
SPR-250	The [organization] shall verify that the scope of security testing/evaluation provides complete coverage of required security controls (to include abuse cases and penetration testing) at the depth of testing defined in the test documents.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,RA-5(3),SA-11(5),SA-11(7)}	* The frequency of testing should be driven by Program completion events and updates. * Examples of approaches are static analyses, dynamic analyses, binary analysis, or a hybrid of the three approaches
SPR-251	The [organization] shall maintain evidence of the execution of the security assessment plan and the results of the security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11}	Documented evidence provides traceability and accountability for security testing activities. Without retained artifacts, organizations cannot demonstrate due diligence or validate corrective actions. Preserved results support audits, mission reviews, and lessons learned. This strengthens governance and compliance posture.
SPR-252	The [organization] shall create and implement a security assessment plan that includes: (1) The types of analyses, testing, evaluation, and reviews of all software and firmware components; (2) The degree of rigor to be applied to include abuse cases and/or penetration testing; and (3) The types of artifacts produced during those processes.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-2,CA-8,SA-11,SA-11(5)}	The security assessment plan should include evaluation of mission objectives in relation to the security of the mission. Assessments should not only be control based but also functional based to ensure mission is resilient against failures of controls.
SPR-254	The [organization] shall employ dynamic analysis (e.g.using simulation, penetration testing, fuzzing, etc.) to identify software/firmware weaknesses and vulnerabilities in developed and incorporated code (open source, commercial, or third-party developed code).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-8,CM-10(1),RA-3(1),SA-11(5),SA-11(8),SA-11(9),SI-3,SI-7(10)}	Dynamic testing uncovers runtime vulnerabilities not visible through static review. Techniques such as fuzzing and penetration testing simulate realistic adversarial behavior. Runtime validation improves detection of memory corruption, logic flaws, and unsafe state transitions. This reduces latent vulnerabilities prior to deployment.
SPR-265	The [organization] shall report identified systems or system components containing software affected by recently announced cybersecurity-related software flaws (and potential vulnerabilities resulting from those flaws) to [organization] officials with cybersecurity responsibilities.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-11}{IR-6,IR-6(2),SI-2,SI-3,SI-4(12),SR-4(4)}	Rapid reporting of vulnerable components enables proactive remediation. Awareness of newly disclosed flaws prevents exploitation. Coordination ensures mission-wide response. Visibility reduces systemic risk.
SPR-266	The [organization] shall determine the vulnerabilities/weaknesses that require remediation, and coordinate the timeline for that remediation, in accordance with the analysis of the vulnerability scan report, the mission assessment of risk, and mission needs.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CA-5,CM-3,RA-5,RA-7,SI-3,SI-3(10)}	Not all vulnerabilities carry equal mission impact. Risk-informed prioritization ensures critical flaws are addressed first. Coordinated timelines balance mission needs with security posture. Structured remediation strengthens governance.
SPR-269	The [organization] shall ensure that the vulnerability scanning tools (e.g., static analysis and/or component analysis tools) used include the capability to readily update the list of potential information system vulnerabilities to be scanned.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(1),RA-5(3),SI-3}	Threat landscapes evolve rapidly. Regular tool updates ensure detection coverage remains current. Outdated signatures create blind spots. Continuous improvement sustains effectiveness.
SPR-270	The [organization] shall perform vulnerability analysis and risk assessment of all systems and software. The analysis shall include results from hardware‑in‑the‑loop vulnerability scanning of flight software, firmware, and link‑segment interfaces.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(3),SA-15(7),SI-3}	Integrated hardware-in-the-loop testing identifies operationally relevant weaknesses. Combined software, firmware, and interface scanning provides holistic coverage. Risk assessment ensures mitigation aligns with mission priorities. End-to-end analysis strengthens assurance.
SPR-271	The [organization] shall ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact. Scanning shall cover flight software, firmware, and link‑segment interfaces in hardware‑in‑the‑loop environments.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,RA-5(3),SI-3}	Component/Origin scanning looks for open-source libraries/software that may be included into the baseline and looks for known vulnerabilities and open-source license violations.
SPR-272	The [organization] shall perform static binary analysis of all firmware that is utilized on the spacecraft.{SV-SP-7,SV-SP-11}{RA-5,SA-10,SA-11,SI-7(10)}	Many commercial products/parts are utilized within the system and should be analyzed for security weaknesses. Blindly accepting the firmware is free of weakness is unacceptable for high assurance missions. The intent is to not blindly accept firmware from unknown sources and assume it is secure. This is meant to apply to firmware the vendors are not developing internally. In-house developed firmware should be going through the vendor's own testing program and have high assurance it is secure. When utilizing firmware from other sources, "expecting" does not meet this requirement. Each supplier needs to provide evidence to support that claim that their firmware they are getting is genuine and secure.
SPR-273	The [organization] shall perform static source code analysis for all available source code looking for [[organization]-defined Top CWE List] weaknesses using complimentary set of static code analysis tools (i.e.more than one).{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,SA-11(1),SA-15(7)}	Static analysis detects coding weaknesses before execution. Using multiple tools increases detection coverage. Alignment with defined CWE priorities ensures focus on high-risk flaws. Early detection reduces downstream remediation cost.
SPR-274	The [organization] shall analyze vulnerability/weakness scan reports and results from security control assessments.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5,SI-3}	Scan results require expert interpretation to avoid false positives or overlooked risks. Structured analysis ensures meaningful remediation. Correlating findings with mission context refines prioritization. Review strengthens governance.
SPR-275	The [organization] shall have automated means to evaluate adherence to coding standards.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15,SA-15(7),RA-5}	Manual review cannot scale across the code base; you must have a way to scale in order to confirm your coding standards are being met. The intent is for automated means to ensure code adheres to a coding standard.
SPR-276	The [organization] shall perform component analysis (a.k.a.origin analysis) for developed or acquired software.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15(7),RA-5}
SPR-278	The [organization] shall correct flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11}	Flaws that impact the mission objectives should be prioritized.
SPR-279	The [organization] shall perform [Selection (one or more): unit; integration; system; regression] testing/evaluation at [Program-defined depth and coverage].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11}	The depth needs to include functional testing as well as negative/abuse testing.
SPR-291	The [organization] shall use the threat and vulnerability analyses of the as-built system, system components, or system services to inform and direct subsequent testing/evaluation of the as-built system, component, or service.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-3(3),SA-11(2),SA-15(8),SI-3}	Security analysis should guide test design. Threat-informed evaluation improves relevance. Feedback loops strengthen defensive posture. Analytical alignment enhances coverage.
SPR-294	The [organization] shall use threat modeling and vulnerability analysis to inform the current development process using analysis from similar systems, components, or services where applicable.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SA-15(8)}
SPR-295	The [organization] shall perform and document threat and vulnerability analyses of the as-built system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(2),SI-3}	Formal records preserve findings and mitigation strategies. Documentation supports lifecycle traceability. Transparent records enhance oversight. Governance requires evidence.
SPR-296	The [organization] shall conduct an Attack Surface Analysis and reduce attack surfaces to a level that presents a low level of compromise by an attacker.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(6),SA-15(5)}	Reducing exposed interfaces lowers exploitation probability. Quantified surface reduction strengthens resilience. Structured assessment aligns design with mission risk tolerance. Minimization enhances defensive posture.
SPR-331	The [organization] shall test software and firmware updates related to flaw remediation for effectiveness and potential side effects on mission systems in a separate test environment before installation.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3,CM-3(1),CM-3(2),CM-4(1),CM-4(2),CM-10(1),SA-8(31),SA-11(9),SI-2,SI-3,SI-3(10),SI-7(10),SI-7(12),SR-5(2)}	This requirement is focused on software and firmware flaws. If hardware flaw remediation is required, refine the requirement to make this clear.
SPR-337	The [organization] shall ensure that the list of potential system vulnerabilities scanned is updated [prior to a new scan] {SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{RA-5(2),SI-3}	Outdated vulnerability signatures reduce detection capability. Updating scan definitions ensures coverage against emerging threats. Proactive updates prevent blind spots. Continuous refresh strengthens scanning effectiveness.
SPR-391	The [organization] shall release updated versions of the mission information systems incorporating security-relevant software and firmware updates, after suitable regression testing, at a frequency no greater than [Program-defined frequency [90 days]].{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-3(2),CM-4(1)}	On-orbit patching/upgrades may be necessary if vulnerabilities are discovered after launch. The system should have the ability to update software post-launch.
SPR-392	The [organization] shall review proposed changes to the spacecraft, assessing both mission and security impacts.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-10,CM-3(2)}	Changes may introduce unintended security regression. Structured review balances mission needs with risk tolerance. Joint mission-security assessment prevents single-domain blind spots. Integrated evaluation supports safe modernization.
SPR-395	The [organization] shall prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{CM-7(8)}	Closed binaries from unverified sources limit vulnerability inspection. Source availability supports transparency and review. Prohibiting opaque code reduces hidden malicious logic risk. Supply chain integrity depends on verifiability.
SPR-396	The [organization] shall perform configuration management during system, component, or service during [design; development; implementation; operations].{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-10}	Configuration discipline ensures traceability from design through operations. Lifecycle oversight prevents undocumented changes. Structured management supports rollback and audit. Configuration integrity underpins mission assurance.
SPR-397	The [organization] shall create prioritized list of software weakness classes (e.g., Common Weakness Enumerations) to be used during static code analysis for prioritization of static analysis results.{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(1),SA-15(7)}	The prioritized list of CWEs should be created considering operational environment, attack surface, etc. Results from the threat modeling and attack surface analysis should be used as inputs into the CWE prioritization process. There is also a CWSS (https://cwe.mitre.org/cwss/cwss_v1.0.1.html) process that can be used to prioritize CWEs. The prioritized list of CWEs can help with tools selection as well as you select tools based on their ability to detect certain high priority CWEs.
SPR-398	The [organization] shall perform a manual code review of all flight code.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-11(4)}	Flight code governs mission-critical behavior. Manual review detects subtle logic flaws missed by automation. Human expertise enhances safety assurance. Defense-in-depth requires layered validation.
SPR-399	The [organization] shall define acceptable coding languages to be used by the software developer.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15}	Standardized languages reduce complexity and maintenance burden. Approved languages support secure development practices. Language governance strengthens code quality and review consistency. Reduced heterogeneity improves assurance.
SPR-400	The [organization] shall define acceptable secure coding standards for use by the software developers.{SV-SP-1,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SA-15}	Secure coding standards mitigate common vulnerability patterns. Structured guidance reduces CWE-class weaknesses. Enforcing standards promotes predictable behavior. Governance supports sustainable security hygiene.
SPR-401	The [organization] shall correct reported cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2}	* Although this requirement is stated to specifically apply to cybersecurity-related flaws, the Program office may choose to broaden it to all SV flaws. * This requirement is allocated to the Program, as it is presumed, they have the greatest knowledge of the components of the system and when identified flaws apply.
SPR-402	The [organization] shall identify, report, and coordinate correction of cybersecurity-related information system flaws.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-7,SV-SP-9,SV-SP-11}{SI-2}	Centralized reporting ensures timely remediation. Coordinated correction prevents repeated exposure. Documentation strengthens audit traceability. Rapid flaw management reduces exploitation window.
SPR-405	The [organization] shall define/maintain an approved operating system list for use on spacecraft.{SV-SP-7}{CM-7(5)}	The operating system is extremely important to security and availability of the spacecraft, therefore should receive high levels of assurance that it operates as intended and free of critical weaknesses/vulnerabilities.
SPR-419	The [organization] shall periodically review the spacecraft and subsystems to identify and disable unnecessary and/or nonsecure functions, ports, protocols, software, and services.{SV-SP-1,SV-SP-7}{CM-7(1)}	Unused services expand attack surface. Periodic review removes exploitable vectors. Simplification enhances predictability. Surface reduction strengthens defensive posture.
SPR-484	The [organization] shall employ interactive application security testing within spacecraft simulation or hardware-in-the-loop test benches to observe flight software runtime behavior, capture memory use, API calls, and data flows, and shall identify and report vulnerabilities prior to integration.{SV-SP-1,SV-SP-7}{SA-11(9)}	Runtime behavior analysis detects dynamic vulnerabilities. Hardware-in-the-loop testing reveals integration flaws. Early detection reduces costly remediation. Testing strengthens secure development lifecycle.

Related SPARTA Techniques and Sub-Techniques

ID		Name	Description
REC-0008		Gather Supply Chain Information	Threat actors map the end-to-end pathway by which hardware, software, data, and people move from design through AIT, launch, and on-orbit sustainment. They catalog manufacturers and lots, test and calibration houses, logistics routes and waypoints, integrator touchpoints, key certificates and tooling, update and key-loading procedures, and who holds custody at each handoff. They correlate this with procurement artifacts, SBOMs, BOMs, and service contracts to locate where trust is assumed rather than verified. Particular attention falls on exceptions, engineering builds, rework tickets, advance replacements, depot repairs, and urgent field updates, because controls are frequently relaxed there. The result is a prioritized list of choke points (board fabrication, FPGA bitstream signing, image repositories, CI/CD runners, cloud artifact stores, freight forwarders) where compromise yields outsized effect.
	REC-0008.03	Known Vulnerabilities	Adversaries correlate discovered component and software versions with public and private vulnerability sources to assemble a ready exploit catalog. Inputs include CPE/CVE mappings, vendor advisories, CWE-class weaknesses common to selected RTOS/middleware, FPGA IP core errata, cryptographic library issues, and hardware stepping errata that interact with thermal/power regimes. They mine leaked documents, demo code, bug trackers, and community forums; pivot from ground assets to flight by following shared libraries and tooling; and watch for lag between disclosure and patch deployment. Even when a vulnerability seems “ground-only,” it may expose build systems or update paths that ultimately control flight artifacts.
RD-0003		Obtain Cyber Capabilities	Adversaries acquire ready-made tools, code, and knowledge so they can move faster and with lower attribution when operations begin. Capabilities span commodity malware and loaders, bespoke implants for mission control mission control and ground enclaves, privilege-escalation and lateral-movement kits, SDR/codec stacks for TT&C and payload links, fuzzers and protocol harnesses, exploit chains for RTOS/middleware and ground services, and databases of configuration playbooks from prior intrusions. Actors prefer modular kits that can be re-skinned (new C2, new certs) and exercised in flatsat or SIL/HIL labs before use. They also collect operational “how-tos”, procedures, scripts, and operator macros, that convert technical access into mission effects.
	RD-0003.01	Exploit/Payload	Threat actors obtain or adapt exploits (the trigger) and payloads (the action after exploitation) for space, ground, and cloud components. Targets include flight software parsers and table loaders, bootloaders and patch/update handlers, bus gateways, payload controllers, and ground services. Payloads may be binaries, scripts, or command/procedure sequences that alter modes, bypass FDIR, or stage follow-on access; they can also be “data payloads” that exploit weak validation (malformed tables, ephemeris, or calibration products). Acquisition paths mirror the broader market, brokered N-day/0-day packages, open-source exploits re-tooled for mission stacks, and theft from vendors or researchers. Actors tune timing, size/rate limits, and anti-replay nuances so delivery fits pass windows and link budgets, and they rehearse on flatsats to achieve deterministic outcomes.
IA-0001		Compromise Supply Chain	Adversaries achieve first execution before the spacecraft ever flies by inserting malicious code, data, or configuration during manufacturing, integration, or delivery. Targets include software sources and dependencies, build systems and compilers, firmware/bitstreams for MCUs and FPGAs, configuration tables, test vectors, and off-the-shelf avionics. Inserted artifacts are designed to appear legitimate, propagate through normal processes, and activate under routine procedures or specific modes (e.g., safing, maintenance). Common insertion points align with where trust is assumed, vendor updates, mirrors and registries, CI/CD runners, programming stations, and “golden image” repositories. The result is pre-positioned access that blends with baseline behavior, often with delayed or conditional triggers and strong deniability.
	IA-0001.01	Software Dependencies & Development Tools	This technique targets what developers import and the tools that transform source into flight binaries. Methods include dependency confusion and typosquatting, poisoned container/base images, malicious IDE plugins, and compromised compilers, linkers, or build runners that subtly alter output. Because flight and ground stacks frequently reuse open-source RTOS components, crypto libraries, protocol parsers, and build scripts, an upstream change can deterministically reproduce a backdoor downstream. Attackers also seed private mirrors or caches so “trust-on-first-use” locks in tainted packages, or abuse CI secrets and environment variables to pivot further. Effects range from inserting covert handlers into command parsers, to weakening integrity checks in update paths, to embedding telemetry beacons that exfiltrate build metadata helpful for later stages.
	IA-0001.02	Software Supply Chain	Here the manipulation targets software delivered to flight or ground systems: altering source before build, swapping signed binaries at distribution edges, subverting update metadata, or using stolen signing keys to issue malicious patches. Space-specific vectors include mission control applications, schedulers, gateway services, flight tables and configuration packages, and firmware loads during I&T or LEOP. Adversaries craft payloads that pass superficial validation, trigger under particular operating modes, or reintroduce known weaknesses through version rollback. “Data payloads” such as malformed tables, ephemerides, or calibration products can double as exploits when parsers are permissive. The objective is to ride the normal promotion pipeline so the implant arrives pre-trusted and executes as part of routine operations.
EX-0009		Exploit Code Flaws	The adversary executes actions on-board by abusing defects in software that runs on the vehicle, ranging from application logic in flight software to libraries, drivers, and supporting services. Outcomes range from arbitrary code execution and privilege escalation to silent logic manipulation (e.g., bypassing interlocks, suppressing alarms) that appears operationally plausible. The hallmark of this technique is that the attacker co-opts existing code paths, often rarely used ones, to run unintended behavior under nominal interfaces. These attacks may be extremely targeted and tailored to specific coding errors introduced as a result of poor coding practices or they may target known issues in the commercial software components.
	EX-0009.02	Operating System	At the OS layer the attacker targets primitives that schedule work and mediate hardware. Maintenance builds may expose shells or management consoles; misconfigurations around these interfaces can provide paths to command interpreters or privileged syscalls. Exploitation yields kernel-mode execution, arbitrary memory read/write, or control of scheduling and address spaces, letting the actor tamper with FSW processes, intercept command paths, or manipulate storage and bus drivers beneath application checks. The technique leverages generic OS weaknesses adapted to the spacecraft’s particular build, turning low-level control into mission-facing effects that appear to originate from legitimate processes.
	EX-0009.03	Known Vulnerability (COTS/FOSS)	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.
EX-0010		Malicious Code	The adversary achieves on-board effects by introducing executable logic that runs on the vehicle, either native binaries and scripts, injected shellcode, or “data payloads” that an interpreter treats as code (e.g., procedure languages, table-driven automations). Delivery commonly piggybacks on legitimate pathways: software/firmware updates, file transfer services, table loaders, maintenance consoles, or command sequences that write to executable regions. Once staged, activation can be explicit (a specific command, mode change, or file open), environmental (time/geometry triggers), or accidental, where operator actions or routine autonomy invoke the implanted logic. Malicious code can target any layer it can reach: altering flight software behavior, manipulating payload controllers, patching boot or device firmware, or installing hooks in drivers and gateways that bridge bus and payload traffic. Effects range from subtle logic changes (quiet data tampering, command filtering) to overt actions (forced mode transitions, resource starvation), and may include secondary capabilities like covert communications, key material harvesting, or persistence across resets by rewriting images or configuration entries.
	EX-0010.01	Ransomware	Ransomware on a spacecraft encrypts data or critical configuration so that nominal operations can no longer proceed without the attacker’s cooperation. Targets include mass-memory file stores (engineering telemetry, payload data), configuration and command tables, event logs, on-board ephemerides, and even intermediate buffers used by downlink pipelines. Some variants interfere with key services instead of bulk data, e.g., encrypting a command dictionary or table index so valid inputs are rejected, or wrapping the payload data path in an attacker-chosen cipher so downlinked products appear as noise. By denying access to on-board content or control artifacts at scale, attackers convert execution into bargaining power or irreversible mission degradation.
	EX-0010.02	Wiper Malware	Wipers deliberately destroy or irreversibly corrupt data and, in some cases, executable images to impair or end mission operations. Destructive routines may overwrite with patterns or pseudorandom data, repeatedly reformat volumes, trigger wear mechanisms on non-volatile memory, or manipulate low-level translation layers so recovery tools see a blank or inconsistent device. Activation can be immediate or staged, sleeping until a specific time, pass, or maintenance action, and may be paired with anti-recovery steps such as erasing checksums, undo logs, or golden images. Because wipers operate at storage and image layers that underpin many subsystems, collateral effects can cascade: autonomy enters safing without viable recovery paths, downlinks carry only noise, and subsequent updates cannot be authenticated or applied. The defining feature is irreversible loss of data or executables as the primary objective, rather than concealment or monetization.
	EX-0010.03	Rootkit	A rootkit hides the presence and activity of other malicious components by interposing on the mechanisms that report system state. On spacecraft this can occur within flight software processes, at OS kernel level, inside separation kernels/hypervisors, or down in system firmware where drivers and initialization routines run. Techniques include API and syscall hooking, patching message queues and inter-process communication paths, altering task lists and scheduler views, filtering telemetry packets and event logs, and rewriting sensor or health values before they are recorded or downlinked. Rootkits may also hook command handlers and gateways so certain opcodes, timetags, or sources are silently accepted or ignored while external observers see normal acknowledgments. Because many missions rely on deterministic procedures and limited observability, even small alterations to reporting can make malicious actions appear as plausible mode transitions or benign anomalies. Persistence often pairs with the concealment layer, with the rootkit reinjecting companions after resets or rebuilds by monitoring for specific files, tables, or image loads and modifying them on the fly.
	EX-0010.04	Bootkit	A bootkit positions itself in the pre-OS boot chain so that it executes before normal integrity checks and can shape what the system subsequently trusts. After seizing early control, the bootkit can redirect image selection, patch kernels or flight binaries in memory, adjust device trees and driver tables, or install hooks that persist across warm resets. Some variants maintain shadow copies of legitimate images and present them to basic verification routines while steering actual execution to a modified payload; others manipulate fallback logic so recovery modes load attacker-controlled code. Because the boot path initializes memory maps, buses, and authentication material, a bootkit can also influence key/counter setup and gateway configurations, creating conditions favorable to later tactics. The central characteristic is precedence: by running first, the implant defines the reality higher layers observe, ensuring that every subsequent component launches under conditions curated by the attacker.

ID	Name	Description	NIST Rev5	D3FEND	ISO 27001
CM0025	Supplier Review	Conduct a supplier review prior to entering into a contractual agreement with a contractor (or sub-contractor) to acquire systems, system components, or system services.	PL-8 \| PL-8(1) \| PL-8(2) \| PM-30 \| PM-30(1) \| RA-3(1) \| SA-11 \| SA-11(3) \| SA-17 \| SA-2 \| SA-3 \| SA-8 \| SA-9 \| SR-11 \| SR-3(1) \| SR-3(3) \| SR-4 \| SR-4(1) \| SR-4(2) \| SR-4(3) \| SR-4(4) \| SR-5 \| SR-5(1) \| SR-5(2) \| SR-6	D3-OAM \| D3-ODM \|	A.5.8 \| 4.4 \| 6.2 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| 10.2 \| 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.8.25 \| A.8.27 \| A.5.21 \| A.8.30 \| A.5.20 \| A.5.21 \| A.5.23 \| A.8.29 \| A.5.22
CM0026	Original Component Manufacturer	Components/Software that cannot be procured from the original component manufacturer or their authorized franchised distribution network should be approved by the supply chain board or equivalent to prevent and detect counterfeit and fraudulent parts, materials, and software.	AC-20(5) \| PL-8 \| PL-8(1) \| PL-8(2) \| PM-30 \| PM-30(1) \| RA-3(1) \| SA-10(4) \| SA-11 \| SA-3 \| SA-8 \| SA-9 \| SR-1 \| SR-11 \| SR-2 \| SR-2(1) \| SR-3 \| SR-3(1) \| SR-3(3) \| SR-4 \| SR-4(1) \| SR-4(2) \| SR-4(3) \| SR-4(4) \| SR-5 \| SR-5(1) \| SR-5(2)	D3-OAM \| D3-ODM \| D3-AM \| D3-FV \| D3-SFV \|	A.5.8 \| 4.4 \| 6.2 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| 10.2 \| 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 \| 5.2 \| 5.3 \| 7.5.1 \| 7.5.2 \| 7.5.3 \| A.5.1 \| A.5.2 \| A.5.4 \| A.5.19 \| A.5.31 \| A.5.36 \| A.5.37 \| A.5.19 \| A.5.20 \| A.5.21 \| A.8.30 \| A.5.20 \| A.5.21 \| A.5.21 \| A.8.30 \| A.5.20 \| A.5.21 \| A.5.23 \| A.8.29
CM0011	Vulnerability Scanning	Vulnerability scanning is used to identify known software vulnerabilities (excluding custom-developed software - ex: COTS and Open-Source). Utilize scanning tools to identify vulnerabilities in dependencies and outdated software (i.e., software composition analysis). Ensure that vulnerability scanning tools and techniques are employed that facilitate interoperability among tools and automate parts of the vulnerability management process by using standards for: (1) Enumerating platforms, custom software flaws, and improper configurations; (2) Formatting checklists and test procedures; and (3) Measuring vulnerability impact.	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	D3-AI \| D3-NM \| D3-AVE \| D3-NVA \| D3-PM \| D3-FBA \| D3-OSM \| D3-SFA \| D3-PA \| D3-PSA \| D3-PLA \| D3-PCSV \| D3-FA \| D3-DA \| D3-ID \| D3-HD \| D3-UA \|	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
CM0015	Software Source Control	Prohibit the use of binary or machine-executable code from sources with limited or no warranty and without the provision of source code.	CM-11 \| CM-14 \| CM-2 \| CM-4 \| CM-5(6) \| CM-7(8) \| SA-10(2) \| SA-10(4) \| SA-11 \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(19) \| SA-8(29) \| SA-8(30) \| SA-8(31) \| SA-8(7) \| SA-9 \| SI-7	D3-PM \| D3-SBV \| D3-EI \| D3-EAL \| D3- EDL \| D3-DCE \|	A.8.9 \| A.8.9 \| 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
CM0021	Software Digital Signature	Prevent the installation of Flight Software without verification that the component has been digitally signed using a certificate that is recognized and approved by the mission.	AC-14 \| CM-11 \| CM-11(3) \| CM-14 \| CM-5(6) \| IA-2 \| SA-10(1) \| SA-11 \| SA-4(5) \| SA-8(29) \| SA-8(31) \| SA-9 \| SI-7 \| SI-7(1) \| SI-7(12) \| SI-7(15) \| SI-7(6)	D3-CH \| D3-CBAN \| D3-FV \| D3-DLIC \| D3-EAL \| D3-SBV \|	A.8.19 \| A.5.16 \| 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
CM0023	Configuration Management	Use automated mechanisms to maintain and validate baseline configuration to ensure the spacecraft's is up-to-date, complete, accurate, and readily available.	CM-11(3) \| CM-2 \| CM-3(4) \| CM-3(6) \| CM-3(7) \| CM-3(8) \| CM-4 \| CM-5 \| CM-5(6) \| MA-7 \| SA-10 \| SA-10(2) \| SA-10(7) \| SA-11 \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(29) \| SA-8(30) \| SA-8(31) \| SI-7 \| SR-11(2)	D3-ACH \| D3-CI \| D3-SICA \| D3-USICA \|	A.8.9 \| A.8.9 \| A.8.9 \| A.8.9 \| A.8.2 \| A.8.4 \| A.8.9 \| A.8.19 \| A.8.31 \| A.8.3 \| A.5.2 \| A.5.8 \| A.8.25 \| A.8.31 \| A.8.27 \| A.8.28 \| A.8.9 \| A.8.28 \| A.8.30 \| A.8.32 \| A.8.29 \| A.8.30
CM0047	Operating System Security	Ensure spacecraft's operating system is scrutinized/whitelisted and has received adequate software assurance previously. The operating system should be analyzed for its attack surface and non-utilized features should be stripped from the operating system. Many real-time operating systems contain features that are not necessary for spacecraft operations and only increase the attack surface.	CM-11(3) \| CM-7 \| CM-7(5) \| CM-7(8) \| PL-8 \| PL-8(1) \| SA-15(6) \| SA-3 \| SA-4(5) \| SA-4(9) \| SA-8 \| SA-8(19) \| SA-8(30) \| SI-3(8)	D3-AVE \| D3-OSM \| D3-EHB \| D3-SDM \| D3-SFA \| D3-SBV \| D3-PA \| D3-SCA \| D3-FCA \|	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	Utilize on-board intrusion detection/prevention system that monitors the mission critical components or systems and audit/logs actions. The IDS/IPS should have the capability to respond to threats (initial access, execution, persistence, evasion, exfiltration, etc.) and it should address signature-based attacks along with dynamic never-before seen attacks using machine learning/adaptive technologies. The IDS/IPS must integrate with traditional fault management to provide a wholistic approach to faults on-board the spacecraft. Spacecraft should select and execute safe countermeasures against cyber-attacks. These countermeasures are a ready supply of options to triage against the specific types of attack and mission priorities. Minimally, the response should ensure vehicle safety and continued operations. Ideally, the goal is to trap the threat, convince the threat that it is successful, and trace and track the attacker — with or without ground support. This would support successful attribution and evolving countermeasures to mitigate the threat in the future. “Safe countermeasures” are those that are compatible with the system’s fault management system to avoid unintended effects or fratricide on the system.	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)	D3-FA \| D3-DA \| D3-FCR \| D3-FH \| D3-ID \| D3-IRA \| D3-HD \| D3-IAA \| D3-FHRA \| D3-NTA \| D3-PMAD \| D3-RTSD \| D3-ANAA \| D3-CA \| D3-CSPP \| D3-ISVA \| D3-PM \| D3-SDM \| D3-SFA \| D3-SFV \| D3-SICA \| D3-USICA \| D3-FBA \| D3-FEMC \| D3-FV \| D3-OSM \| D3-PFV \| D3-EHB \| D3-IDA \| D3-MBT \| D3-SBV \| D3-PA \| D3-PSMD \| D3-PSA \| D3-SEA \| D3-SSC \| D3-SCA \| D3-FAPA \| D3-IBCA \| D3-PCSV \| D3-FCA \| D3-PLA \| D3-UBA \| D3-RAPA \| D3-SDA \| D3-UDTA \| D3-UGLPA \| D3-ANET \| D3-AZET \| D3-JFAPA \| D3-LAM \| D3-NI \| D3-RRID \| D3-NTF \| D3-ITF \| D3-OTF \| D3-EI \| D3-EAL \| D3-EDL \| D3-HBPI \| D3-IOPR \| D3-KBPI \| D3-MAC \| D3-SCF \|	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
CM0014	Secure boot	Software/Firmware must verify a trust chain that extends through the hardware root of trust, boot loader, boot configuration file, and operating system image, in that order. The trusted boot/RoT computing module should be implemented on radiation tolerant burn-in (non-programmable) equipment.	AC-14 \| PL-8 \| PL-8(1) \| SA-8(10) \| SA-8(12) \| SA-8(13) \| SA-8(3) \| SA-8(30) \| SA-8(4) \| SC-51 \| SI-7 \| SI-7(1) \| SI-7(10) \| SI-7(9)	D3-PH \| D3-BA \| D3-DLIC \| D3-TBI \|	A.5.8

SV-SP-7 - Operating System Attack

Informational References

High-Level Requirements

Low-Level Requirements

Related SPARTA Techniques and Sub-Techniques

Related SPARTA Countermeasures