safemode.space
← All techniques
REC-0001.01
ST0001Reconnaissance
sub-technique

Software Design

Parent: REC-0001

Description

Adversaries target knowledge of flight and ground software to identify exploitable seams and to build high-fidelity emulators for rehearsal. Valuable details include RTOS selection and version, process layout, inter-process messaging patterns, memory maps and linker scripts, fault-detection/isolation/recovery logic, mode management and safing behavior, command handlers and table services, bootloaders, patch/update mechanisms, crypto libraries, device drivers, and test harnesses. Artifacts may be source code, binaries with symbols, stripped images with recognizable patterns, configuration tables, and SBOMs that reveal vulnerable dependencies. With these, a threat actor can reverse engineer command parsing, locate debug hooks, craft inputs that bypass FDIR, or time payload and bus interactions to produce cascading effects. Supply-chain access to vendors of COTS components, open-source communities, or integrators can be used to insert weaknesses or to harvest build metadata. Even partial disclosures, such as a unit test name, an assert message, or a legacy API, shrink the search space for exploitation.

Mappings

EU regulation articles

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

    Flight/ground software details (RTOS versions, command handlers, crypto libraries, patch mechanisms) require the confidentiality categorization 80(3) places on operator information assets.

  • eu-space-actArt. 81(6)
    addresses
    high
    direct

    Source trees, binaries, and configuration tables held in operator repositories must be protected from unauthorized access by 81(6)'s identity-and-access-management protocols.

  • nis2Art. 21(2)(e)
    addresses
    high
    direct

    Protection of source trees, binaries-with-symbols, command-handler implementations, bootloaders, and patch/update mechanisms is exactly what secure acquisition, development and maintenance under Art. 21(2)(e) requires, including vulnerability handling for the disclosed dependencies an SBOM exposes.

  • nis2Art. 21(2)(i)
    addresses
    moderate
    direct

    Source code, stripped images with recognizable patterns, configuration tables, and test harnesses are mission-critical assets whose disclosure access-control policies and asset-management practices under Art. 21(2)(i) must restrict.

  • nis2-implAnnex 11.3.1
    addresses
    moderate
    direct

    Build operators, release engineers and code-signing custodians are privileged accounts under Annex 11.3, and the privileged-account policy is the procedural lever that bounds source-code and binary-with-symbol exposure to the smallest set of trusted operators.

  • nis2-implAnnex 12.1.1
    addresses
    high
    derived

    Source code and stripped flight images are mission-critical information assets requiring classification so that storage, replication and sharing inherit the protection appropriate to crown-jewel software.

  • nis2-implAnnex 6.2.1
    addresses
    high
    direct

    Source trees, command-handler implementations, build artefacts and patch mechanisms live inside the secure-development life cycle the implementing regulation requires the entity to establish; the rules and tooling specified there constrain who can read and copy the codebase.

ENISA controls

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

    A documented secure development lifecycle is the discipline through which flight and ground software details (RTOS choice, FDIR logic, debug hooks) are protected from disclosure.

  • ENISA-STL-2025-03-sD.24-i01
    addresses
    moderate

    Information classification and labelling of source artefacts and SBOMs governs the access-gating discipline for the flight-software internals REC-0001.01 reconnoiters. The relationship is governance-level relevance rather than an active countermeasure.

  • ENISA-STL-2025-03-sD.25-i08
    addresses
    moderate

    Software source control restricting source, build metadata, and symbolised binaries is relevant to the artefacts REC-0001.01 enumerates, but Software Source Control is a governance control and does not actively defend against reconnaissance.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, REC-0001.01 (SPARTA v3.2).

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