Strategy
Exposure debt: why finding fast and fixing slow is the real risk
A validated vulnerability that stays open is a liability you already know about. Here is how to measure it and pay it down.
Most security programs report on discovery: how many findings came in this quarter, how many were critical, how quickly they were triaged. Those numbers matter, but they describe the input to the problem, not the problem itself. An attacker does not care how fast you found a flaw. They care whether it is still there.
What exposure debt is
Exposure debt is the total of every validated, still-open vulnerability, weighted by how severe it is and how long it has been open. A single critical issue open for sixty days carries more debt than ten low-severity issues opened yesterday. The idea borrows from technical debt: the longer you leave it, the more it costs, and the cost is paid at a time you do not choose.
Why discovery metrics hide it
A team can triple its finding rate and still become less secure if remediation does not keep pace. Every new validated report adds to the balance. When findings sit in a backlog, the organisation has documented proof of a weakness and no fix — the worst possible position in an incident review or an audit.
How to measure it
Start with a remediation target for each severity level. Common starting points are days for critical issues, a few weeks for high, and a quarter for medium, but the right numbers depend on your release cadence and risk appetite. Then track three things every week: open findings by severity, the age of each one, and the number that have passed their target.
Assign every finding to an owning team, not a person. People change roles; services keep owners. Reporting overdue findings by team turns a security metric into an engineering conversation, which is where the fix actually happens.
How to pay it down
Fix the oldest critical and high issues first — they carry the most debt. Look for clusters: ten findings in one service usually point to one missing control, such as a shared authorisation check. Fixing the root cause clears several items at once and stops new ones arriving.
Finally, retest every fix. A finding is only closed when someone has confirmed the original attack no longer works. Closing on a developer's word, without retesting, quietly moves debt off the books without paying it.