safemode.space
← All techniques
EX-0009.01
ST0004Execution
sub-technique

Flight Software

Parent: EX-0009

Description

Flight software presents rich attack surface where mission-specific parsing and autonomy live. Vulnerable components include command and telemetry handlers, table loaders, file transfer services, mode management and safing logic, payload control applications, and gateway processes that bridge payload and bus protocols. Typical flaws are unchecked lengths and indices in command fields, arithmetic overflows in rate/size calculations, insufficient validation of table contents, format-string misuse in logging, incomplete state cleanup across rapid mode changes, and race conditions in concurrent message processing. Some FSW suites expose operator-facing APIs or scripting/procedure engines used for automation; malformed invocations can coerce unexpected behaviors or enable arbitrary expressions. Because many subsystems act on “last write wins,” logic errors can yield durable configuration changes without obvious anomalies in protocol syntax. Successful exploitation lets an adversary execute code, alter persistent parameters, or chain effects across partitions that would otherwise be segmented by design.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(a)
    addresses
    high
    derived

    Manufacturer obligation that products be made available without known exploitable vulnerabilities applies directly to flight-software command/telemetry handlers, table loaders and file-transfer services that this technique targets.

  • craAnnex I, Part I, (2)(k)
    addresses
    moderate
    derived

    Exploitation-mitigation mechanisms (memory-safety primitives, partition isolation, defensive coding) reduce the impact of successful FSW exploitation even when the underlying defect remains.

  • craAnnex I, Part II, (2)
    addresses
    high
    derived

    Address-and-remediate-without-delay applies to identified FSW vulnerabilities; the obligation bounds operational dwell time before remediation.

  • craAnnex I, Part II, (3)
    addresses
    high
    derived

    Effective and regular tests and reviews (static analysis, fuzzing of command parsers and table loaders, integration testing on flatsats) are the manufacturer-side discipline that surfaces FSW flaws before flight.

  • craAnnex I, Part II, (5)
    addresses
    high
    direct

    Known-vulnerability exploitation (primary mappings: Part II, (2)+(3)) makes (5) the cascade — discovered exploits must reach the manufacturer through a CVD channel for remediation timing to be meaningful.

  • craAnnex I, Part II, (8)
    addresses
    high
    direct

    Known-vulnerability exploitation (primary mapping: Part II, (2) remediate) cascades to (8) — the patch must reach affected products without delay once available.

  • eu-space-actArt. 76(5)
    addresses
    moderate
    direct

    FSW vulnerability identification (primary mapping: Art. 78(1)) is part of the overall ISMS 76(5) requires; vulnerability registers are an ISMS artifact.

  • eu-space-actArt. 76(6)
    addresses
    moderate
    direct

    FSW testing (primary: Art. 88(1)) is one input to the effectiveness-assessment-policy 76(6) requires — assessing whether testing actually surfaces flaws.

  • eu-space-actArt. 78(1)
    addresses
    high
    direct

    Flight-software defects (unchecked lengths, arithmetic overflows, table-content validation) are the cybersecurity vulnerabilities 78(1)(c) requires the operator to identify continuously; (d) requires risk-treatment plans for FSW vulnerabilities above acceptable risk.

  • eu-space-actArt. 88(1)
    addresses
    high
    direct

    88(1)'s testing programme, with 88(3)'s 3-yearly TLPT, is the operator discipline that surfaces FSW parser, command-handler, and table-loader defects before adversaries find them.

  • eu-space-actArt. 88(3)
    addresses
    high
    direct

    FSW code-flaw testing (primary: Art. 88(1)) cascades to 88(3) — pre-launch TLPT is the canonical case for FSW security-test cadence.

  • nis2Art. 21(2)(e)
    addresses
    moderate
    inferred

    EX-0009.01 exploits flight-software implementation flaws to execute code or alter persistent parameters; NIS2 21(2)(e) security in development and maintenance including vulnerability handling governs this defect class.

  • nis2-implAnnex 6.10.1
    addresses
    high
    derived

    Vulnerability-handling-and-disclosure obligations require the entity to obtain information about flight-software defects and act on them through coordinated remediation, which bounds the exploit window for code-flaw-class attacks against on-board parsers and autonomy logic.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Flight-software command/telemetry handlers, table loaders and file-transfer services live inside the secure-development life cycle the implementing regulation requires the entity to govern with explicit rules; defensive coding, review and integrity practices reduce the population of exploitable defects in those parsers.

  • nis2-implAnnex 6.5.1
    addresses
    high
    derived

    Security-testing policy and procedures (static analysis, fuzzing of command parsers and table loaders, integration testing on flatsats) are the procedural mechanism that surfaces flight-software flaws before flight.

  • nis2-implAnnex 6.5.2
    addresses
    high
    derived

    Flight-software command/telemetry handlers, table loaders and file-transfer services are exactly the test-scope items Annex 6.5.2 requires the entity to define under risk assessment, including fuzzing of parsers and integration testing on flatsats.

  • nis2-implAnnex 6.5.3
    addresses
    moderate
    derived

    Annex 6.5.3 review-cadence obligation ensures FSW security testing policy is kept current as flight-software code base, dependencies and threat model evolve.

  • nis2-implAnnex 6.6.1
    addresses
    moderate
    derived

    Security-patch management procedures govern the deployment of fixes to flight software once defects are identified, determining the operational dwell time before remediation.

ENISA controls

  • ENISA-STL-2025-03-sD.21-i02
    addresses
    high

    Acceptable coding standards including safe memory access/allocation are the discipline that prevents flight-software defects (unchecked indices, format-string misuse, race conditions) at source.

  • ENISA-STL-2025-03-sD.21-i03
    addresses
    high

    A documented secure development lifecycle is the engineering discipline against the unchecked-length, overflow, race, and state-cleanup defects EX-0009.01 exploits in flight software.

  • ENISA-STL-2025-03-sD.33-i03
    mitigates
    moderate

    Dynamic code analysis including fuzzing exposes FSW table-loader, parser, and gateway defects that static tools miss.

  • ENISA-STL-2025-03-sD.33-i04
    mitigates
    high

    Static code analysis with two tools and a CWE-prioritised list catches the canonical FSW defect classes (overflow, format string, missing length check) before flight.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EX-0009.01 (SPARTA v3.2).

Built 2026-07-25 from 216 techniques, 334 regulation articles, 125 ENISA controls, 2,610 framework controls, and 90 countermeasures.