Implementing Continuous Threat Exposure Management (CTEM)

Threat and vulnerability management cannot keep pace with the speed and scale of modern attacks. In 2026, it is not enough to run occasional vulnerability scans and hope that high‑risk exposures are caught before attackers find them. Yet most security teams still treat vulnerability scans as one‑off exercises. This article explains how to build a CTEM program that continuously discovers, prioritizes, validates and remediates exposures. I provide hands‑on examples for practitioners, showing how to combine attack‑path modelling and MITRE ATT&CK mapping with automation, risk scoring and board‑level reporting.

What is Continuous Threat Exposure Management (CTEM)?

Continuous Threat Exposure Management (CTEM) is a cybersecurity approach that continuously identifies, prioritizes, validates and addresses exposures based on their likelihood of exploitation and potential business impact. Unlike traditional vulnerability management, CTEM looks beyond individual vulnerabilities to consider misconfigurations, attack paths, asset criticality, threat intelligence and control effectiveness.

Why continuous exposure management matters

Traditional vulnerability management generates huge lists of CVEs but often lacks context about how those weaknesses could be exploited. Attackers, meanwhile, monitor the same feeds and weaponize exploit code within hours. Quarterly scans can’t keep up with this velocity; they leave exposures unaddressed for months while attackers move at machine speed. Continuous exposure management closes that gap by combining discovery, attack path analysis and business risk to determine which exposures matter most. Exposure management should be continuous and risk‑based, incorporating threat intelligence and business context, not just static CVSS scores.

CTEM also addresses the expanding attack surface. Cloud, SaaS, on‑premises, OT and IoT systems blur the perimeter; misconfigured APIs, forgotten subdomains and partner integrations all create exploitable paths. CTEM provides a continuous loop of scoping, discovery, prioritization, validation and mobilization. Each stage feeds the next, allowing security leaders to focus on exposures that matter to the business and to validate controls regularly.

Overview of the five‑step CTEM cycle

I summarize these phases here and will expand on each with practical advice and code examples:

1. Scoping: Define what is in scope: business‑critical assets, processes, likely adversaries and attack surfaces across on‑prem, cloud, SaaS and OT. Scoping aligns security efforts with business priorities.

2. Discovery: Continuously identify assets, misconfigurations and vulnerabilities using attack surface management and scanning tools. Discovery should include shadow IT, third‑party connections and unknown endpoints 

3. Prioritization: Rank exposures based on exploitability and business impact, not just CVSS severity. This stage uses threat intelligence and attack‑path mapping to determine which issues are most likely to be exploited.

4. Validation: Confirm whether exposures are actually exploitable by using safe, controlled attack simulations or breach‑and‑attack testing. Validation ensures that remediation efforts address real risk, not hypothetical vulnerabilities.

5. Mobilization: Turn findings into action by coordinating cross‑functional remediation, implementing compensating controls and feeding exposure data into board‑level dashboards. Mobilization closes the loop and informs the next scoping cycle.

In the following sections I describe how to implement each stage, provide code snippets for automation and discuss cultural shifts necessary for a successful CTEM program.

Scoping: defining critical assets and attack surfaces

Scoping determines where to focus CTEM efforts. Without a clear scope, continuous discovery can generate unmanageable noise. Scoping should involve stakeholders from business, IT and security to identify the systems and processes that are critical to revenue, operations or regulatory compliance. These might include customer‑facing web applications, payment processing systems, data repositories or third‑party integrations.

Asset inventory via API integration

Most organizations already have multiple asset repositories: CMDBs, cloud APIs, endpoint agents and vulnerability scanners. A CTEM program should aggregate these sources into a unified inventory. The following Python example uses the requests library to query hypothetical APIs for a CMDB and a cloud provider and to build a consolidated asset list. Adjust the endpoints and authentication mechanisms to your environment.

import requests
from typing import List, Dict

def fetch_cmdb_assets(cmdb_url: str, api_key: str) -> List[Dict]:
headers = {"Authorization": f"Bearer {api_key}"}
resp = requests.get(f"{cmdb_url}/assets", headers=headers, timeout=30)
resp.raise_for_status()
return resp.json().get("assets", [])

def fetch_cloud_assets(cloud_api_url: str, token: str) -> List[Dict]:
headers = {"Authorization": f"Bearer {token}"}
resp = requests.get(f"{cloud_api_url}/v1/resources", headers=headers, timeout=30)
resp.raise_for_status()
return resp.json().get("resources", [])

def consolidate_assets(cmdb_assets: List[Dict], cloud_assets: List[Dict]) -> Dict[str, Dict]:
consolidated = {}
for asset in cmdb_assets + cloud_assets:
# Use a unique identifier (e.g., hostname or instance ID)
uid = asset.get("id") or asset.get("instance_id")
if not uid:
continue
consolidated.setdefault(uid, {}).update(asset)
return consolidated

# Example usage
cmdb_assets = fetch_cmdb_assets("https://cmdb.example.com/api", "CMDB_API_KEY")
cloud_assets = fetch_cloud_assets("https://api.cloudprovider.com", "CLOUD_TOKEN")
inventory = consolidate_assets(cmdb_assets, cloud_assets)

print(f"Discovered {len(inventory)} unique assets in scope.")

This script retrieves assets from a CMDB and a cloud provider, merges them using unique identifiers and prints a count of the total assets. In a real CTEM implementation you would repeat this for additional sources (e.g., SaaS providers, container orchestrators, OT sensors) and annotate each asset with business context (criticality, data sensitivity, owner). Without such context, later stages of prioritization will lack the information needed to measure business impact.

Mapping assets to business processes

Once you have an inventory, map each asset to the business process it supports. This mapping can be maintained in a spreadsheet or a configuration management database. Including business owners ensures that security decisions align with operational priorities. During scoping, identify potential adversaries and their likely tactics based on industry threat intelligence. The scoping stage focuses on the business aspects most important to senior management. Aligning CTEM to these priorities fosters executive buy‑in and ensures that exposure reduction efforts translate into tangible risk reduction.

Discovery: continuous asset and vulnerability identification

Discovery is more than periodic scanning. The goal is to continuously identify both assets and exposures across your entire attack surface. Tenable recommends including unpatchable attack surfaces, misconfigurations and insecure credentials across IT, OT, cloud and IoT. Shadow IT, forgotten subdomains and third‑party connections all need to be discovered because attackers frequently exploit external exposures that organizations overlook. Point‑in‑time assessments cannot keep pace with cloud deployments and infrastructure changes, reinforcing the need for continuous discovery.

Attack surface management and secondary assets

Attack surface management (ASM) platforms scan internet‑facing assets, discovering unknown services, exposed APIs and expired certificates. Discovery should also include secondary assets; systems that are not directly part of a critical process but could be abused to reach it. I also advise using attack path mapping to understand lateral movement from secondary assets to critical ones. For example, an outdated Jenkins server might not host sensitive data but may provide a foothold into your CI/CD pipeline.

Automating discovery with Python

The next script demonstrates a simple way to query an ASM platform and a vulnerability scanner, then store exposures in a database. Replace the endpoints with your vendor APIs and add proper authentication. The function parse_findings normalizes results into a consistent structure.

import sqlite3
import requests

def fetch_asm_exposures(asm_api_url: str, api_key: str):
headers = {"Authorization": f"ApiKey {api_key}"}
response = requests.get(f"{asm_api_url}/exposures", headers=headers, timeout=30)
response.raise_for_status()
return response.json().get("exposures", [])

def fetch_scanner_findings(scanner_url: str, token: str):
headers = {"Authorization": f"Bearer {token}"}
response = requests.get(f"{scanner_url}/findings", headers=headers, timeout=30)
response.raise_for_status()
return response.json().get("findings", [])

def parse_findings(raw_findings):
normalized = []
for item in raw_findings:
normalized.append({
"id": item.get("id"),
"asset": item.get("asset_id"),
"type": item.get("type"),
"severity": item.get("severity"),
"description": item.get("description"),
"url": item.get("url"),
})
return normalized

def store_exposures(db_path: str, exposures):
conn = sqlite3.connect(db_path)
cur = conn.cursor()
cur.execute("""CREATE TABLE IF NOT EXISTS exposures (
id TEXT PRIMARY KEY,
asset TEXT,
type TEXT,
severity TEXT,
description TEXT,
url TEXT
)""")
for exp in exposures:
cur.execute(
"INSERT OR REPLACE INTO exposures (id, asset, type, severity, description, url) VALUES (?,?,?,?,?,?)",
(exp['id'], exp['asset'], exp['type'], exp['severity'], exp['description'], exp['url'])
)
conn.commit()
conn.close()

# Example usage
raw_asm = fetch_asm_exposures("https://asm.example.com/api", "ASM_API_KEY")
raw_scanner = fetch_scanner_findings("https://scanner.example.com/api", "SCANNER_TOKEN")
all_exposures = parse_findings(raw_asm) + parse_findings(raw_scanner)
store_exposures("/tmp/ctem_exposures.db", all_exposures)
print(f"Stored {len(all_exposures)} exposures in database.")

With a database of exposures, you can correlate exposures across tools, map them to assets and prepare them for prioritization. To detect newly discovered assets, schedule this script to run hourly or daily, and compare the latest findings against the baseline inventory.

Prioritization: risk‑based ranking of exposures

CTEM prioritization goes beyond severity scores; it considers exploitability, business impact, exposure paths and adversary relevance. Only a subset of identified exposures require immediate remediation; others may be mitigated by compensating controls. Traditional vulnerability management creates extensive backlogs and lacks validation mechanisms. Risk‑based prioritization helps teams focus on exposures that matter.

Calculating a custom risk score

Here is a Python example that calculates a simple risk score by combining CVSS severity, whether a known exploit exists, asset criticality and whether the asset is internet-facing. In practice, you could extend this model with EPSS data to incorporate exploit likelihood and threat intelligence to identify active exploitation.

def compute_risk(severity: str, has_known_exploit: bool, criticality: int, internet_facing: bool) -> float:
# Assign numeric values to severity
severity_weights = {"low": 1, "medium": 3, "high": 6, "critical": 9}
base = severity_weights.get(severity.lower(), 1)
# Increase risk if exploit exists
exploit_modifier = 2 if has_known_exploit else 1
# Increase risk based on asset criticality (1–5 scale)
criticality_modifier = criticality
# Internet‑facing assets get an extra multiplier
exposure_modifier = 1.5 if internet_facing else 1
return base * exploit_modifier * criticality_modifier * exposure_modifier

# Example: compute risk for a high‑severity vulnerability on a critical, internet‑facing asset with a known exploit
score = compute_risk("high", True, 5, True)
print(f"Calculated risk score: {score}")

You can extend this function with additional factors such as data sensitivity, user accounts, control gaps or whether the exposure appears in CISA’s Known Exploited Vulnerabilities (KEV) Catalog. After calculating scores for each exposure, sort them and group by remediation team to generate an actionable backlog. Prioritization should also incorporate attack path analysis to identify exposures that enable lateral movement or privilege escalation; we discuss attack paths in the validation section.

Business context and board‑level dashboards

Prioritization only succeeds when exposures are mapped to business impact. For example, a medium‑severity vulnerability in a public‑facing e‑commerce portal may be more critical than a high‑severity vulnerability in an internal test system. To communicate these insights to executives, CTEM programs feed exposure data into board‑level dashboards, showing trends such as time‑to‑remediate, exposure counts by criticality and reduction of attack paths over time. This fosters risk‑based decision‑making and holds teams accountable for remediation progress.

Validation: proving exploitability and control effectiveness

Validation differentiates CTEM from traditional vulnerability management. Rather than assuming that all high‑severity exposures are equally exploitable, validation uses safe simulations to prove whether an attacker could realistically exploit a vulnerability or misconfiguration. You can also use penetration tests and red/purple teaming to test exploitability and measure the effectiveness of existing controls. Validation addresses the false sense of security created by patch counts, as many CVEs may not be exploitable in your environment.

Attack path modeling and MITRE ATT&CK mapping

Modern CTEM platforms integrate attack path modeling (graph‑based representations of how an adversary might pivot through an environment) with the MITRE ATT&CK framework. Attack path modeling identifies the sequence of exploitations, misconfigurations and credentials an attacker could use to reach a critical asset. MITRE ATT&CK provides a taxonomy of tactics, techniques and procedures (TTPs) that can be used to classify exposures and ensure that detection and response controls align with real adversary behaviors.

Below is a simplified example using the Python networkx library to build an attack graph. Each node represents an asset, and edges represent exploit paths. The script calculates all attack paths from an entry point to a target asset and labels each edge with corresponding MITRE techniques. In a production CTEM program, these mappings would come from your threat intelligence and vulnerability database.

import networkx as nx

# Define assets and potential exploit paths
G = nx.DiGraph()
G.add_node("internet")
G.add_node("web_server")
G.add_node("app_server")
G.add_node("database")

G.add_edge("internet", "web_server", technique="T1190: Exploit Public-Facing Application")
G.add_edge("web_server", "app_server", technique="T1059: Command and Scripting Interpreter")
G.add_edge("app_server", "database", technique="T1078: Valid Accounts")

# Find all paths from external entry to critical database
paths = list(nx.all_simple_paths(G, source="internet", target="database"))
for p in paths:
techniques = [G[p[i]][p[i+1]]['technique'] for i in range(len(p)-1)]
print(f"Attack path: {' -> '.join(p)}")
print(f"Techniques: {', '.join(techniques)}\n")

The output might look like:

Attack path: internet -> web_server -> app_server -> database
Techniques: T1190: Exploit Public‑Facing Application, T1059: Command and Scripting Interpreter, T1078: Valid Accounts

Security teams can overlay detection logic onto this graph. For example, ensure that web application firewalls detect T1190 exploitation attempts, that endpoint detection responds to suspicious script execution (T1059) and that identity governance flags anomalous credential use (T1078). By validating attack paths in this way, CTEM practitioners can prioritize exposures that chain together into high‑impact attack paths and confirm that controls will break the chain.

Breach simulation and safe testing

Validation also involves running safe, controlled simulations of attacks. Open‑source tools such as Atomic Red Team and PurpleSharp provide modular scripts to simulate specific ATT&CK techniques. When integrated into a CTEM pipeline, these simulations can run automatically against scoped assets, verifying that controls trigger as expected. For example, you could use Atomic Red Team to simulate a credential stuffing attack against an exposed login endpoint and monitor whether your identity provider generates an alert. Tools like Caldera allow for multi‑step adversary emulation across an attack path, aligning with the graph built above. Recording the outcome of each simulation provides data for risk dashboards and ensures that exposures classified as “high risk” truly are exploitable.

Mobilization: turning insights into action

The final stage of CTEM is mobilization, translating prioritized and validated findings into remediation activities. Mobilization involves integrating remediation processes into existing workflows and collaborating with non‑security teams. CrowdStrike emphasizes the need to coordinate cross‑functional teams, streamline approvals and automate remediation to avoid bottlenecks. Without effective mobilization, CTEM becomes yet another source of reports with no impact.

Automating ticket creation and remediation tasks

The following Python snippet demonstrates how to automatically create tickets in Jira (or another issue tracking system) for high‑risk exposures. It iterates through the exposures stored earlier, filters those above a risk threshold and posts them to a Jira REST API.

import requests

def create_jira_ticket(jira_url, auth, project_key, summary, description):
data = {
"fields": {
"project": {"key": project_key},
"summary": summary,
"description": description,
"issuetype": {"name": "Task"}
}
}
response = requests.post(
f"{jira_url}/rest/api/2/issue", json=data, auth=auth, timeout=30
)
response.raise_for_status()
return response.json().get("key")

def mobilize_exposures(db_path, jira_url, auth, project_key, risk_threshold):
import sqlite3
conn = sqlite3.connect(db_path)
cur = conn.cursor()
cur.execute("SELECT id, asset, severity, description, url FROM exposures")
for row in cur.fetchall():
exposure_id, asset, severity, description, url = row
# Compute risk score (this example just uses severity as a proxy)
severity_weights = {"low":1, "medium":3, "high":6, "critical":9}
risk_score = severity_weights.get(severity.lower(), 1)
if risk_score >= risk_threshold:
summary = f"Remediate {exposure_id} on {asset}"
desc = f"Exposure description: {description}\nDetails: {url}\nRisk score: {risk_score}"
ticket_id = create_jira_ticket(jira_url, auth, project_key, summary, desc)
print(f"Created Jira ticket {ticket_id} for exposure {exposure_id}")
conn.close()

# Example usage
JIRA_URL = "https://jira.example.com"
AUTH = ("username", "api_token")
PROJECT_KEY = "SEC"
mobilize_exposures("/tmp/ctem_exposures.db", JIRA_URL, AUTH, PROJECT_KEY, risk_threshold=6)

Mobilization doesn’t end with ticket creation. Track remediation status and time‑to‑fix metrics to drive accountability. Integrate CTEM outputs into security orchestration and automation (SOAR) platforms for automated patch deployment or policy enforcement when possible. Empower teams with self‑service dashboards so they can see their own exposure backlog and progress.

Reporting exposures to executives

Boards and executives want to know whether the organization is reducing risk, not how many CVEs were closed. CTEM provides metrics such as mean time to remediate (MTTR), number of validated attack paths, percentage of critical assets with unknown exposures and trend lines of exposure reduction. Use dashboards to visualize exposures per business unit and show the effect of remediation on risk over time. Present these metrics in the context of business outcomes: for example, highlight how reducing an attack path could prevent service downtime or regulatory fines.

Best practices and lessons learned

Implementing CTEM requires more than tools; it demands a cultural shift. Many teams still equate vulnerability management with patch counts. CTEM encourages teams to think in terms of exposure, the combination of asset criticality, exploitability and adversary intent. This shift empowers security professionals to focus limited resources on exposures that could lead to compromise. Based on industry guidance and practical experience, the following best practices can help you succeed with CTEM:

1. Adopt a continuous mindset: CTEM is not a one‑time project. Tools and processes must support continuous discovery, assessment and prioritization.

2. Prioritize based on business risk: Evaluate exposures using business context, internet exposure and threat intelligence instead of static scores.

3. Integrate threat intelligence: Incorporate intelligence about known exploited vulnerabilities and attacker TTPs such as MITRE ATT&CK.

4. Automate where possible: Automate asset discovery, risk scoring and remediation workflows to improve speed and efficiency.

5. Collaborate across teams: Exposure reduction often involves infrastructure, DevOps and application teams. Work collaboratively and provide them with actionable context.

6. Validate regularly: Use breach and attack simulations to confirm that exposures are exploitable and that controls are effective.

7. Measure and report outcomes: Track metrics like MTTR, exposure trends and validated attack paths. Use board‑level dashboards to communicate progress.

Frequently asked questions about CTEM

What is Continuous Threat Exposure Management (CTEM)?

CTEM is a continuous, cyclical approach to reducing risk, rather than a one-time assessment. It combines asset discovery, business context, exploitability and validated attack paths to determine where an organization is genuinely exposed, instead of relying on static vulnerability counts or CVSS scores alone.

What are the five stages of CTEM?

CTEM runs through scoping, discovery, prioritization, validation and mobilization, with each cycle feeding the next. In short: decide what matters, find the exposures, rank them by real-world risk, prove which ones are actually exploitable, then route the confirmed findings into remediation.

How is CTEM different from traditional vulnerability management?

Traditional vulnerability management tends to produce large backlogs of CVEs ranked by severity alone, often without validating which ones an attacker could realistically use. CTEM adds that missing layer: business impact, exploitability and attack-path validation, so remediation effort goes toward exposures that pose actual risk rather than every finding on a scan report.

How do you implement a CTEM program?

Most programs start small: pick one critical business process or asset group, run it through the full five-stage cycle, and use that as the template before scaling. Automation for discovery and risk scoring, along with a validation step using safe attack simulations, help separate a working CTEM program from a vulnerability scanner with a new name.

Conclusion

Continuous Threat Exposure Management transforms vulnerability management from a periodic task into an ongoing, risk‑aligned program. By following the five‑step cycle (scoping, discovery, prioritization, validation and mobilization) security teams can continuously reduce business exposure. Attack path modeling and MITRE ATT&CK mapping help focus on realistic threats, while automation and risk scoring ensure that remediation efforts target the most critical issues.

Most importantly, CTEM shifts the conversation from patch counts to measurable risk reduction, making security a strategic partner in business resilience. If you'd like help building a continuous threat exposure management program that reduces real business risk, explore Arctiq's CTEM-Aligned Exposure & Resilience Advisory, part of our broader Cybersecurity Advisory Services.