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

Security Testing Tools

Parent: REC-0006

Description

Adversaries study how you test to learn what you don’t test. They inventory static analyzers and coding standards (MISRA/C, CERT, CWE rulesets), dynamic tools (address/UB sanitizers, valgrind-class tools), fuzzers targeted at command parsers and protocols (e.g., CCSDS TC/TM, payload formats), property-based tests, mutation testing, coverage thresholds, and formal methods applied to mode logic or crypto. They also examine HIL setups, fault-injection frameworks, timing/jitter tests, and regression suites that gate release. Gaps, such as minimal negative testing on rare modes, weak corpus diversity, or untested rate/size limits, inform exploit design and the timing of inputs to evade FDIR or saturate queues.

Mappings

EU regulation articles

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

    Annex I, Part II, (3) requires manufacturers to apply effective and regular tests and reviews of product security; the same disciplined testing program that surfaces vulnerabilities also drives the test-tool inventory that security-testing-tools reconnaissance attempts to enumerate, but a manufacturer that systematically tests narrows the gap-discovery surface.

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

    Test-tool inventories, fuzzer corpora, and coverage thresholds are operator-held artifacts whose disclosure reveals untested attack surfaces — 80(3)'s categorization applies.

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

    Reconnaissance of the operator's testing programme (static analyzers, fuzzers, formal-methods coverage) discloses test gaps; 88(1)'s testing programme obligation places operator responsibility on what is tested and how.

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

    Security-testing-tool reconnaissance (primary: Art. 88(1)) cascades to 88(3) — TLPT 3-yearly cadence is the high-level discipline that surfaces gaps in operator's own testing programme.

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

    Static analysers, fuzzers, sanitisers, fault-injection rigs, and coverage gates are the assurance discipline secure development and maintenance under Art. 21(2)(e) — including disclosed-vulnerability handling — explicitly mandates.

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

    Coverage thresholds, mutation testing, and the gating logic between testing and release are how the entity assesses the effectiveness of its cybersecurity risk-management measures under Art. 21(2)(f).

  • nis2-implAnnex 12.1.1
    addresses
    moderate
    derived

    Test plans, fuzz-harness configurations and known-blind-spot inventories are highly sensitive assets; their classification governs the recon surface for an adversary mapping the entity's test-tool gaps.

  • nis2-implAnnex 6.5.1
    addresses
    high
    direct

    Security-testing tools and policies are exactly what the implementing regulation requires the entity to formalize; the same policy that codifies what is tested also codifies what knowledge of testing must remain confidential.

  • nis2-implAnnex 6.5.2
    addresses
    moderate
    derived

    Security-testing-tools reconnaissance targets the same testing scope Annex 6.5.2 requires the entity to define; the policy that codifies what is tested also codifies what knowledge of testing must remain confidential.

  • nis2-implAnnex 6.5.3
    addresses
    moderate
    derived

    Annex 6.5.3 review-cadence keeps the testing-policy and tool inventory current, which constrains the recon adversary's blind-spot map of the entity's test-tool gaps.

ENISA controls

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

    The secure development lifecycle governs how security testing tools and their outputs are stored, accessed, and disposed of.

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

    Security testing results are the artefact REC-0006.02 reconnoiters, so the control is relevant, but the excerpt describes using pentest and scan results to identify vulnerabilities, not actively defending them against reconnaissance, so addresses rather than mitigates.

Cross-reference controls

SPARTA countermeasures

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

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