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

Known Vulnerabilities

Parent: REC-0008

Description

Adversaries correlate discovered component and software versions with public and private vulnerability sources to assemble a ready exploit catalog. Inputs include CPE/CVE mappings, vendor advisories, CWE-class weaknesses common to selected RTOS/middleware, FPGA IP core errata, cryptographic library issues, and hardware stepping errata that interact with thermal/power regimes. They mine leaked documents, demo code, bug trackers, and community forums; pivot from ground assets to flight by following shared libraries and tooling; and watch for lag between disclosure and patch deployment. Even when a vulnerability seems “ground-only,” it may expose build systems or update paths that ultimately control flight artifacts.

Mappings

EU regulation articles

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

    Manufacturer obligation to identify and document vulnerabilities and components is precisely what closes the gap an adversary's known-vulnerability reconnaissance attempts to exploit: when the manufacturer's vulnerability inventory is current, the adversary's recon yields no asymmetric advantage.

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

    Manufacturers must address and remediate vulnerabilities without delay; this is the operational discipline that bounds the time between disclosure and exploitation, which is the metric known-vulnerability reconnaissance is trying to outrun.

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

    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.

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

    Manufacturer obligation to provide secure update-distribution mechanisms ensures that remediation actually reaches deployed products; without that distribution path, vulnerability-handling discipline upstream cannot close the exploit window the adversary's recon attempts to widen.

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

    Manufacturer obligation to disseminate security updates without delay once available is the temporal discipline that bounds the exploit window for known vulnerabilities.

  • craArt. 13(6)
    addresses
    high
    derived

    Manufacturer-on-component vulnerability handling (including for open-source components) is the precise obligation an adversary's known-vulnerability reconnaissance attempts to exploit before remediation; Art. 13(6) establishes the manufacturer's duty when a vulnerability is identified in a contained component.

  • craArt. 13(8)
    addresses
    high
    derived

    Manufacturer obligation to provide security updates throughout the support period is the long-tail discipline that closes recon-driven exploit windows for the lifetime of deployed products.

  • craArt. 14(1)
    addresses
    moderate
    derived

    Manufacturer obligation to notify actively-exploited vulnerabilities is the procedural escalation lever that ensures known-but-exploited vulnerability information reaches authorities and downstream defenders quickly.

  • craArt. 14(10)
    relates to
    low
    direct

    Known-vulnerability reconnaissance notification (primary mapping: Art. 14(1)) follows the format and procedures specified by (14)(10)'s implementing acts.

  • craArt. 14(2)
    addresses
    moderate
    direct

    Known-vulnerability reconnaissance with active notification (primary mapping: Art. 14(1)) directly cascades to (14)(2)'s timing schedule — the procedural specification of the notification timeline.

  • craArt. 14(9)
    relates to
    moderate
    direct

    Known-vulnerability reconnaissance (primary mapping: Art. 14(1)) is a scenario where premature dissemination of notification could weaponize a still-unpatched vulnerability; (14)(9)'s delegated-acts on cybersecurity-grounds for delaying dissemination directly govern this case.

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

    Known-vulnerability reconnaissance (primary: Art. 78(1)) directly engages ISMS vulnerability-register discipline; 76(5)'s ISMS is the management container for the operator's vulnerability landscape.

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

    78(1)(c) requires operators to identify cybersecurity vulnerabilities and analyse them when they cannot be fixed immediately; (d) requires risk treatment plans for vulnerabilities above acceptable risk — directly addressing known-vulnerability exposure.

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

    88(1)'s testing programme obligation, including (88)(3)'s 3-yearly Threat Led Penetration Testing, validates that the operator's products are tested against known-vulnerability catalogs.

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

    Known-vulnerability reconnaissance (primary: Art. 88(1)) cascades to 88(3) — TLPT validates that operator products are tested against known-vuln catalogs at the 3-yearly cadence.

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

    91(4)'s address-the-root-causes-of-incidents obligation requires operators to remediate the underlying vulnerabilities that adversaries are mapping in this technique.

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

    Vulnerability handling and disclosure under Art. 21(2)(e) is the precise obligation that requires the entity to track CPE/CVE matches against its components, monitor advisories, and close the disclosure-to-patch lag the technique exploits.

  • nis2-implAnnex 5.1.1
    addresses
    moderate
    derived

    Supply-chain security policy is the procedural lever for tracking supplier-disclosed vulnerabilities and pushing them through to remediation; weak supplier-side disclosure inflates the known-vulnerability recon surface.

  • nis2-implAnnex 6.10.1
    addresses
    high
    direct

    Vulnerability-handling-and-disclosure obligations require the entity to obtain and act on vulnerability information for its systems; that procedural mechanism shrinks the gap between adversary recon of CVE catalogs and the entity's own remediation timeline.

  • nis2-implAnnex 6.6.1
    addresses
    high
    direct

    Security-patch management procedures determine how quickly publicly-known vulnerabilities are closed in the entity's systems, which is the metric the adversary's known-vulnerability reconnaissance is trying to exploit before remediation.

ENISA controls

  • ENISA-STL-2025-03-sD.25-i02
    addresses
    high

    Vulnerability Management governs the operator collection and evaluation of known vulnerabilities, the domain REC-0008.03 mines, reducing exposure rather than actively defending against the reconnaissance itself.

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

    Vulnerability scanning by the operator surfaces the same exposures REC-0008.03 catalogs, allowing remediation before exploitation.

  • ENISA-STL-2025-03-sD.25-i06
    addresses
    high

    Regular software updates close the window in which a catalogued vulnerability is exploitable and reduce the value of REC-0008.03 catalog, but patching the victim does not prevent the reconnaissance activity itself, so addresses rather than mitigates.

Cross-reference controls

SPARTA countermeasures

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

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