Cybersecurity as engineering assurance for aerospace and space systems

Spacecraft and aircraft are long-lived, expensive to modify and, in the case of spacecraft, impossible to reach physically after launch. They are commanded over radio links, built from software and hardware supplied by many organisations, and operated through ground systems connected to wider networks.

A security weakness is therefore a mission risk in the same sense as a structural margin or a thermal limit. Public policy has said so explicitly: the United States' Space Policy Directive-5 calls for cybersecurity to be built into space systems from design onward, and NIST has published Cybersecurity Framework guidance for commercial satellite operations and for the satellite ground segment.

When security lives in a separate report, its findings do not appear in the readiness picture until someone copies them across. In AEAIP they are part of the same graph as every other finding.

Security verification uses the same verification logic as everything else, with its own methods: threat modelling and secure-design review early; static and dynamic security testing, software composition analysis and fuzzing during development; penetration testing on representative configurations; and configuration verification, firmware integrity and secure-boot evidence on the flight article.

The full list sits in the verification method taxonomy. Which methods apply depends on the system, its threat model and the programme's security requirements.

A penetration test is evidence about the build, keys and settings it was run against. A software bill of materials describes one build. When the flight software moves from 4.2.0 to 4.2.1, both need to be re-examined.

This is configuration-aware evidence validity applied to security, and it is where security and engineering most often fall out of step: a remediation is made, the build changes, and the security evidence still on file describes the old build. See configuration-aware evidence validity.

1. 01Security requirement: SEC-012 — reject replayed or out-of-sequence telecommands
2. 02Threat: Replay of captured telecommands on the S-band uplink
3. 03Allocated control: Authenticated commands with a monotonic sequence counter
4. 04Configuration: FSW build 4.2.0 · ground command encoder v1.8
5. 05Verification method: Penetration test PT-02 on the flat-sat
6. 06Finding: SEC-F-031 (medium) — counter accepted within a 30 s window after reset
7. 07Remediation: Counter persisted across resets; FSW build 4.2.1
8. 08Retest: PT-02 retest on build 4.2.1 · pending
9. 09Authorized security review: Not started

At TRR this finding is a condition, not a blocker: commanding during the test is limited to the procedure. At SAR it becomes a blocker until the retest passes and an authorised reviewer closes it.

AEAIP is designed to map security evidence to the frameworks a programme applies, without claiming compliance with any of them. Commonly referenced guidance includes:

• NIST Cybersecurity Framework 2.0, and its space profiles in NIST IR 8270 (commercial satellite operations) and NIST IR 8401 (satellite ground segment).
• NIST SP 800-218 (Secure Software Development Framework) and NIST SP 800-160 Vol. 1 Rev. 1 (systems security engineering).
• Software bill of materials guidance from NTIA and CISA.
• For aircraft, the airworthiness security process defined in RTCA DO-326A / EUROCAE ED-202A.
• The customer's and nation's own security requirements, which take precedence.