Skip to main content

CTEM Stage 2: Discovery

Stage Summary: Discovery identifies the assets in scope and the exposures that affect them—vulnerabilities, misconfigurations, identity weaknesses, and control gaps—captured with enough evidence to support prioritization and validation.

Discovery data pipeline to exposure register

Why Discovery Matters​

CTEM discovery is not a one-time inventory sweep. It is the discipline of maintaining continuous, high-fidelity visibility into what you own (and what you accidentally expose), with enough context to drive action.

Authoritative guidance across government and standards bodies consistently converges on this point:

  • Asset visibility and vulnerability detection are foundational to measurable cybersecurity progress (e.g., CISA’s direction for asset visibility and vulnerability detection).
  • Inventories must be accurate, complete for the defined boundary, and maintained at a practical level of granularity (e.g., inventory controls in common security baselines).
  • Monitoring programs should continuously refine measurements and align them with risk tolerance (continuous monitoring guidance).

The CTEM nuance is what you do with discovery output: discovery is not judged by the volume of findings. It is judged by how well it enables prioritization and validation against your scoped “crown jewels.”

Discovery Outcomes​

OutputWhat “good” looks likeAnti-pattern
Asset inventory for in-scope boundaryHigh ownership coverage; low staleness; stable identifiersCMDB-as-truth, stale records
Exposure registerEvidence-backed, deduped, actionableOne giant unverified findings list
Context enrichmentReachability, identity/privilege context, business service mappingSeverity-only metadata
Data lineageYou can explain where each record came from and when“Trust the tool”
A pragmatic target

If your discovery output cannot tell you who owns an exposed condition and whether it is still present, it will not survive contact with remediation workflows.

Key Activities​

1. Establish an Authoritative Asset Inventory (for the Scope)​

Discovery begins by answering “what exists?” inside the boundary you defined in Stage 1.

In mature environments, the best asset inventory is not a single system—it is a reconciled view built from multiple sources, each with known strengths:

  • Cloud control planes (instances, serverless, storage, IAM roles, public endpoints)
  • DNS and certificate ecosystems (domains/subdomains, cert transparency signals, newly issued certs)
  • Identity providers (users, service principals, privileged roles, MFA posture)
  • SaaS admin consoles (tenant configuration, sharing posture, OAuth apps, admin roles)
  • Endpoint and server telemetry (agents, hostnames, OS versions)
  • Network sources (DHCP, VPN, proxy logs) where appropriate

Asset inventory design constraints (worth stating explicitly)​

  • Stable identifiers: decide what uniquely identifies an asset class (domain, account ID, instance ID, application ID, repo ID).
  • Ownership as a required field: if you can’t assign ownership, you can’t run CTEM at scale.
  • Freshness SLAs: define how stale is acceptable (e.g., external domains < 24h; SaaS config < 7d; internal inventory < 7d).

Known vs unknown assets

2. Enumerate Exposures Beyond CVEs​

CTEM discovery explicitly extends beyond classic vulnerability management. Exposures you should expect to track (depending on scope) include:

  • Software vulnerabilities (CVE-based issues, dependency weaknesses)
  • Configuration exposures (insecure defaults, overly permissive access, weak TLS posture)
  • Identity exposures (privileged accounts without MFA, excessive permissions, stale service principals)
  • SaaS posture gaps (public sharing, risky OAuth apps, unmanaged admin roles)
  • Attack-path primitives (reachable management interfaces, exposed secrets, weak segmentation)
  • Third-party integration exposures (overprivileged integrations, insecure vendor connectivity patterns)

A useful working definition in CTEM programs:

  • Vulnerability: a flaw in software/hardware.
  • Exposure: a condition that increases the likelihood or impact of compromise (can include vulnerabilities, but also misconfigurations, identities, and control gaps).

This framing matters because the most exploitable conditions are often combinations: a reachable service + weak auth + overprivileged identity + exposed data.

3. Capture Evidence and Context (Not Just Findings)​

Discovery output must be defensible. For each exposure record, capture:

  • Evidence: what you saw (config snippet, response header, policy state, scanner evidence ID)
  • Timestamping: first seen / last seen (and a confidence interval if applicable)
  • Reachability: internet-facing, partner-facing, internal-only, or segmented
  • Privilege context: does exploitation require auth? which role? is MFA enforced?
  • Business mapping: which critical service/asset category does this affect?
  • Compensating controls (if known): WAF, segmentation, EDR, conditional access, etc.
Evidence is what enables validation

Without evidence, remediation teams will push back (correctly), and validation teams will waste time re-discovering the same condition.

4. Normalize, Deduplicate, and Validate Data Quality​

High-volume discovery without normalization becomes unusable. Minimum hygiene:

  • Deduplicate exposures across tools (same CVE, same asset, multiple sources)
  • Normalize naming (domains, hostnames, cloud resource tags, repo names)
  • Enforce schemas (asset classes and exposure types are enumerable; avoid free-text chaos)
  • Ownership resolution (use tags, repo ownership files, directory groups, service catalogs)
  • Freshness checks (stale assets/exposures are explicitly marked and re-verified)

Discovery Templates​

Template A: Exposure Register (minimum viable)​

FieldDescription
Exposure IDUnique ID for the exposure record
Asset ID / NameDomain, resource ID, app/service identifier
Asset classApp/API, SaaS tenant, identity object, cloud resource, endpoint
Business serviceWhich scoped service this supports
Exposure typeCVE, misconfiguration, identity weakness, control gap
Severity signalCVSS (if applicable) or internal severity
EvidenceLink/ID to supporting evidence (redacted if needed)
ReachabilityInternet / partner / internal
PreconditionsAuth required? privilege required?
OwnerTeam/individual accountable
First seen / last seenTimestamps
StatusOpen / mitigated / accepted / false positive
NotesCompensating controls, change windows, etc.

Template B: Data Quality Scorecard (for discovery health)​

MetricTargetWhy it matters
% assets with assigned owner≥ 95%Enables mobilization
% exposures with evidence≥ 90%Enables validation and remediation trust
Median “last seen” age (external)< 48hKeeps external reality current
Deduplication rateIncreasing early, stabilizing laterIndicates normalization maturity
“Unknown asset” rateTrending down over timeIndicates reduced shadow IT

Common Pitfalls​

  1. Counting findings as success. Volume is not fidelity.
  2. Relying on a single source of truth. Every inventory source lies somewhere; reconcile.
  3. Ignoring identity and SaaS discovery. Modern environments are identity-anchored and SaaS-heavy.
  4. No evidence, no timestamps. “We think it’s exposed” doesn’t survive triage.
  5. No ownership mapping. Unassigned exposures accumulate indefinitely.
  6. Stale discovery cadences. Quarterly discovery in a cloud-first enterprise is effectively historical reporting.

Next Steps​

With an evidence-backed exposure register in hand, move to Prioritization to decide what matters most.

References (non-vendor)​