Finding bugs is easy, but fixing them is the real bottleneck — here is how to convince your board to fund your security cleanup.
Security leaders have made strong progress in visibility. Most organizations can now identify vulnerabilities across their applications, dependencies and development pipelines with far more consistency than in the past. Yet a fundamental imbalance remains: Vulnerabilities are being discovered faster than they can be remediated.
That imbalance is growing. Today, 82% of organizations carry security debt, defined as accumulated vulnerabilities that have remained unresolved for more than a year. At the same time, the share of vulnerabilities defined as both “severe” and “likely to be exploited” continues to increase.
This combination has real consequences. Vulnerabilities are not just accumulating; they persist in production environments long enough to be discovered and used.
Among my fellow CISOs, the conversation has shifted. The challenge now is to translate this reality into a business case that resonates with executive leadership and drives investment in remediation capacity. Here are six ways to do this.
Treat security debt like financial debt
Security debt behaves much like financial debt. It accumulates over time, compounds when left unmanaged and creates ongoing costs for the business. Those costs show up in delayed releases, emergency remediation efforts, audit findings and incident response.
Managing it effectively requires the same discipline applied to financial risk. That means measuring total and critical debt, setting reduction targets and tracking progress over time. It also means distinguishing between acceptable and unacceptable levels of risk, rather than treating all vulnerabilities as equal.
I believe security debt should be visible at the executive level. Leadership teams routinely track financial performance, operational resilience and service reliability. Security debt belongs in the same category. It reflects the organization’s exposure and its ability to manage that exposure over time.
Frame remediation capacity as a business constraint
Most organizations have a strong awareness of vulnerabilities. The limiting factor is the ability to address them.
Remediation capacity determines whether security debt grows or shrinks. When the volume of new findings exceeds the organization’s ability to fix them, the backlog expands and exposure increases. This dynamic persists regardless of how effective detection tools are.
In my experience, it’s important to quantify this constraint. That includes showing the gap between findings and fixes, identifying where high-risk vulnerabilities remain open and demonstrating how long they persist. These data points make it clear that incremental efficiency improvements will not close the gap on their own.
Presenting remediation capacity in operational terms helps align the discussion with executive priorities. Leaders understand constraints in engineering throughput, cloud spend and service availability. Remediation capacity should be treated in the same way.
Focus on exploitable risk in critical systems
Security debt becomes meaningful when it is tied to business impact.
Not all vulnerabilities carry the same level of risk. The ones that matter most share two characteristics. They are likely to be exploited, and they exist in applications that are important to the business.
Traditional severity scoring does not fully capture this. The Common Vulnerability Scoring System (CVSS) remains useful. Still, it does not reflect whether a vulnerability is reachable, whether it sits in a critical system or whether exploit techniques are readily available.
A practical approach is to layer exploitability and business context onto existing scoring models. This creates a focused set of high-risk vulnerabilities that require immediate attention. In many environments, this represents a relatively small percentage of total findings, but it accounts for a large portion of potential impact.
By concentrating on this subset, organizations can direct resources where they have the greatest effect. This approach also makes it easier to communicate risks in business terms.
Prioritize crown-jewel applications
Risk is not distributed evenly across applications.
Every organization has systems that are more critical than others. These may include customer-facing platforms, revenue-generating services or applications that process sensitive data. Compromise in these areas has a disproportionate impact on the business.
Focusing remediation efforts on these crown-jewel applications improves outcomes quickly. Our research found that 11.3% of flaws have high severity and high exploitability. It ensures that the most important systems receive the highest level of protection and reduces the likelihood of high-impact incidents.
Clear targets help reinforce this focus. Over a defined period, organizations can reduce critical security debt, shorten the lifespan of high-risk vulnerabilities and maintain strict thresholds for exposure in key systems. These targets translate security activity into business outcomes that leadership can understand and support.
Establish metrics that reflect risk
Metrics play a central role in shaping behavior.
Many organizations continue to rely on the number of vulnerabilities discovered or resolved. While these metrics provide useful context, they do not indicate whether risk is increasing or decreasing.
More effective measures focus on exposure. These include the number of critical or exploitable vulnerabilities in key systems, the average age of those vulnerabilities and trends over time. Together, these metrics provide a clearer picture of how risk is evolving.
Linking these measures to organizational objectives strengthens accountability. Security debt reduction can be incorporated into OKRs, with specific targets for reducing critical debt, lowering vulnerability age and maintaining acceptable thresholds in high-risk applications.
Formalizing risk acceptance is also important. High-risk vulnerabilities that remain open should require business approval and defined timelines. This ensures that risk is acknowledged and managed deliberately.
Increase investment in remediation capacity
Improving security outcomes requires sustained investment in the ability to act.
Remediation capacity can be expanded in several ways. Organizations can allocate dedicated engineering time for security work, integrate remediation into development workflows and adopt automation to reduce manual effort. AI-assisted fixes and automated guidance can help teams address vulnerabilities more efficiently without disrupting development velocity.
Preventing new security debt is equally important. Policies such as requiring high-risk vulnerabilities to be resolved before release help limit the introduction of additional exposure. Over time, this reduces the overall burden on remediation teams.
These changes do not slow innovation. They create conditions for delivering software safely and consistently.
Align the business around risk reduction
Security debt affects more than the security function. It influences resilience, regulatory posture and the organization’s ability to deliver software with confidence.
CISOs play a central role in aligning stakeholders around this issue. By framing security debt in terms of business impact, capacity constraints and measurable outcomes, they can shift the conversation from technical backlog management to enterprise risk reduction.
This alignment is critical for securing investment. When leadership understands the relationship between remediation capacity and business risk, decisions about funding, prioritization and trade-offs become clearer.
Security debt will continue to exist. What matters is how effectively it is managed and measured. For example, a good target should be doubling fix capacity through tooling investment, not just headcount.
Organizations that measure, govern and actively invest in reducing it are better positioned to control risk at scale. Those that do not will continue to see exposure grow, even as their visibility improves.
This article is published as part of the Foundry Expert Contributor Network.
Want to join?