New CTEM Metrics That Matter: How to Brief Your Board on AI-Accelerated Exposure
The exploitation clock used to give defenders room to breathe. A vulnerability got discovered, a team had weeks to patch it, and the numbers a CISO brought to the board, so many scans run, so many tickets closed, were reasonable proxies for progress.
AI has broken that clock. Continuous threat exposure management (CTEM) is the practice of continuously discovering, validating, and prioritizing real-world exposure instead of periodically scanning for it.
Nearly all organizations (94%) expanded their AI footprint while much fewer formally test more than 60% of what they deployed.1 This gap shifts how CISOs report on program quality, but are still bringing boards the metrics of a slower era.
Vulnerability discovery today runs at record volume and record speed, and the time between a finding surfacing and an attacker exploiting it has collapsed from months to hours. CTEM calls for a different reporting model entirely, one built for how fast exposure actually moves today.
Vulnerability Counts Were Built for a Slower World
A report built around vulnerability counts assumes the defender has time on its side, and that assumption no longer holds.
Based on HackerOne data: Submissions reporting vulnerabilities have increased 76% year over year. About 25% of those vulnerabilities are validated as exploitable. Critical and high-severity issues now make up 32% of all findings, up several percentage points from last year.
When AI-accelerated discovery surfaces thousands of new findings a week, what matters is which of them are real, and how fast a team can close the real ones before an attacker gets there first. A CISO who walks into a board meeting with scan totals and ticket counts is answering a question nobody is asking anymore.
Three Metrics to Replace Vulnerability Counts in a CTEM Program
What boards want to know is whether the organization is more exposed, or less, than it was ninety days ago, and activity metrics were never built to answer that. The following three matter now:
Time to Validate: How quickly can you confirm a vulnerability is truly exploitable?
Time to Validate is the clock on turning a raw report into a confirmed threat, the time it takes a team to separate a genuine exploit from noise.
This is typically measured as: Sum of all validation times (submission → exploit confirmed) ÷ total number of vulnerabilities validated in the period
AI has flooded that front door with volume, so validation now needs AI working the other side of the equation too, triaging fast enough that a real finding never sits unconfirmed while an attacker who needs no lead time is already closing in. A slow Time to Validate leaves real findings unconfirmed, and exposed, for as long as the delay lasts.
Total Exposure Backlog: What is the volume and age of your unresolved, valid, exploitable vulnerabilities?
Total Exposure Backlog is the weight sitting on the organization right now, the volume and age of every validated, exploitable vulnerability still unresolved.
This is typically measured as: Total validated vulnerabilities opened in the period − total vulnerabilities resolved in the period + prior period's unresolved balance
This is the number that is supposed to shrink, and boards are right to press on it as AI reshapes what application security programs have to account for. A backlog that holds steady while individual tickets close usually means new risk is arriving faster than old risk is leaving.
Mean Time to Remediate (MTTR): How fast are you closing exploitable vulnerabilities?
Mean Time to Remediate (MTTR) is the pace of the fix itself, and it is where the mismatch is starkest: most programs still measure MTTR in months, while the exploitation window it is racing against is now measured in hours. That gap is the risk a board actually needs to see.
This is typically measured as: Sum of all remediation times (submission → resolution) ÷ total number of vulnerabilities remediated in the period
Read together, these three numbers demonstrate how fast a team tells real threats from false alarms, how much confirmed danger is currently unresolved, and how quickly that danger gets shut down.
The Language Shifts With the Exposure Metrics
As the metrics change, so do conversations with the board and security teams charged with addressing modern problems. A shift is needed in how program leaders convey these changes using the following concepts:
“Exposure is a time problem.” | The longer a confirmed vulnerability stays open, the more attractive a target it becomes, especially now that attackers use their own AI to weaponize disclosures quickly. In 2025, the average gap between discovery and exploitation was roughly thirty-two days. This year, that gap has shrunk to hours, about thirty times faster, which means the job now is closing exposures before that window closes on the defender instead. |
“We prioritize validated exposures, not theoretical findings.” | Treating every submission as equally urgent is how teams end up burning their best hours chasing noise, so validating first, before a single remediation dollar gets spent, is what keeps a team's attention on the exposures that could actually hurt the organization. |
“We measure how long exploitable issues stay open.” | If exposure really is a time problem, this is the number that proves it, since a rising average means risk is compounding by the day whether or not any single finding looks dramatic on its own. |
Three Program Changes That Actually Shift the Numbers
Reporting these three numbers only matters if a CTEM program can actually shift them, and three changes tend to make that possible.
- The first is validating before mobilizing. AI has widened the front door on vulnerability submissions across every category of software, and no team is triaging that volume by hand anymore, so automating validation, and letting AI take the first pass at sorting signal from noise, is what keeps Time to Validate from becoming the new bottleneck.
- The second is cutting the handoffs. The strongest defense against AI-accelerated threats runs AI-assisted prioritization straight into engineering with no manual relay in between, because every handoff between security and engineering is a place where MTTR quietly gets worse, and removing them is how it improves.
- The third is closing the loop: fixing the issue, verifying the fix actually worked, and looking for the underlying pattern that let it happen in the first place. A single well-aimed architectural fix can sometimes retire dozens of related vulnerabilities at once, which is exactly where automated analysis pays for itself fastest.
Continuous Security Requires a Connected Platform
None of these three metrics move on their own. A CTEM program needs infrastructure behind it.
The H1 Platform runs discovery, validation, prioritization, and remediation through Hai, HackerOne's agentic AI orchestrator, working alongside a global community of security researchers to eliminate exploitable risk continuously, so the findings a CISO reports are confirmed and the fixes behind them are real.
Take a deeper dive with The New Metrics That Matter: How to Brief Your Board guide
1. Closing the AI Security Gap: Containing Risk Before It Scales
Survey methodology: HackerOne surveyed 303 security leaders between January and February 2026. Respondents were screened to ensure they oversee or contribute to tracking, managing, or testing their organization’s AI/ML systems, and represent a range of senior security and offensive security roles within organizations reporting $250 million or more in revenue across the United States, Canada, the United Kingdom, Australia, Singapore, and Germany. Respondents represented multiple industries, led by Technology Hardware/Software (37%) and Banking/Financial Services/Insurance (16%), with additional representation across manufacturing, healthcare, retail/e-commerce, and other sectors.
