How CISOs Should Prioritize Security Debt

A security backlog that only ever grows is not a backlog. It is a record of decisions nobody made on purpose. Security debt is the cleanest name for it, and prioritizing it well starts with accepting that you will not clear it.

Veracode’s latest State of Software Security report, produced with the Cyentia Institute, defines security debt narrowly: known vulnerabilities left unresolved for more than a year. On that definition, 82% of the organizations in its dataset carry some, and 60% carry critical debt, meaning long-lived, high-severity flaws. Third-party and open-source components account for 66% of the critical debt. The median organization fixes roughly 10% of its vulnerability backlog each month, and the half-life for fixing third-party flaws is 358 days.

Treat those numbers as a picture of one slice of the problem. They come from application scanning on one vendor’s platform, across 1.6 million applications. They say nothing about the unsupported operating system in the plant network, the standing admin rights nobody has reviewed, or the logging gap in the finance system. A CISO’s debt is wider than a scan report.

Define debt as a decision, not a finding

A working definition: security debt is any known weakness the organization has chosen, or defaulted into, not fixing. The “defaulted into” part matters most. Most debt is never formally accepted. It ages because fixing it competes with product delivery and loses.

That framing changes the job. Vulnerability counts tell you how much debt exists. They do not tell you which items are dangerous, which are cheap to retire, or which someone should consciously decide to live with. The CISO’s work is to turn silent defaults into explicit decisions, and to order them.

Four questions that sort debt

Most prioritization schemes fail because they rank on one axis, usually severity. Severity alone puts a critical flaw on an isolated test server above a medium flaw on an internet-facing system that sits in front of customer data. Ask four questions instead, in this order.

1. Is it being exploited now? CISA’s Known Exploited Vulnerabilities catalog lists flaws with evidence of active exploitation. CISA urges all organizations, not only US federal agencies, to build timely remediation of those entries into their vulnerability management practice. An item on that list moves to the front, whatever its score.

2. Can an attacker reach it? Exposure beats everything else when it is real. An internet-facing system, a flaw reachable from a contractor network, or an identity that can be used from outside all raise the ranking. Internal-only debt with strong segmentation can wait longer.

3. What does it sit in front of? This is the question scoring tools answer worst. A medium-rated weakness in an identity provider, a build pipeline or a backup system can expose far more than a critical one in a low-value application. Rank by what the weakness gives access to. Your crown-jewel list is the input here.

4. What does it cost to carry versus to fix? Some debt is cheap to retire and removes a lot of risk. Some is expensive and removes little. Do the cheap, high-value work first. Put the expensive, low-value work in front of a named executive for an explicit decision.

The Exploit Prediction Scoring System (EPSS), maintained by FIRST, can help with the first question. It estimates the probability that a published vulnerability will be exploited in the wild within 30 days. It measures likelihood only. It says nothing about impact, so it cannot answer the third question for you.

Why the arithmetic works against you

If a typical organization clears about a tenth of its backlog each month, the backlog only shrinks when new debt arrives more slowly than old debt is retired. In many engineering organizations it does not. New services ship with new dependencies, and every dependency has a future.

So the first control is not a clean-up campaign. It is a rule at the point of entry: what level of known weakness is allowed to ship, and who can overrule that. Without an entry rule, the best remediation program in the world is bailing a boat with the tap still running.

What to put in front of the board

Boards do not need a vulnerability count. They need three things: how much critical debt sits on systems that matter, how old it is, and whether the trend is improving. NIST’s Cybersecurity Framework 2.0 places risk management strategy, including risk appetite, inside its Govern function. Debt is where that strategy meets reality. If the board has agreed an appetite for risk and the debt report contradicts it, someone has to decide which one changes.

• Age of critical debt on crown-jewel systems. Age exposes neglect that a count hides.

• Known-exploited items open beyond the agreed deadline. This should be close to zero, and every exception should have a name on it.

• Net debt movement. Debt retired minus debt created over the period. This is the number that shows whether you are winning.

• Accepted debt, with owners and expiry dates. If acceptance never expires, it is not acceptance. It is neglect with paperwork.

Decisions to make this quarter

5. Agree with the CTO a fixed share of engineering capacity for debt retirement, so remediation is not renegotiated every sprint.

6. Set an entry rule for new debt and name who can approve exceptions.

7. Assign every debt class in the table above to an accountable owner, not a team alias.

8. Put an expiry date on every risk acceptance and review them as a set, not one at a time.

9. Choose the ranking method and publish it, so engineers can predict what will be escalated.

Veracode’s report offers triage protocols aimed at cutting critical debt by 25% within 180 days. That is a vendor’s target, not a measured result, and your results will vary with your estate. It is still a useful size of ambition. Cutting critical debt in half is rarely realistic in a quarter. Retiring the portion that is exploited, reachable and close to your crown jewels usually is.

Sources

• Veracode and the Cyentia Institute, State of Software Security (latest edition): definition of security debt, prevalence of critical debt, third-party share, remediation half-life and median fix rate. veracode.com

• CISA, Known Exploited Vulnerabilities Catalog and Binding Operational Directive 22-01: evidence-based list of actively exploited vulnerabilities and CISA’s recommendation that all organizations prioritize them. cisa.gov

• FIRST, Exploit Prediction Scoring System (EPSS): probability of exploitation within 30 days. first.org

• NIST, The NIST Cybersecurity Framework (CSF) 2.0, NIST CSWP 29: Govern function and risk management strategy. nvlpubs.nist.gov