safemode.space
← All techniques
DE-0012
ST0006Defense Evasion

Component Collusion

Description

This technique involves two or more compromised components operating in coordination to conceal malicious activity. Threat actors compromise multiple software modules during the supply chain process and design them to behave cooperatively. Each component independently performs only a limited, seemingly benign function, such that when analyzed in isolation, no single module appears malicious. An example of implementation involves one component acting as a trigger agent, waiting for specific mission or system conditions (e.g., GPS fix, telemetry state) and writing a signal to a shared resource (e.g., file, bus). A separate action agent monitors this resource and only executes the malicious behavior (such as data exfiltration or command injection) upon receiving the trigger. This division of responsibilities significantly undermines traditional detection techniques, such as log analysis, static code review, or heuristic-based behavior monitoring.

Mappings

EU regulation articles

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

    Coordinated cooperative behavior between compromised components manipulates shared resources (files, buses) — modification of stored/transmitted data within (2)(f)'s scope.

  • craAnnex I, Part II, (1)
    addresses
    moderate
    inferred

    mitigates DOWNGRADE: SBOM/component documentation under Part II (1) is domain-relevant for tracing which modules exist, but does not interdict coordinated multi-component collusion since each component is benign in isolation; the operative defenses are runtime behavioral monitoring and integrity verification.

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

    Component-collusion via supply-chain compromise (primary mapping: Annex I, Part II, (1) component identification + Art. 13(5) due diligence) requires a coordinated-vulnerability-disclosure policy as the inbound channel for receiving reports about suspect third-party modules; the CVD policy obligation under (5) closes the loop on the (1)/(13)(5) primary cluster.

  • craArt. 13(5)
    addresses
    high
    direct

    Component collusion via supply-chain compromise is the precise risk (13)(5)'s due-diligence-on-third-party-components obligation triggers — manufacturers must ensure integrated components do not compromise product cybersecurity.

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

    Component collusion via supply-chain compromise is the canonical case 92(1)'s contractual information-security obligation addresses — operators must structure supplier contracts to limit cooperative-component insertion.

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

    Art. 92(2)'s supply-chain-risk-strategy obligation is domain-relevant to colluding components, but the cited strategy mandate names no interdicting mechanism; component-provenance verification would be the interdiction.

  • nis2Art. 21(2)(b)
    addresses
    moderate
    derived

    Coordinated-implant detection via cross-component behavioural baselines (shared-resource writes, trigger-action correlation, mission-state-keyed activations) is part of Art. 21(2)(b)'s incident-handling capability — log analysis on a single module is insufficient.

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

    Coordinated multi-component compromise originates in the supply-chain process (multiple modules from multiple vendors compromised together); Art. 21(2)(d)'s supplier-relationship security obligation is the central control over that origin.

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

    Detection of cooperative-multi-component behaviour requires assurance disciplines (cross-component static analysis, behavioural fuzzing, integration-level vulnerability handling) Art. 21(2)(e)'s secure development/maintenance + disclosure obligation is meant to cover.

  • nis2Art. 21(3)
    addresses
    high
    direct

    Cross-supplier coordination of cooperative implants is the kind of supplier-specific vulnerability Art. 21(3) requires the entity to consider when sizing reliance on combinations of vendors whose products co-resident on the same vehicle.

  • nis2-implAnnex 5.1.1
    addresses
    high
    derived

    Coordinated compromise of multiple software modules during the supply chain process is the canonical multi-supplier collusion threat the supply-chain policy is established to govern.

  • nis2-implAnnex 5.1.6
    addresses
    high
    derived

    Component-collusion compromise rides through coordinated supply-chain manipulation across multiple suppliers; Annex 5.1.6 ongoing monitoring (correlating signals across the supplier population) is the procedural mechanism that surfaces such cross-supplier collusion patterns.

  • nis2-implAnnex 5.1.7
    addresses
    high
    derived

    Annex 5.1.7 follow-up procedures convert cross-supplier collusion signals into integration-test reinforcement and supplier-replacement actions.

  • nis2-implAnnex 6.2.1
    addresses
    high
    derived

    Secure-development discipline (cross-module review, integration testing, defensive coding) is the developmental control that surfaces colluding modules whose individual behaviour appears benign but whose composition produces malicious effect.

  • nis2-implAnnex 6.5.1
    addresses
    moderate
    derived

    Security-testing procedures (integration testing, behavioural testing across module boundaries) are the procedural mechanism that surfaces collusive component interactions before they reach production.

  • nis2-implAnnex 6.5.2
    addresses
    high
    derived

    Component-collusion testing scope (cross-module behavioural analysis, integration-level security testing) is what Annex 6.5.2 requires the entity to define under risk-assessment-driven testing.

  • nis2-implAnnex 6.5.3
    addresses
    moderate
    derived

    Annex 6.5.3 review-cadence ensures cross-module testing scope evolves as supplier composition and module interactions change.

ENISA controls

  • ENISA-STL-2025-03-sD.20-i04
    addresses
    high

    Cyber supply-chain risk management with multi-supplier diversification reduces the surface where coordinated-component compromise can stage cooperative behaviour.

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

    A documented secure development lifecycle is relevant to integration review, but the generic secure-engineering-principles excerpt does not actively prevent the multi-component collusion DE-0012 designs to appear benign in isolation.

  • ENISA-STL-2025-03-sD.28-i01
    addresses
    high

    Supplier security management with ISMS audits scopes the supply-chain relationships under which component-collusion compromise must arise.

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

    Software supply-chain integrity controls (hash sums, supplier audits) raise the cost of inserting two-or-more cooperating modules through the supply chain.

Cross-reference controls

SPARTA countermeasures

Cite as SafeMode Space, DE-0012 (SPARTA v3.2).

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