“You knew and you could have acted, so why didn’t you act?”
This is the question you don’t want to be asked. And in the aftermath of an incident, leaders are faced with an increasing number of questions to answer.
For years, many executives and boards have treated large vulnerability backlogs as an unpleasant but acceptable reality: “We accept the risk.” If you’ve seen reports showing thousands (or tens of thousands) of open highs and critical CVEs, you’ve probably also heard the common justifications from those who turn a blind eye. “We have other priorities, it’s going to take years of engineering to fix this, how do we know these are really critical, we’re still prioritizing, we’ll get to it.”
In the old world, such stories often managed to survive, although not well. Exploitation was slower, more manual, and required more operator skill. Even the most sophisticated attackers had their limitations. Organizations relied on these constraints as an implicit part of their risk models. “If it really was as bad as you say, we’d be in danger right now.”
That world is gone.
AI development costs have collapsed
We are now seeing threat actors use agent AI systems to accelerate the entire attack workflow, including reconnaissance, vulnerability discovery, exploit development, and operational tempo. Anthropic has detailed how attackers used Claude to thwart cyberespionage operations in a way that significantly increased their speed and scale, explicitly warning that this type of capability could allow inexperienced groups to perform tasks that previously required far more skill and personnel.
As security leaders, we know that AI allows attackers to act faster. But now, automation turns backlogs into weapons. In the old model, having 13,000 Highs in production could be rationalized as a triage issue. The new model allows attackers to discover, verify, and exploit chains dramatically faster. “We’re working on a backlog” starts to sound less like a strategy and more like an excuse.
The most dangerous verdict in the boardroom
“Don’t worry. The CISO will take care of it.”
I have lived the reality behind those words. CISOs can build programs, establish priorities, report metrics, and drive cross-functional remediation, but in many companies, vulnerability issues are structurally larger than the responsibility of a single executive. This is a system issue. Legacy dependencies, release velocity constraints, weak production environments, and limited engineering resources. The board cannot delegate governance.
The Delaware Caremark case series is frequently cited in discussions of director oversight. The board must have a reporting system designed to surface the resulting risks and must actually engage with what the system reports. The point is not to scare directors with legal theories. When a report says “thousands of significant vulnerabilities exist,” it’s a pragmatic governance case where the board’s job is to provide oversight.
What should boards ask for (and how should CISOs respond)?
If you are a board member, you need to seek operational truth. Focus not only on compliance, but also on the resiliency of your company’s technology. And if you’re a security leader, you need to create an operating system that provides that. Here are questions your team can use to break through performative cybersecurity.
What does our vulnerability management program look like end-to-end? How many vulnerabilities (particularly critical and high-level) currently exist in our products? How long did it take to fully remediate new critical and high-level ones in the past quarter? Over the past year? If a new zero-day is discovered in our current best-selling product, how long will it take to tell our customers that it is secure? What is the dollar cost of our current vulnerability backlog? (Multiplying all the man-hours and engineering costs to fix it will give you a number that your board can manage.)
This is how to make the backlog concrete enough for leadership to stop hiding behind abstractions.
“Apply patches faster” is not the complete answer
Many organizations are responding to board pressure by pledging to deliver patches more quickly. This is useful until the production environment is disrupted.
If applying an emergency patch does affect your customers (and it does, depending on your environment), you’ll be forced to make a terrible trade-off between accepting exposure and accepting downtime. Modern enterprises need a model that reduces the frequency and scope of emergency remediation, rather than one that merely accelerates the same fragile processes.
Supply chain reality: Debt is changing
We are seeing a shift in liability as regulators and courts focus on software supply chain health and operational resilience.
The EU currently has a Cyber Resilience Act (CRA) in place, with its main obligations coming into force in December 2027. Many organizations will face increased expectations for vulnerability handling, secure design practices, and accountability throughout the software lifecycle.
In financial services, DORA (Digital Operational Resilience Act) has been applied, introducing harmonized ICT risk management and operational resilience requirements across the EU.
This dynamic is also being seen in the United States, where class action lawsuits have brought negligence claims against companies, with plaintiffs alleging a lack of due diligence that led to data breaches.
Design can reduce backlog
In an era of accelerated AI exploitation, “managed risk” often means assuming that attackers will continue to move at yesterday’s pace.
Boards should stop accepting that assumption. CISOs should stop pretending to “patch faster” or insisting that accepting the risk is enough. And organizations need to invest in reducing vulnerability exposure at the source so that their next audit report is less a spreadsheet of accepted risks and more evidence of a reduced attack surface.
Shameless plug. This is where Chainguard’s approach is designed to change the calculation. Start with secure-by-default software components that minimize vulnerabilities from the beginning and reduce the number of vulnerabilities that arise over time. This means fewer critical discoveries impacting your environment, fewer emergency patch cycles, and fewer disruptions to operations when the next high-profile CVE occurs.
By structurally reducing vulnerability backlogs and remediation efforts, teams can redirect engineering time from zero-ROI firefighting to high-ROI innovations that actually drive competitive advantage and revenue.
Because when the backlash starts after the breach and someone asks why the company chose to keep the price high at 13,000 in production, the only defensible answer is: “They didn’t.” We have changed the system.
For featured opinions and practical advice from and for engineering and security leaders, subscribe to Unchained or learn more about Chainguard.
Note: This article was professionally written and contributed by Quincy Castro, CISO at Chainguard.
Source link
