Annex I, Part II, (5)

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.

Flight-software exploitation handled through the secure-update channel (primary mapping: Annex I, Part II, (7) secure update distribution) presumes a CVD policy as the upstream intake; (5) supplements (7) by establishing how vulnerabilities reach the manufacturer in the first place.

Exploitation of malicious code embedded during supply chain (primary mapping: Annex I, Part II, (1) + Art. 13(5)) requires CVD policy under (5) to receive and process third-party reports about such embedded artifacts.

Hardware-supply-chain backdoor exploitation (primary mappings: Part II, (1) + Part II, (2) + Art. 13(2)) creates a vulnerability-handling cascade where (5)'s CVD policy is the inbound channel for hardware-related vulnerability reports.

Vulnerability exploitation (primary mappings: Annex I, Part II, (1)+(2)+(3)) directly triggers the CVD policy obligation in (5) — the parent vulnerability-handling cluster includes inbound disclosure as a foundational requirement.

Known-vulnerability exploitation (primary mappings: Part II, (2)+(3)) makes (5) the cascade — discovered exploits must reach the manufacturer through a CVD channel for remediation timing to be meaningful.

Zero-day or undocumented-vulnerability exploitation (primary mappings: Part II, (1)+(2)) increases the importance of (5)'s CVD policy as the inbound channel for unknown-vuln reports from researchers and partners.

Exploitation of public/disclosed vulnerabilities (primary mappings: Part II, (1)+(2)+(8) + Art. 13(6)+(8)) sits squarely in the CVD lifecycle; (5) supplements the entire cluster as the inbound counterpart to the outbound disclosure obligations already in primary.

Stack/heap memory exploitation handled via secure update distribution (primary mapping: Part II, (7)) implies an upstream CVD process; (5)'s policy obligation is the procedural intake.

Compromise of supply chain (primary mappings: Part II, (1) + Art. 13(5) + Art. 13(6)) requires CVD policy under (5) to coordinate disclosure with upstream component manufacturers (Art. 13(6) presumes a CVD-grade discipline).

Software-dependency compromise (primary mappings: Part II, (1)+(2) + Art. 13(5)) creates an explicit need for a CVD channel to receive reports from open-source maintainers and downstream users.

Software supply-chain compromise (primary mappings: Part II, (7) + Art. 13(5) + Art. 13(8)) makes CVD policy under (5) the procedural intake for vulnerabilities that emerge in distributed-update channels.

Hardware supply-chain compromise (primary mappings: Part II, (1) + Art. 13(5)) requires CVD policy under (5) for receiving hardware-related vulnerability reports.

Compromised software updates initial-access (primary mappings: Part I, (2)(c) + Part II, (1) + Art. 13(5)) places a CVD policy obligation under (5) so update-channel anomalies can be reported and processed.

Malicious commands during software/firmware update (primary mappings: Part II, (7) + Art. 13(8)) presupposes a CVD process under (5) to receive reports of update-channel exploitation.

Malicious update persistence (primary mapping: Part II, (7) secure update distribution) implies CVD intake for reports about persistent post-update artifacts; (5) supplements the outbound (7) cascade.

Backdoor persistence (primary mappings: Part II, (3) + Art. 14(1) actively-exploited-vuln notification) directly triggers the CVD policy under (5) — vulnerabilities that lead to backdoor persistence flow through the CVD intake.

Hardware-backdoor persistence (primary mappings: Part II, (1) + Art. 13(5)) requires CVD intake under (5) for receiving hardware-component vulnerability reports relevant to backdoor detection.

Software-backdoor persistence (primary mappings: Part II, (3) + Art. 13(5)) implies CVD policy under (5) for inbound vulnerability reports concerning persistent malicious software.

Eavesdropping on update channels (primary mappings: Part I, (2)(c) + Part II, (1)) is detected and reported via the CVD intake (5) when third parties observe anomalies in the update flow.

Information-gathering on supply chain (primary mappings: Part II, (1) + Art. 13(5)) presupposes a CVD policy under (5) to coordinate inbound reports about supply-chain weaknesses.

Hardware-supply-chain reconnaissance (primary mappings: Part II, (1) + Art. 13(5)) requires CVD policy under (5) to handle inbound third-party hardware-related vulnerability reports.

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.

Known-vulnerability reconnaissance (primary mappings: Part II, (1)+(2)+(7)+(8) + Art. 13(6)+(8) + Art. 14(1)) is the CVD discipline's central case — (5) is the policy obligation that operationalizes the entire cluster.

Open-source-software reconnaissance (primary mapping: Art. 13(5)) requires a CVD intake under (5) as the inbound channel for OSS vulnerability disclosures from upstream maintainers.