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

Software Recon

Parent: REC-0008

Description

Threat actors enumerate the software factory: where source lives, how dependencies are pulled, how artifacts are built, signed, stored, and promoted to flight. They inventory repos and access models, CI/CD orchestrators, build containers and base images, package registries, signing services/HSMs, update channels, and the policies that gate promotion (tests, reviews, attestations). With this, an adversary can plan dependency confusion or typosquatting attacks, modify build scripts, poison cached artifacts, or swap binaries at distribution edges (mirrors, CDN, ground station staging).

Mappings

EU regulation articles

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

    Software-factory reconnaissance enumerates source location, dependencies and signing pipelines; manufacturers under Annex I, Part II, (1) must identify and document software components (SBOM), which is the same surface, owned by the manufacturer and used to drive vulnerability handling rather than adversary planning.

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

    Software-supply-chain reconnaissance (primary mappings: Part II, (1) + Art. 13(5)) places CVD policy under (5) as the procedural intake for software-component vulnerability reports.

  • craArt. 13(5)
    addresses
    moderate
    derived

    Manufacturer due-diligence on software-component integration governs how vendor relationships, dependency manifests and provenance are vetted — the same pipeline software-factory reconnaissance attempts to enumerate.

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

    Software-supply-chain reconnaissance (build pipelines, signing services, package registries) is exactly what 92(1)'s contractual information-security obligations address through supplier governance.

  • eu-space-actArt. 92(2)
    addresses
    moderate
    inferred

    Art. 92(2)'s supply-chain risk-reduction strategy is domain-relevant to software-factory reconnaissance, but names no mechanism interdicting the information-gathering.

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

    Dependency confusion, typosquatting, and CI artefact poisoning ride supplier and service-provider relationships (registries, CDNs, COTS vendors); supply-chain security under Art. 21(2)(d) is the obligation that constrains the trust framework around them.

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

    Software-factory hardening (repositories, build containers, package registries, signing services/HSMs, promotion gates) is the network-and-information-systems acquisition/development/maintenance posture Art. 21(2)(e) explicitly governs, including handling of disclosed weaknesses in those mechanisms.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers the software-supplier relationship that exposes module names, API surfaces, and version metadata via reconnaissance. Art. 21(3) procedurally extends to assessment of that supplier's vulnerability-handling and disclosure procedures, since the recon surface mirrors what the supplier publishes about itself.

  • nis2-implAnnex 12.4.1
    addresses
    moderate
    derived

    Software-asset inventories carry the version, dependency and provenance data the recon enumerates; their classification controls determine whether the data is exfiltrable through normal access paths.

  • nis2-implAnnex 5.1.1
    addresses
    moderate
    derived

    Software supply chains traverse the entity's supplier network; the supply-chain security policy governs the disclosure surface (vendor lists, dependency manifests, repository URLs) that recon harvests.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Software-factory reconnaissance enumerates the very environment the secure-development rules govern: source location, dependency pulls, build/sign/store/promote flows.

ENISA controls

  • ENISA-STL-2025-03-sD.28-i02
    addresses
    moderate

    Adequate protection of deployed COTS/Open-Source version numbers is precisely the discipline that mitigates cross-referencing against public CVE repositories.

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

    SBOM is the canonical answer to software composition reconnaissance; controlling its disclosure determines REC-0008.02's yield.

  • ENISA-STL-2025-03-sD.28-i04
    addresses
    moderate

    Supply-chain integrity controls regulate hash-sum verification and auditing — the artefacts that limit how readable the dependency graph is to outsiders.

Cross-reference controls

SPARTA countermeasures

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

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