Include the following requirements, descriptions, and criteria, explicitly or by reference, using [Selection (one or more): standardized contract language;
[Assignment: organization-defined contract language]
] in the acquisition contract for the system, system component, or system service:
a. Security and privacy functional requirements;
b. Strength of mechanism requirements;
c. Security and privacy assurance requirements;
d. Controls needed to satisfy the security and privacy requirements.
e. Security and privacy documentation requirements;
f. Requirements for protecting security and privacy documentation;
g. Description of the system development environment and environment in which the system is intended to operate;
h. Allocation of responsibility or identification of parties responsible for information security, privacy, and supply chain risk management; and
i. Acceptance criteria.
Acquisition requirements work best when they pair what functions are needed with how assurance will be shown. Specify security functions (e.g., command authentication, partitioning, telemetry integrity, secure boot) alongside deliverable evidence (design descriptions, verification plans, interface specs, performance bounds). Favor artifacts aligned to mission realities: image/bitstream provenance, key-handling procedures, mode-dependent behavior, and twin/RF-emulation results that show robustness under degraded conditions.
On-orbit software updates/upgrades/patches/direct memory writes. If TT&C is compromised or MOC or even the developer's environment, the risk exists to do a variation of a supply chain attack where after it is in orbit you inject malicious code
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.
Testing only focuses on functional requirements and rarely considers end to end or abuse cases
Sample Requirements
SPARTA ID
Requirement
Rationale/Additional Guidance/Notes
SPR-431
The [organization] shall include the following requirements, descriptions, and criteria, explicitly or by reference, in the acquisition of a system, system component, or system service: a.Functional security requirements; b.Strength of mechanism requirements; c.Security assurance requirements; d.Controls needed to satisfy the security requirements.e.Security documentation requirements; f.Requirements for protecting security documentation; g.Description of the system development environment and environment in which the system is intended to operate; h.Allocation of responsibility or identification of parties responsible control implementation and continuous monitoring/enforcement throughout the system life cycle; and i.Acceptance criteria.{SV-SP-4,SV-SP-6}{SA-4}
Security must be embedded in procurement documentation. Explicit criteria prevent ambiguity. Defined acceptance standards ensure compliance. Acquisition governance strengthens supply chain assurance.