Introduction of malicious software such as a virus, worm, Distributed Denial-Of-Service (DDOS) agent, keylogger, rootkit, or Trojan Horse
| SPARTA ID | Requirement | Rationale/Additional Guidance/Notes |
|---|---|---|
| SPR-80 | The [spacecraft] shall execute procedures for ensuring that security-relevant hardware, software, and firmware updates uploaded are exactly as specified by the gold copies. {SV-SP-9,SV-IT-3,SV-SP-3}{CM-3(5),SA-8(8),SA-8(21),SA-8(31),SA-10(3),SA-10(4),SA-10(6),SI-7(10),SI-7(12)} | Ensuring updates match approved gold copies prevents insertion of malicious or altered firmware/software. Compromise during update processes is a high-impact attack vector. Validation protects the trusted computing baseline. This supports recovery and reconstitution integrity. |
| 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-91 | The [spacecraft] shall prevent the installation of Flight Software without verification that the component has been digitally signed.{SV-SP-1,SV-SP-3,SV-SP-6,SV-SP-9}{CM-3,CM-3(8),CM-5,CM-5(3),CM-14,SA-8(8),SA-8(31),SA-10(2),SI-3,SI-7(12),SI-7(15)} | Requiring digital signature verification before installing flight software prevents unauthorized, malicious, or tampered code from being introduced into the spacecraft environment. Software supply chain compromise is a high-impact attack vector that can result in persistent control or loss of mission. Cryptographic validation ensures only approved and trusted binaries are executed. This maintains integrity of the trusted computing baseline. |
| SPR-152 | The [spacecraft] shall use automated mechanisms to maintain and validate baseline configuration to ensure the [spacecraft] is up-to-date, complete, accurate, and readily available.{SV-SP-3}{CM-2(2),CM-3(5),CM-3(7),CM-6,SA-8(8)} | This could be command trigger from Ground or elsewhere. The point here is that the self-test is executed onboard the spacecraft via onboard HW/SW self-test mechanisms and its result is reported to the Ground |
| SPR-179 | The [spacecraft] shall be configured to restrict software execution to only the software/processes that are explicitly authorized and necessary for operational purposes.{SV-SP-3,SV-SP-1}{CM-7(2)} | Allowlisting executable processes prevents unauthorized or malicious code execution. This reduces attack surface and blocks persistence mechanisms. Spacecraft compute resources are constrained, making minimal execution environments safer and more predictable. Only mission-essential binaries should be permitted. |
| SPR-180 | The [spacecraft] shall enforce least functionality principles to prevent the execution of unauthorized software.{SV-SP-3,SV-SP-1}{CM-7(2)} | Limiting enabled services and functions reduces exploitable entry points. Unused capabilities create unnecessary risk without mission benefit. Least functionality supports deterministic system behavior. Reduced complexity improves resilience and monitoring accuracy. |
| SPR-212 | The [spacecraft] shall be capable of shutting off specific subsystems or payloads to isolate malicious activity or protect the platform.{SV-MA-3,SV-AC-6,SV-SP-3,SV-MA-8}{PE-10} | Isolation limits impact of compromised components. Segmentation prevents systemic compromise. Controlled shutdown preserves overall platform health. Modular containment strengthens survivability. |
| SPR-232 | The [organization] shall conduct a criticality analysis to identify mission critical functions and critical components and reduce the vulnerability of such functions and components through secure system design.{SV-SP-3,SV-SP-4,SV-AV-7,SV-MA-4}{CP-2,CP-2(8),PL-7,PM-11,PM-30(1),RA-3(1),RA-9,SA-8(9),SA-8(11),SA-8(25),SA-12,SA-14,SA-15(3),SC-7(29),SR-1} | During SCRM, criticality analysis will aid in determining supply chain risk. For mission critical functions/components, extra scrutiny must be applied to ensure supply chain is secured. |
| SPR-238 | The [organization] shall require subcontractors developing information system components or providing information system services (as appropriate) to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)} | Select the particular subcontractors, software vendors, and manufacturers based on the criticality analysis performed for the Program Protection Plan and the criticality of the components that they supply. Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc. |
| SPR-249 | The [organization] shall employ [Program-defined Operations Security (OPSEC) safeguards] to protect supply chain-related information for the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CP-2(8),PM-30,SA-12(9),SC-38,SR-7} | OPSEC safeguards may include: (1) Limiting the disclosure of information needed to design, develop, test, produce, deliver, and support the element for example, supplier identities, supplier processes, potential suppliers, security requirements, design specifications, testing and evaluation result, and system/component configurations, including the use of direct shipping, blind buys, etc.; (2) Extending supply chain awareness, education, and training for suppliers, intermediate users, and end users; (3) Extending the range of OPSEC tactics, techniques, and procedures to potential suppliers, contracted suppliers, or sub-prime contractor tier of suppliers; and (4) Using centralized support and maintenance services to minimize direct interactions between end users and original suppliers. |
| 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-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-255 | The [organization] shall employ independent third-party analysis and penetration testing of all software (COTS, FOSS, Custom) associated with the system, system components, or system services.{SV-SP-1,SV-SP-3,SV-SP-6}{CA-2,CA-2(1),CA-8(1),CM-10(1),SA-9,SA-11(3),SA-12(11),SI-3,SI-3(10),SR-4(4),SR-6(1)} | Independent assessment reduces bias and uncovers blind spots in internal reviews. External testers provide objective validation of system resilience. Independent penetration testing strengthens confidence in defensive posture. Separation of duties enhances credibility and assurance. |
| SPR-256 | The [organization] shall perform penetration testing/analysis: (1) On potential system elements before accepting the system; (2) As a realistic simulation of the active adversary’s known adversary tactics, techniques, procedures (TTPs), and tools; and (3) Throughout the lifecycle on physical and logical systems, elements, and processes.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CA-8(1),SA-9,SA-11(5),SR-5(2)} | Penetration testing should be performed throughout the lifecycle on physical and logical systems, elements, and processes including: (1) Hardware, software, and firmware development processes; (2) Shipping/handling procedures; (3) Personnel and physical security programs; (4) Configuration management tools/measures to maintain provenance; and (5) Any other programs, processes, or procedures associated with the production/distribution of supply chain elements. |
| SPR-263 | The [organization] shall provide training to its personnel on how to identify and respond to malicious code indicators to include but not limited to indicators of potentially malicious code in flight software, indicators from development machine’s anti-virus/anti-malware software of potential malicious code, and to recognize suspicious communications and anomalous behavior in [organization] information systems.{SV-SP-3,SV-SP-10}{AT-3(4),IR-6,IR-6(2),SI-4(24)} | Personnel must recognize signs of compromised flight or development systems. Early detection prevents propagation into mission assets. Training strengthens defense across lifecycle stages. Awareness reduces supply chain exposure. |
| 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-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-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-277 | In coordination with [organization], the [organization] shall prioritize and remediate flaws identified during security testing/evaluation.{SV-SP-1,SV-SP-3}{CA-2,CA-5,SA-11,SI-3,SI-3(10)} | Timely remediation reduces exploitation window. Coordination ensures mission continuity during patching. Documented prioritization demonstrates due diligence. Structured response enhances accountability. |
| 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-282 | The [organization] shall use all-source intelligence analysis of suppliers and potential suppliers of the information system, system components, or system services to inform engineering, acquisition, and risk management decisions.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-16,PM-30,RA-2,RA-3(1),RA-3(2),RA-7,SA-9,SA-12(8),SR-5(2)} | * The Program should also consider sub suppliers and potential sub suppliers. * All-source intelligence of suppliers that the organization may use includes: (1) Defense Intelligence Agency (DIA) Threat Assessment Center (TAC), the enterprise focal point for supplier threat assessments for the DOD acquisition community risks; (2) Other U.S. Government resources including: (a) Government Industry Data Exchange Program (GIDEP) – Database where government and industry can record issues with suppliers, including counterfeits; and (b) System for Award Management (SAM) – Database of companies that are barred from doing business with the US Government. |
| SPR-283 | The [organization] shall request threat analysis of suppliers of critical components and manage access to and control of threat analysis products containing U.S.person information.{SV-SP-3,SV-SP-4,SV-SP-11}{PM-16,PM-30(1),RA-3(1),SA-9,SA-12,SR-1} | The intent of this requirement is to address supply chain concerns on hardware and software vendors. Not required for trusted suppliers accredited to the Defense Microelectronic Activity (DMEA). If the Program intends to use a supplier not accredited by DMEA, the government customer should be notified as soon as possible. If the Program has internal processes to vet suppliers, it may meet this requirement. All software used and its origins must be included in the SBOM and be subjected to internal and Government vulnerability scans. |
| 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-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-304 | The [organization] shall maintain a list of suppliers and potential suppliers used, and the products that they supply to include software.{SV-SP-3,SV-SP-4,SV-SP-11}{CM-10,PL-8(2),PM-30,SA-8(9),SA-8(11)} | Ideally you have diversification with suppliers |
| SPR-305 | The [organization] shall develop and implement anti-counterfeit policy and procedures designed to detect and prevent counterfeit components from entering the information system, including support tamper resistance and provide a level of protection against the introduction of malicious code or hardware.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{CM-3(8),CM-7(9),PM-30,SA-8(9),SA-8(11),SA-9,SA-10(3),SA-19,SC-51,SR-4(3),SR-4(4),SR-5(2),SR-11} | Counterfeit hardware may embed malicious implants. Formal policies reduce infiltration risk. Supplier verification strengthens trust. Hardware authenticity is foundational to cybersecurity. |
| SPR-307 | The [organization] shall maintain documentation tracing the strategies, tools, and methods implemented to mitigate supply chain risk .{SV-SP-3,SV-SP-4,SV-AV-7}{PM-30,RA-3(1),SA-12(1),SR-5} | Examples include: (1) Transferring a portion of the risk to the developer or supplier through the use of contract language and incentives; (2) Using contract language that requires the implementation of SCRM throughout the system lifecycle in applicable contracts and other acquisition and assistance instruments (grants, cooperative agreements, Cooperative Research and Development Agreements (CRADAs), and other transactions). Within the DOD some examples include: (a) Language outlined in the Defense Acquisition Guidebook section 13.13. Contracting; (b) Language requiring the use of protected mechanisms to deliver elements and data about elements, processes, and delivery mechanisms; (c) Language that articulates that requirements flow down supply chain tiers to sub-prime suppliers. (3) Incentives for suppliers that: (a) Implement required security safeguards and SCRM best practices; (b) Promote transparency into their organizational processes and security practices; (c) Provide additional vetting of the processes and security practices of subordinate suppliers, critical information system components, and services; and (d) Implement contract to reduce SC risk down the contract stack. (4) Gaining insight into supplier security practices; (5) Using contract language and incentives to enable more robust risk management later in the lifecycle; (6) Using a centralized intermediary or “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary; |
| SPR-308 | The [organization] shall protect against supply chain threats to the system, system components, or system services by employing security safeguards as defined by NIST SP 800-161 Rev.1.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{PM-30,RA-3(1),SA-8(9),SA-8(11),SA-12,SI-3,SR-1} | The chosen supply chain safeguards should demonstrably support a comprehensive, defense-in-breadth information security strategy. Safeguards should include protections for both hardware and software. Program should define their critical components (HW & SW) and identify the supply chain protections, approach/posture/process. |
| SPR-317 | The [organization] shall employ [organization]-defined techniques to limit harm from potential adversaries identifying and targeting the Program supply chain.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-3(2),SC-38} | Examples of security safeguards that the organization should consider implementing to limit the harm from potential adversaries targeting the organizational supply chain, are: (1) Using trusted physical delivery mechanisms that do not permit access to the element during delivery (ship via a protected carrier, use cleared/official couriers, or a diplomatic pouch); (2) Using trusted electronic delivery of products and services (require downloading from approved, verification-enhanced sites); (3) Avoiding the purchase of custom configurations, where feasible; (4) Using procurement carve outs (i.e., exclusions to commitments or obligations), where feasible; (5) Using defensive design approaches; (6) Employing system OPSEC principles; (7) Employing a diverse set of suppliers; (8) Employing approved vendor lists with standing reputations in industry; (9) Using a centralized intermediary and “Blind Buy” approaches to acquire element(s) to hide actual usage locations from an untrustworthy supplier or adversary Employing inventory management policies and processes; (10) Using flexible agreements during each acquisition and procurement phase so that it is possible to meet emerging needs or requirements to address supply chain risk without requiring complete revision or re-competition of an acquisition or procurement; (11) Using international, national, commercial or government standards to increase potential supply base; (12) Limiting the disclosure of information that can become publicly available; and (13) Minimizing the time between purchase decisions and required delivery. |
| SPR-330 | The [organization] shall employ the [organization]-defined approaches for the purchase of the system, system components, or system services from suppliers.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-5} | This could include tailored acquisition strategies, contract tools, and procurement methods. |
| 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-332 | The [organization] shall employ [Selection (one or more): independent third-party analysis, Program penetration testing, independent third-party penetration testing] of [Program-defined supply chain elements, processes, and actors] associated with the system, system components, or system services.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-6(1)} | Third-party testing identifies weaknesses across suppliers and processes. Independent review strengthens trust in acquisition channels. Broader testing scope reduces systemic risk. Supply chain validation enhances mission security posture. |
| SPR-336 | The [organization] (and Prime Contractor) shall 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.{SV-SP-3,SV-SP-4,SV-AV-7,SV-SP-11}{SR-6} | |
| 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-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-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-436 | The [organization] shall require the developer of the system, system component, or system services to demonstrate the use of a system development life cycle that includes [state-of-the-practice system/security engineering methods, software development methods, testing/evaluation/validation techniques, and quality control processes].{SV-SP-1,SV-SP-2,SV-SP-3,SV-SP-9}{SA-3,SA-4(3)} | Examples of good security practices would be using defense-in-depth tactics across the board, least-privilege being implemented, two factor authentication everywhere possible, using DevSecOps, implementing and validating adherence to secure coding standards, performing static code analysis, component/origin analysis for open source, fuzzing/dynamic analysis with abuse cases, etc. |
| SPR-483 | The [organization] shall require trusted generation of flight and payload software and configuration baselines in a controlled build environment that enforces signed commits, reproducible builds, cryptographic hashing, and code signing of release artifacts, and shall maintain a configuration-controlled golden image for comparison and rollback.{SV-SP-4,SV-SP-3,SV-SP-9}{SA-10(4)} | Controlled builds prevent unauthorized code injection. Reproducible builds strengthen supply chain transparency. Golden images support rollback and forensic validation. Configuration control strengthens integrity. |
| SPR-485 | The [organization] shall require that IAST results are recorded as assessment evidence and shall block promotion of builds with unresolved high-severity findings to the flight baseline.{SV-SP-1,SV-SP-3}{SA-11(9)} | Preventing promotion of vulnerable builds protects mission integrity. Enforced gating ensures accountability. Security evidence supports auditability. Quality control strengthens assurance. |
| ID | Name | Description | |
|---|---|---|---|
| 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. | |
| IA-0009 | Trusted Relationship | Adversaries obtain first execution by riding connections that the mission already trusts, formal interconnections with partners, vendors, and user communities. Once a third party is compromised, the actor inherits that entity’s approved routes into mission enclaves: VPNs and jump hosts into ground networks, API keys into cloud tenants, automated file drops that feed command or update pipelines, and collaboration spaces where procedures and dictionaries circulate. Because traffic, credentials, and artifacts originate from known counterparts, the initial execution event can appear as a routine payload task, scheduled procedure, or software update promoted through established processes. | |
| IA-0009.01 | Mission Collaborator (academia, international, etc.) | Missions frequently depend on distributed teams, instrument builders at universities, science operations centers, and international partners, connected by data portals, shared repositories, and federated credentials. A compromise of a collaborator yields access to telescience networks, analysis pipelines, instrument commanding tools, and file exchanges that deliver ephemerides, calibration products, procedures, or configuration tables into mission workflows. Partners may operate their own ground elements or payload gateways under delegated authority, creating additional entry points whose authentication and logging differ from the prime’s. Initial access emerges when attacker-modified artifacts or commands traverse these sanctioned paths: a revised calibration script uploaded through a science portal, a configuration table promoted by a cross-org CI job, or a payload task submitted via a collaboration queue and forwarded by the prime as routine work. Variations in process rigor, identity proofing, and toolchains across institutions amplify the attacker’s options while preserving the appearance of legitimate partner activity. | |
| IA-0009.02 | Vendor | Vendors that design, integrate, or support mission systems often hold elevated, persistent routes into operations: remote administration of ground software and modems, access to identity providers and license servers, control of cloud-hosted services, and authority to deliver firmware, bitstreams, or patches. Attackers who compromise a vendor’s enterprise or build environment can assume these roles, issuing commands through approved consoles, queuing updates in provider-operated portals, or invoking maintenance procedures that the mission expects the vendor to perform. Some vendor pathways terminate directly on RF equipment or key-management infrastructure; others ride cross-account cloud roles or managed SaaS backends that handle mission data and scheduling. | |
| IA-0009.03 | User Segment | The “user segment” encompasses end users and their equipment that interact with mission services, SATCOM terminals, customer ground gateways, tasking portals, and downstream processing pipelines for delivered data. Where these environments interconnect with mission cores, a compromised user domain becomes a springboard. Attackers can inject malformed tasking requests that propagate into payload scheduling, craft user-plane messages that traverse gateways into control or management planes, or seed data products that flow back to mission processing systems and automation. In broadband constellations and hosted services, user terminals may share infrastructure with TT&C or provider management networks, creating opportunities to pivot from customer equipment into provider-run nodes that the spacecraft trusts. | |
| EX-0002 | Position, Navigation, and Timing (PNT) Geofencing | Malware or implanted procedures execute only when the spacecraft’s state meets geometric and temporal criteria. Triggers can be defined in orbital elements, inertial or Earth-fixed coordinates, relative geometry, lighting conditions, or time references. The code monitors on-board navigation solutions, ephemerides, or propagated TLEs and arms itself when thresholds are met (e.g., “only fire over region X,” “only activate during LEOP,” or “only run within N seconds of a scheduled downlink.”) Geofencing reduces exposure and aids deniability: triggers are rare, aligned with mission cadence, and hard to reproduce on the ground. More elaborate variants require conjunctions of conditions (position + attitude + clock epoch) or incorporate drift so the trigger slowly evolves with the orbit. The result is effect-on-demand: execution occurs precisely where and when the actor intends, while remaining dormant elsewhere. | |
| 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. | |
| EX-0010.05 | On-Board Process Injection | Adversaries may inject malicious code into trusted onboard software processes in order to execute arbitrary functionality within the context of legitimate spacecraft software. Targeted processes may include flight software tasks, operating system services, telemetry handlers, middleware, communication daemons, scheduler services, device drivers, or other mission-critical runtime components. Process injection enables malicious code to inherit the permissions, memory access, execution context, and trust relationships associated with the compromised process. This may allow adversaries to manipulate telemetry, alter spacecraft operational behavior, suppress reporting, interfere with fault management, inject unauthorized commands, or evade detection without interrupting nominal spacecraft operations. Unlike standalone malicious binaries or scripts, injected code executes within legitimate onboard software contexts, causing malicious activity to appear operationally valid and making detection and forensic analysis significantly more difficult. | |
| PER-0002 | Backdoor | A backdoor is a covert access path that bypasses normal authentication, authorization, or operational checks so the attacker can reenter the system on demand. Backdoors may be preexisting (undocumented service modes, maintenance accounts, debug features) or introduced by the adversary during development, integration, or on-orbit updates. Triggers range from “magic” opcodes and timetags to specific geometry/time conditions, counters, or data patterns embedded in routine traffic. The access they provide varies from expanded command sets and relaxed rate/size limits to alternate communications profiles and hidden file/parameter interfaces. Well-crafted backdoors blend with nominal behavior, appearing as ordinary operations while quietly accepting instructions that other paths would reject, thereby sustaining the attacker’s foothold across passes, resets, and operator handovers. | |
| PER-0002.02 | Software Backdoor | Software backdoors are code paths intentionally crafted or later inserted to provide privileged functionality on cue. In flight contexts, they appear as hidden command handlers, alternate authentication checks, special user/role constructs, or procedure/script hooks that accept nonpublic inputs. They can be embedded in flight applications, separation kernels or drivers, gateway processors that translate bus/payload traffic, or update/loader utilities that handle tables and images. SDR configurations offer another avenue: non-public waveforms, subcarriers, or framing profiles that, when selected, expose a private command channel. Activation is often conditional, specific timetags, geometry, message sequences, or file names, to keep the feature dormant during routine testing and operations. Once present, the backdoor provides a repeatable way to execute commands or modify state without traversing the standard control surfaces, sustaining the adversary’s access over time. | |
| DE-0007 | Evasion via Rootkit | A rootkit hides malicious activity by interposing on reporting paths after the system has booted. In flight contexts this includes patching flight software APIs, kernel syscalls, message queues, and telemetry publishers so task lists, counters, health channels, and event severities are falsified before downlink. Command handlers can be hooked to suppress evidence of certain opcodes or sources; recorder catalogs and file listings can be rewritten on the fly; and housekeeping can be biased to show nominal temperatures, currents, or voltages while actions proceed. The defining feature is runtime concealment: the observability surfaces operators rely on are altered to present a curated, benign narrative. | |
| DE-0008 | Evasion via Bootkit | A bootkit hides activity by running first and shaping what higher layers will later observe. Positioned in boot ROM handoff or early loaders, it can select or patch images in memory, alter device trees and driver tables, seed forged counters and timestamps, and preconfigure telemetry/crypto modes so subsequent components launch into a reality curated by the attacker. Because integrity and logging mechanisms are initialized afterward, the resulting view of processes, files, and histories reflects the bootkit’s choices, allowing long-term evasion that persists across resets and mode transitions. | |
| IMP-0002 | [DEPRECATED] Disruption | Measures designed to temporarily impair the use or access to a system for a period of time. Threat actors may seek to disrupt communications from the victim spacecraft to the ground controllers or other interested parties. By disrupting communications during critical times, there is the potential impact of data being lost or critical actions not being performed. This could cause the spacecraft's purpose to be put into jeopardy depending on what communications were lost during the disruption. This behavior is different than Denial as this attack can also attempt to modify the data and messages as they are passed as a way to disrupt communications. | |
| IMP-0003 | [DEPRECATED] Denial | Measures designed to temporarily eliminate the use, access, or operation of a system for a period of time, usually without physical damage to the affected system. Threat actors may seek to deny ground controllers and other interested parties access to the victim spacecraft. This would be done exhausting system resource, degrading subsystems, or blocking communications entirely. This behavior is different from Disruption as this seeks to deny communications entirely, rather than stop them for a length of time. | |
| IMP-0004 | [DEPRECATED] Degradation | Measures designed to permanently impair (either partially or totally) the use of a system. Threat actors may target various subsystems or the hosted payload in such a way to rapidly increase it's degradation. This could potentially shorten the lifespan of the victim spacecraft. | |
| IMP-0006 | [DEPRECATED] Theft | Threat actors may attempt to steal the data that is being gathered, processed, and sent from the victim spacecraft. Many spacecraft have a particular purpose associated with them and the data they gather is deemed mission critical. By attempting to steal this data, the mission, or purpose, of the spacecraft could be lost entirely. | |
| ID | Name | Description | NIST Rev5 | D3FEND | ISO 27001 | |
|---|---|---|---|---|---|---|
| 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. | CA-3 CM-4 CP-2 PL-8 PL-8(1) RA-3 SA-11 SA-11(2) SA-11(3) SA-11(6) SA-15(6) SA-15(8) SA-2 SA-3 SA-4(9) SA-8 SA-8(25) SA-8(30) | D3-AI D3-AVE D3-SWI D3-HCI D3-NM D3-LLM D3-ALLM D3-PLLM D3-PLM D3-APLM D3-PPLM D3-SYSM D3-DEM D3-SVCDM D3-SYSDM | A.5.14 A.8.21 A.8.9 7.5.1 7.5.2 7.5.3 A.5.2 A.5.29 A.8.1 A.5.8 6.1.2 8.2 9.3.2 A.8.8 A.5.2 A.5.8 A.8.25 A.8.31 A.8.27 A.8.28 A.8.29 A.8.30 | |
| 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. | AC-17 AC-18 AC-20(5) AC-3(11) AC-3(13) AC-3(15) CA-8 CA-8(1) CM-11 CM-14 CM-2(2) CM-3(2) CM-3(7) CM-3(8) CM-4(1) CM-5(6) CM-7(8) CP-2(8) MA-7 PL-8 PL-8(1) PL-8(2) PM-30 PM-30(1) RA-3(1) RA-3(2) RA-5 RA-5(2) RA-9 SA-10 SA-10(4) 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(3) SA-15(5) SA-15(7) SA-15(8) SA-17 SA-3 SA-3(1) SA-3(2) SA-4(12) SA-4(3) SA-4(5) SA-4(9) SA-8 SA-8(19) SA-8(30) SA-8(31) SA-9 SC-38 SI-2 SI-2(6) SI-7 SR-1 SR-11 SR-2 SR-2(1) SR-3 SR-3(2) SR-4 SR-4(1) SR-4(2) SR-4(3) SR-4(4) SR-5 SR-5(2) SR-6 SR-6(1) SR-7 | D3-AI D3-AVE D3-SWI D3-HCI D3-NNI D3-OAM D3-AM D3-OM D3-DI D3-MFA D3-CH D3-OTP D3-BAN D3-PA D3- FAPA D3- DQSA D3-IBCA D3-PCSV D3-PSMD | A.8.4 A.5.14 A.6.7 A.8.1 A.5.14 A.8.1 A.8.20 A.8.9 A.8.9 A.8.31 A.8.19 A.5.30 A.5.8 4.4 6.2 7.5.1 7.5.2 7.5.3 10.2 A.8.8 A.5.22 A.5.2 A.5.8 A.8.25 A.8.31 A.8.33 A.8.28 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.9 A.8.28 A.8.30 A.8.32 A.8.29 A.8.30 A.8.28 A.5.8 A.8.25 A.8.28 A.8.25 A.8.27 A.6.8 A.8.8 A.8.32 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 A.5.22 A.5.22 | |
| 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. | AC-3(11) CM-2 SA-11 SA-5 SA-8(29) | D3-AI D3-SWI | A.8.4 A.8.9 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 | D3-SU | 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 | 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 | |
| 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 | D3-AI D3-AVE D3-SWI | 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 | |
| CM0013 | Dependency Confusion | Dependency confusion is a software supply chain attack in which an adversary publishes a malicious package to a public repository using the same name as an organization's internal private package, exploiting build tools that may inadvertently resolve the public version over the intended internal one. Mitigating this attack requires a layered set of controls: internal dependencies must be sourced exclusively from private, controlled repositories rather than public package registries; build and continuous integration and continuous delivery (CI/CD) pipeline configurations must explicitly define trusted repository sources and resolution order to prevent inadvertent public package substitution; and dependency integrity must be validated at the point of consumption by verifying that cryptographic checksums match those of the known-good official packages. A secure build environment is a prerequisite for these controls to be effective, as a compromised build environment can undermine dependency controls regardless of repository configuration. Together, these measures ensure that only verified, intended dependencies are incorporated into flight software, ground system software, and supporting toolchains. | CM-10(1) CM-11 CM-2 CM-5(6) RA-5 SA-11 SA-3 SA-8 SA-8(30) SA-8(7) SA-8(9) SA-9 SI-7 | D3-LFP D3-UBA D3-RAPA D3-MAC | A.8.9 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 | |
| CM0015 | Software Source Control | Binary or machine-executable code obtained from sources that provide no warranty and no access to the corresponding source code must not be incorporated into spacecraft or ground systems. This prohibition addresses a fundamental software assurance gap: without source code, missions cannot perform source-based static analysis or independently review and modify implementation details, and may have reduced ability to assess, repair, or extend the software. Code from sources with limited or no warranty and no source code provision may be difficult to independently analyze, repair, or extend and leaves the mission dependent on supplier assurances and remediation capabilities. This countermeasure applies throughout the software supply chain, including components integrated by subcontractors. | 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 | |
| CM0016 | CWE List | A prioritized list of software weakness classes, drawn from a recognized weakness enumeration taxonomy such as the common weakness enumeration (CWE) framework, provides the analytical foundation for targeted, mission-relevant static code analysis. Rather than treating all weakness classes as equally significant, mission teams should derive a system-specific priority ranking based on the spacecraft or ground system's architecture, threat environment, operational constraints, and consequence of exploitation for each weakness class. This prioritized list serves two functions: it directs static analysis tool configuration toward the weakness classes most relevant to the mission, and it provides a defensible, documented basis for triaging and ranking analysis findings so that remediation resources are applied where mission risk is highest. The prioritization rationale should be documented and maintained as a controlled artifact, as it reflects security-relevant design decisions about the system's risk posture. | RA-5 SA-11 SA-11(1) SA-15(7) SI-7 | D3-AI D3-AVE | A.8.8 A.8.29 A.8.30 A.8.28 | |
| 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. | PL-8 PL-8(1) SA-11 SA-11(3) SA-15 SA-3 SA-4(9) SA-8 SA-8(30) SA-8(7) SI-7 | D3-AI D3-AVE D3-SWI D3-DCE D3-EHPV D3-ORA D3-FEV D3-FR D3-ER D3-PE D3-PT D3-PS | A.5.8 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.5.8 A.8.25 | |
| CM0018 | Dynamic Testing | Dynamic analysis subjects executing software and firmware to active testing conditions to identify weaknesses and vulnerabilities that static analysis alone cannot detect, including runtime memory corruption, logic errors, timing vulnerabilities, and interface behaviors that only manifest under operational conditions. Applicable techniques include simulation-based testing, penetration testing, fuzz testing, and adversarial emulation using realistic threat actor tactics, techniques, and procedures (TTPs). Dynamic testing must be applied to all software and firmware categories: mission-developed code, open-source components, commercial off-the-shelf (COTS) software, and third-party developed code. Dynamic testing should be performed on potential system elements before acceptance, include realistic simulation of known adversary TTPs, and tools, and continue throughout the lifecycle on applicable physical and logical systems, elements, and processes. Full-scale hardware integration testbeds, commonly referred to as flat satellite (FLATSAT) environments, provide high-fidelity physical test platforms for dynamic analysis; digital twins implemented via instruction set simulation, also known as emulation, provide a flexible and scalable alternative environment capable of supporting TTP execution across a broad range of test scenarios without requiring physical hardware availability. | CA-8 CA-8(1) CM-4(2) CP-4(5) RA-3 RA-5(11) RA-7 SA-11 SA-11(3) SA-11(5) SA-11(8) SA-11(9) SA-3 SA-8 SA-8(30) SC-2(2) SC-7(29) SI-3 SI-3(10) SI-7 SR-6(1) | D3-DA D3-FBA D3-PSA D3-PLA D3-PA D3-SEA D3-MBT | 6.1.2 8.2 9.3.2 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 | |
| CM0019 | Static Analysis | Static source code analysis examines software without executing it, identifying security-relevant weaknesses in the codebase before they can be exploited at runtime. Static analysis must be performed across all available source code. The mission’s weakness prioritization (i.e., CM0016) process should guide tool configuration and finding triage without unnecessarily excluding other weakness classes supported by the tools. The static analysis program must employ no fewer than two distinct tools with complementary language and weakness-detection capabilities. The tools should be applied at defined points throughout the development and maintenance lifecycle to provide overlapping and complementary analysis coverage and reduce the likelihood that exploitable weaknesses persist into integration or deployment. Tool selection should account for language compatibility, weakness class coverage, and the ability to produce findings in formats that support triage and remediation tracking. Static analysis should be integrated into the software build pipeline as an automated, recurring activity rather than conducted as a periodic manual exercise, ensuring that new code contributions are analyzed continuously throughout development. | CM-4(2) RA-3 RA-5 RA-7 SA-11 SA-11(1) SA-11(3) SA-11(4) SA-15(7) SA-3 SA-8 SA-8(30) SI-7 | D3-PM D3-FBA D3-FEMC D3-FV D3-PFV D3-SFV D3-OSM | 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.28 | |
| CM0021 | Software Digital Signature | Each software or firmware image subject to installation or update control shall be verified using an approved digital signature and an approved trust anchor before installation or activation. The trust anchor may be represented by a certificate or by a directly provisioned verification key, depending on the approved trust architecture. Successful verification establishes that the image was signed by an authorized signing identity and has not been modified since signing; it does not establish that the signed code is non-malicious, vulnerability-free, or operationally safe. Signature verification confirms the integrity and approved origin of the software but does not, by itself, prevent installation of an older validly signed version; update authorization and rollback protections must be enforced separately. The verification mechanism must be implemented such that it cannot be bypassed through operational commands, configuration changes, or software updates, and must reject any component whose signature is absent or invalid, or whose signing certificate or trust anchor is not recognized and approved by the mission. Digital signature enforcement complements but is distinct from the boot-time chain of trust established through secure boot; it applies to software installation and update events throughout the operational lifecycle, not only at system startup. | 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 | Configuration management (CM) for space systems requires automated mechanisms to establish, maintain, validate, and report on the approved baseline configuration of spacecraft and supporting ground systems, ensuring the baseline remains current, complete, and accurate throughout the mission lifecycle. Automated mechanisms should support configuration management by improving the accuracy, currency, and validation of configuration records. Automation does not replace formal change control, engineering review, approval, or other configuration management activities that require human judgment. The approved baseline must be readily accessible to authorized personnel for operational decision-making, anomaly investigation, and change impact assessment. Deviations between the documented baseline and the actual system configuration represent both security and operational risk because undocumented changes may introduce vulnerabilities, mask adversary activity, or produce unpredictable system behavior. Automated validation should identify and report configuration drift at mission-defined intervals or following relevant change events, based on system observability and mission risk. | 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 | The spacecraft operating system (OS) must be subjected to software assurance scrutiny commensurate with its mission criticality and security role. Prior assurance and flight-history evidence may be reused only after its applicability to the selected OS version, configuration, target hardware, operational use, and current mission security requirements has been evaluated. The OS must be analyzed for its attack surface, and all features, services, libraries, and interfaces not required for the mission's defined operational functions must be stripped, disabled, or removed before the OS is integrated into the flight software stack. This hardening requirement is particularly significant for some real-time operating systems (RTOS), which commonly include networking stacks, file systems, shell interfaces, diagnostic services, and other general-purpose capabilities that are unnecessary for spacecraft operations but expand the exploitable attack surface available to an adversary. Only an organization-approved OS product, version, build, and configuration baseline may be used in the delivered spacecraft system. The approved baseline must be enforced through reproducible build controls, configuration management, component inventories, and automated verification where supported. | 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 | |
| CM0069 | Process White Listing | Process whitelisting establishes an approved set of executable images, tasks, applications, or process types that may run on the spacecraft computing platform. Enforcement should occur within a trusted layer capable of controlling process or task creation, which may be implemented in firmware, a secure monitor, a hypervisor, the operating system, or the real-time executive according to the platform architecture. The enforcement mechanism must verify an approved process identity before execution and deny unapproved process creation unless a mission-approved recovery mechanism applies. This countermeasure limits the creation or execution of software identities not present in the approved baseline. It does not prevent an adversary from abusing an approved process, altering its runtime memory, redirecting its control flow, or exploiting permitted scripting or loading functionality unless those behaviors are addressed by complementary integrity and execution controls. | CM-11 CM-7(5) PL-8 PL-8(1) SI-10(5) | D3-MAC D3-EAL D3-EDL | A.8.19 A.8.19 A.5.8 | |
| CM0005 | Ground-based Countermeasures | Ground-based countermeasures protect the terrestrial capabilities that develop, launch, command, monitor, operate, secure, and sustain space missions. These capabilities may be distributed across mission-owned systems, contractor environments, external partners, and commercial service providers. Because ground segment architectures and responsibilities vary, cybersecurity protections should be selected through threat-informed analysis of the mission functions being performed rather than through indiscriminate application of a single control set. The SPARTA Ground Segment Cyber Defenses guidance provides an interactive functional decomposition that maps ground segment function groups to applicable Defense-in-Depth sub-layers and countermeasure targets. The supporting report, VTR-2026-00702 Rev A, Ground Segment Cyber Defenses and Risk-Based Tiering, provides the methodology, definitions, and risk-tier rationale. The accompanying Ground Segment Cyber Defenses Excel Workbook consolidates the function mappings and Baseline and Enhanced countermeasure guidance into a resource that can be tailored to a specific mission architecture. | SPARTA Ground Segment Cyber Defenses guidance | Nearly all D3FEND Techniques apply to Ground | None | |
| 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) | 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 | |