Program Building Exposure Debt

Exposure debt is the risk your backlog does not count

July 28, 2026·10 min read·Chris Boker, Founder, CVEasy AI
An open ledger book with five stacked green rows on the left labeled by icon shape for known vulnerabilities, expired exceptions, unknown assets, untested detections, and broken sensor coverage, a mint principal circle and a gold interest circle joined by a curving green arrow on the right, and a small green closed-loop repayment ring beneath

Two dashboards, same room. The vulnerability backlog on the wall is trending down for the third quarter running, which the program manager rightly puts in the deck, while the environment the team actually defends is quietly getting harder to defend. That gap lives in a set of numbers the wall dashboard was never built to hold: temporary firewall rules that outlived their ticket, exceptions that expired without a renewal, a segment nobody has scanned in months because a credential broke, and a detection rule disabled during tuning and never re-enabled. None of it shows up on the wall until it becomes the incident.

There is already a name for the shape of this problem. What has been missing is a way to keep it on one page.

The community already put most of the pieces down

Ward Cunningham coined technical debt in his 1992 OOPSLA experience report on the WyCash portfolio management system, framing shipped code that misaligns with proper understanding as debt that carries interest until repaid (Agile Alliance). Martin Fowler later formalized principal and interest as the canonical decomposition of that metaphor (martinfowler.com), and the security branch of the metaphor has been in circulation for years.

Veracode has done the most work on the software side. Their 2026 State of Software Security defines security debt as flaws left unresolved for over a year and reports that 82% of organizations now carry it, up from 74% the prior year, with 60% carrying debt classified as critical (Veracode). Nucleus Security has extended the same idea into vulnerability management, mapping how backlog age compounds into program risk (Nucleus). Arctic Security frames security debt as the accumulated cost of postponed measures (Arctic Security). A recent qualitative study of 22 practitioners codified how software teams perceive security debt in code and design settings, and is honest that its scope stops there (Boufaied, Ghaleb, Masood, 2025).

The exact phrase exposure debt is not new either. Jonathan Risto used it in an August 2025 post to describe the backlog of vulnerabilities, misconfigurations, and risky conditions that sit because they are not urgent enough to fix today (Risto, LinkedIn). Any post that pretends to coin the term is not being honest about the record. What still deserves to be written is the unified ledger and the accrual mechanic, because those are the parts practitioners keep asking for and no published work has put in one place.

Where the ledger stops today

Each piece of the prior art sits in its own silo. Veracode measures application flaws while Nucleus watches the vulnerability backlog age. Detection engineers argue about "detection debt" inside their own rule sets, and cloud teams talk about misconfiguration debt while identity teams talk about privilege debt, and none of those numbers ever meets the others in a single view. A CISO who wants that single view of what the environment owes the attacker has to reconcile five spreadsheets and one Confluence page nobody has opened since the last audit.

The arXiv paper and the Veracode report are both explicit that their scope stops at code, design, and applications. The gap those authors keep pointing at is the exposure-wide extension, and that is the ground worth staking.

A single ledger for exposure

Everything an environment owes the attacker belongs on one ledger, whether it is a code flaw, a stale scanner credential, an ownerless service, an expired exception, or a segment nobody has validated in a quarter. Five entries a program already tracks separately turn out to be entries in the same book.

Known vulnerabilities past a policy age. The Veracode definition, extended to any finding source the program feeds from, with age as the qualifier that turns a finding into a ledger entry and a written policy as what makes the qualifier defensible.

Exceptions past their expiration. Every exception is a debt instrument with a principal, a rate, and a maturity date. An exception whose maturity date has passed is a defaulted note, not a paragraph in a policy binder, and treating it that way turns the risk register into a live ledger with dates that mean something.

Unknown assets. These are unbooked liabilities. You cannot count what you do not see, so this debt shows up not as a line item but as a discount on every other line, since ownerless workloads carry the same weight as owned ones once an attacker reaches them.

Untested detections. A rule that has not fired against an adversary technique in ninety days is not a control, it is a claim about a control, and the gap between claim and evidence is where breach reports get written.

Broken sensor coverage. A scanner credential that expired six weeks ago is silently deferring every finding that scanner would have surfaced, and the interest is paid in the incident postmortem.

Put the five together and the ledger becomes readable in a way a backlog never will be, because it counts what the backlog assumes.

Principal and interest, extended

Fowler's principal and interest translate cleanly onto that ledger. Principal is the risk condition itself. Interest is the compounding cost of leaving it: more dependent systems built on top of it, more exceptions written around it, more emergency work when it inevitably surfaces, more fear around changes near it. The prior-art authors agree the interest side has not been quantified, which is exactly why the shape of it is worth writing down.

Interest on exposure debt compounds through three visible channels.

Coupling. Every system built on top of an unresolved condition tightens the coupling, so the eventual fix has to cross more callsites and more pinned versions, and the upgrade cost scales with those downstream commits rather than with the size of the original patch.

Exception drift. Compensating controls written around unpatched systems become their own infrastructure, so two exceptions become a policy while ten become a shadow program running in parallel to the real one, itself untested and owned by nobody in particular.

Response cost. Findings that sit long enough eventually surface as incidents, and by the postmortem the interest is measured in weekend hours rather than remediation tickets, paid on a principal that was booked months before the pager went off.

Each of these channels shows up in the same postmortems, quarter after quarter, and each is measurable when the ledger is honest about entries the backlog omits.

Reading the ledger without one magic number

Do not compress this into a single score. The moment you do, someone will optimize it and the ledger will start lying the same way the backlog does. Signals that survive gaming are the ones tied to real conditions:

  • The rate at which new assets appear before ownership is assigned.
  • Expired exceptions still relied on for compensating protection.
  • Findings closed that reopen inside a scan cycle.
  • Ownerless findings older than a policy threshold.
  • Percentage of critical assets not covered by a working scanner credential.
  • Detections not validated inside the last quarter.
  • Internet-facing services not represented in the asset inventory.

The trend on each of those is more useful than a single number ever will be, and no reasonable optimizer chases seven trends at once.

Not all debt is a mistake

Some debt is rational. A hospital defers a patch on a clinical system because the vendor requires a maintenance window that affects patient care. An OT operator uses compensating controls because a plant outage carries a cost the patch does not justify by itself. The problem was never debt, it was the way debt gets carried.

Managed debt has an owner, a reason, a compensating control, an expiration date, and a validation record. Unmanaged debt has a dashboard note and a wish. Everything in the middle is a spectrum a program can walk toward the first shape and away from the second, one expiration date and one owner at a time.

Paying it down

Repayment is engineering work and belongs on an engineering plan. Kill dead assets, expire old exceptions, close owner gaps, remove public exposure, patch the systems whose blast radius is worst, and validate the detections you claim to run. The best debt payments reduce future work, not just current findings, so every unowned service that gets an owner cuts the interest rate on every future finding against it. The backlog cannot see that kind of repayment, and the ledger can.

Where this fits in the program

A ledger like this is what turns Continuous Threat Exposure Management from a five-stage slide into a program a team can run every week, and TRIS is the layer that weights any given entry against reachability, active exploitation, and consequence. The blog is called I am the vulnerability for a reason: the vulnerability was never a CVE number, it was the accumulated conditions the environment stopped counting. Formalizing exposure debt is what turns a backlog trending down on a slide into a program that trends down where the attacker actually lives.

Related Reading