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

Development Environment

Parent: REC-0006

Description

Threat actors enumerate the exact environment used to produce flight builds: IDEs and plugins, cross-compilers and SDKs, container images/VMs, environment variables, path conventions, build systems, static libraries, and private package registries. They correlate repository layouts (mono- vs multi-repo), branch and review policies, protected branches/tags, and CI orchestrators to find where policy gaps allow unreviewed code or tool updates. Secrets embedded in configs (tokens, service accounts), permissive compiler/linker flags, or disabled hardening options are especially valuable. Knowledge of debug/diagnostic builds, symbol servers, and crash-dump handling lets an adversary reconstruct higher-fidelity testbeds or derive function boundaries in stripped images.

Mappings

EU regulation articles

  • eu-space-actArt. 81(1)
    addresses
    moderate
    direct

    Identity-and-access-management protocols under 81(1) govern the dev-environment credentials, repository access, and CI/CD orchestrator permissions.

  • eu-space-actArt. 81(4)
    addresses
    moderate
    direct

    Dev-environment recon (primary: Art. 81(1)) cascades to 81(4) — repository and CI/CD credential audit limits attacker reconnaissance value.

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

    Development environment compromise sits squarely in supply-chain risk; 92(1)'s information-security contractual obligation extends to dev environment access governance with suppliers.

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

    Hardening of cross-compilers/SDKs, container images, build systems, branch protections, and CI orchestrators is exactly the secure development and maintenance posture Art. 21(2)(e) requires the entity to maintain.

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

    Repositories, protected branches/tags, CI orchestrators, package registries, and signing tokens are access-controlled assets; Art. 21(2)(i)'s access-control + asset-management discipline governs which roles can read or alter them.

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

    addresses; Art. 21(2)(j) is domain-relevant because developer-site IdPs, source-control, and CI/CD accounts should use MFA, but MFA does not interdict passive enumeration of the build environment, repo layouts, or secrets-in-configs; the operative control is the secure-development assurance of Art. 21(2)(e).

  • nis2-implAnnex 11.3.1
    addresses
    moderate
    derived

    Privileged accounts on build servers, signing nodes and dev-cluster admin consoles are within the privileged-account population whose recon exposure must be constrained.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Secure-development rules govern the entity's development environment design, which is the very target the adversary enumerates.

  • nis2-implAnnex 6.3.1
    addresses
    moderate
    direct

    Configuration management of the development environment (IDEs, cross-compilers, container images, build agents) is the implementing-regulation control that defines and protects the development substrate the technique enumerates.

ENISA controls

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

    A secure development lifecycle is the umbrella discipline whose engineering principles guard the development environment.

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

    Separation of development environments from test and production directly mitigates this technique's harvest of dev-environment intelligence.

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

    Software source control governs the provenance and handling of source code, development tools, and libraries in the development environment that REC-0006.01 reconnoiters. The relationship is governance-level relevance rather than active mitigation of reconnaissance.

Cross-reference controls

SPARTA countermeasures

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

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