safemode.space
← All techniques
EXF-0008
ST0008Exfiltration

Compromised Developer Site

Description

By breaching development or integration environments (at the mission owner, contractor, or partner), the adversary gains access to source code, test vectors, telemetry captures, build artifacts, documentation, and configuration data, material that is often more complete than flight archives. Beyond theft of intellectual property, the attacker can embed telemetry taps, extended logging, or data “export” features into test harnesses, simulators, or flight builds so that, once fielded, the system produces extra observables or forwards content to non-mission endpoints. This activity typically occurs pre-launch during software production and ATLO, positioning exfiltration mechanisms to activate later in flight.

Mappings

EU regulation articles

  • craAnnex I, Part I, (2)(f)
    addresses
    moderate
    direct

    Embedding telemetry taps, extended logging, or data-export features into builds is unauthorized modification of programs that manifests post-deployment — the integrity-of-programs property (2)(f) requires the manufacturer to protect end-to-end through the build pipeline.

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

    Effective and regular security tests must extend to test harnesses, simulators, and flight builds — the development-pipeline artifacts EXF-0008 attacks; (Part II, 3)'s testing obligation applies to the supply chain that produces the product.

  • craArt. 13(2)
    addresses
    high
    direct

    Compromise during planning/design/development/production is exactly the lifecycle phase (13)(2)'s risk-assessment obligation requires the manufacturer to consider — including the development environment as part of the cybersecurity risk surface.

  • eu-space-actArt. 76(4)
    addresses
    high
    direct

    76(4)(a) explicitly covers the conception and design phases including preparatory activities to manufacturing — the lifecycle stage EXF-0008 attacks via developer-environment compromise.

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

    Compromised-developer-site exfiltration (primary: Art. 76(4) lifecycle) requires ISMS coverage of the development phase per 76(5)'s integrate-all-sources-of-risk obligation.

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

    Dev-environment testing (primary: Art. 88(1)) effectiveness needs the assessment policy 76(6) requires — ensuring dev-pipeline integrity checks remain effective.

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

    88(1)'s testing programme should extend to test harnesses, simulators, and flight builds — verifying that compromised dev artifacts cannot reach production silently.

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

    Dev-environment compromise testing (primary: Art. 88(1)) cascades to 88(3) — TLPT scope can include dev-pipeline integrity validation against the 3-yearly cadence.

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

    Development and integration environments at contractors and partners are supplier touchpoints; 92(1)'s contractual information-security obligation extends to supplier dev-pipeline governance.

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

    Compromise of contractor or partner development/integration environments (where source, test vectors, and ATLO artefacts live) is a textbook software supply-chain failure; Art. 21(2)(d)'s supplier-relationship security obligation governs the trust framework over those environments.

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

    Embedding extended logging, telemetry taps, or 'export' features in test harnesses, simulators, or flight builds is exactly the integrity attack on the development pipeline Art. 21(2)(e)'s acquisition/development/maintenance and vulnerability-handling discipline is intended to detect and prevent.

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

    Multi-factor authentication on developer-site identity providers, source-control accounts, and CI/CD orchestrators under Art. 21(2)(j) reduces the credential-driven entry path to the development environment the technique exploits.

  • nis2Art. 21(3)
    addresses
    high
    derived

    Primary mapping to Art. 21(2)(d) covers compromised developer-site exposure via contractor and integrator relationships. Art. 21(3) procedurally extends to assessment of those suppliers' secure-development environments and vulnerability-management practices, since compromised dev sites are an attribute of supplier security quality.

  • nis2-implAnnex 11.3.1
    addresses
    moderate
    derived

    Build operators, simulator administrators and ATLO test controllers are privileged-account holders; the privileged-account policy bounds the population that can ever extract development artefacts at scale.

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Development artefacts (source, test vectors, configuration data) are mission-critical information assets whose classification level governs storage and access controls.

  • nis2-implAnnex 3.3.2
    addresses
    moderate
    derived

    Contractors and integrators must be able to report suspicious events affecting their development environments back to the mission owner; Annex 3.3.2 requires that reporting mechanism to be communicated to suppliers, which is the upstream feeder for early dev-site compromise discovery.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Contractor and integrator development environments are direct suppliers under the supply-chain policy; the policy frames the security expectations imposed on those environments where pre-launch exfiltration occurs.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Developer-site suppliers (contractors, integrators, partner dev environments) require Annex 5.1.6 ongoing monitoring because dev-site compromise typically rides through gradually deteriorating supplier-side security posture.

  • nis2-implAnnex 5.1.7
    addresses
    moderate
    derived

    Annex 5.1.7 reporting and follow-up convert dev-site supplier monitoring signals into pre-launch verification actions and supplier remediation.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Source code, test vectors, telemetry captures, build artefacts and configuration data live inside the secure-development life cycle; the rules for that lifecycle govern the integrity, access and protection controls that resist exfiltration of the development corpus.

ENISA controls

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

    Secure development lifecycle principles cover the engineering controls that detect embedded telemetry taps and extended logging in test harnesses and flight builds.

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

    Separation of dev/test/production environments is the structural defense against compromised developer-site implants reaching flight builds and ATLO.

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

    Software source control governs restrictions on access to source code, development tools, and software libraries, relevant to the developer-site artefacts EXF-0008 mines.

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

    Outsourced development controls direct, monitor, and review contractor activities and dev environments — including the partner sites EXF-0008 may target.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, EXF-0008 (SPARTA v3.2).

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