All techniques
REC-0006
ST0001Reconnaissance

Gather FSW Development Information

Description

Adversaries collect a cradle-to-operations view of how flight software is built, tested, signed, and released. Useful artifacts include architecture docs, source trees and SBOMs, compiler/linker toolchains and flags, RTOS and middleware versions, build scripts, CI/CD pipelines, code-signing workflows, defect trackers, and release notes that describe “as-built” vs. “as-flown” deltas. They also seek integration environments, emulators/SIL, flatsats/iron birds, hardware-in-the-loop rigs, and the autonomy/FDIR logic that governs mode transitions and patch acceptance. With this knowledge, a threat actor can identify weak crypto or provenance controls on update paths, predict error-handling behavior, and craft inputs that slip past unit/integration tests. Even small disclosures (e.g., a linker script, an assert string, or a sanitized crash dump) shrink the search space for exploitation.

Mappings

EU regulation articles

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

    Source trees, SBOMs, CI/CD configs, and code-signing workflows are operator-held information artifacts within 80(3)'s confidentiality categorization scope.

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

    FSW development environments are operated by the operator's primes, integrators, and tool vendors — 92(1)'s supply-chain security obligation governs what these supplier contracts must include for protecting the dev pipeline.

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

    Cradle-to-operations protection of the FSW pipeline (architecture, source, build/sign/release, integration environments, autonomy rules) is exactly the network-and-information-systems acquisition/development/maintenance obligation in Art. 21(2)(e), including vulnerability handling on disclosed weaknesses.

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

    Repositories, CI/CD orchestrators, code-signing services/HSMs, defect trackers, and SIL/HIL rigs are the precise asset class Art. 21(2)(i)'s access-control + asset-management obligation governs.

  • nis2-implAnnex 11.3.1
    addresses
    high
    derived

    Build pipelines, code-signing services and release-train operators are privileged-account environments whose access policies bound the population that can pull or copy FSW artefacts.

  • nis2-implAnnex 12.1.1
    addresses
    high
    derived

    Source repositories, build artefacts and release manifests are classified information assets; the classification level is the input to the storage, transport and dissemination controls that constrain FSW-development reconnaissance.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    FSW development information lives entirely inside the secure-development life cycle the implementing regulation requires the entity to govern with explicit rules — that lifecycle is the protection envelope for every artefact this technique targets.

ENISA controls

  • A documented secure development lifecycle is the operator-side discipline that protects the FSW dev environment, CI/CD, and toolchains from intelligence collection.

  • Separation of dev/test/production environments limits adversary lateral movement from a compromised dev account into FSW build artefacts.

  • Restricting source, dev-tool, and library access is relevant to the FSW-development artefacts REC-0006 reconnoiters, but Software Source Control is a governance control and does not actively defend against reconnaissance.

  • Outsourced development controls direct, monitor, and review contractor access to the FSW dev environment that REC-0006 targets.

Cross-reference controls

SPARTA countermeasures

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

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