What Boards Must Demand in the Age of AI-Automated Exploitation

“You knew, and you could have acted. Why didn’t you?”

This is the question you do not want to be asked. And increasingly, it’s the question leaders are forced to answer after an incident.

For years, many executive teams and boards have treated a large vulnerability backlog as an uncomfortable but tolerable fact of life: “we’ve accepted the risk.” If you’ve ever seen a report showing thousands (or tens of thousands) of open Highs and Critical CVEs, you’ve probably also heard the usual rationalizations from folks that would rather look the other way: we have other priorities, this will take years of engineering time to fix, how do you know these are really Critical, we’re still prioritizing, we’ll get to it.

In the old world, that story, while not good, was often survivable. Exploitation was slower, more manual, and required more operator skill. Even the most sophisticated attackers had constraints. Organizations leaned on those constraints as an unspoken part of the risk model: “If it was really as bad as you say, we’d be compromised right now.”

That world is gone.

AI has collapsed the cost of exploitation

We’re now watching threat actors use agentic AI systems to accelerate the entire offensive workflow: reconnaissance, vulnerability discovery, exploit development, and operational tempo. Anthropic publicly detailed disrupting a cyber-espionage campaign in which attackers used Claude in ways that materially increased their speed and scale, and they explicitly warned that this kind of capability can allow less experienced groups to do work that previously required far more skill and staffing.

As security leaders, we know that AI enables attackers to move faster. But now, automation turns a backlog into a weapon. In the old model, having 13,000 Highs in production could be rationalized as a triage problem. In the new model, attackers can move from chain discovery to validation and exploitation in dramatically less time. “We’re working the backlog” stops sounding like a strategy and starts sounding like an excuse.

The most dangerous sentence in the boardroom

“Don’t worry, the CISO has it handled.”

I’ve lived the reality behind that sentence. CISOs can build programs, establish priorities, report metrics, and drive cross-functional remediation, but in many enterprises, the vulnerability problem is structurally bigger than any one executive’s responsibility. It’s a system problem: legacy dependencies, release velocity constraints, fragile production environments, and limited engineering resources. Boards can’t delegate governance.

Delaware’s Caremark line of cases is frequently cited in director oversight discussions: boards must have reporting systems designed to surface consequential risk and must actually engage with what those systems report. The point isn’t to scare directors with legal theory – it’s to make the practical governance point that if your reporting says “we have thousands of serious vulnerabilities open,” the board’s job is to exercise oversight.

What boards should demand (and how CISOs should answer)

If you’re a board member, you should seek operational truth. Focus on the resiliency of your company’s tech, not just compliance. And if you’re a security leader, you should be creating the operating systems that provide it. These are the questions teams can use that cut through performative cybersecurity:

What does our vulnerability management program look like end-to-end?****How many vulnerabilities (especially Criticals and Highs) exist in our products right now?****How long did it take to fully remediate new Criticals and Highs in the past quarter? The past year?****If a new 0-day was discovered in our top-selling product today, how long would it take before we could tell customers it was safe?****What is the dollar cost of our current vulnerability backlog?(Multiply people-hours to fix by fully loaded engineering cost, and you get a number the board can govern.)

This is how you make the backlog tangible enough that leadership stops hiding behind abstractions.

“Patch faster” is not a complete answer

Many organizations respond to board pressure by promising to patch faster. That helps, until it breaks production.

If emergency patching reliably causes customer impact (and in some environments it does), you’re forced into a terrible tradeoff: accept exposure or accept downtime. The modern enterprise needs a model that reduces the frequency and blast radius of emergency remediation, not one that merely accelerates the same fragile process.

The supply chain reality: liabilities are shifting

We’re seeing liabilities shift as regulators and courts focus on software supply chain hygiene and operational resilience.

In the EU, the Cyber Resilience Act (CRA) is now in force, with its main obligations taking effect in December 2027. Many organizations will face stronger expectations for vulnerability handling, secure-by-design practices, and accountability throughout the software lifecycle.

In financial services, DORA (Digital Operational Resilience Act) has entered into application, bringing harmonized ICT risk management and operational resilience requirements across the EU.

We’re also seeing this dynamic play out in the US, where negligence claims are brought in class action lawsuits against firms, with plaintiffs alleging a lack of due care that led to data breaches.

You can reduce the backlog by design

In the age of AI-accelerated exploitation, “managed risk” too often means assuming attackers will keep moving at yesterday’s pace.

Boards should stop accepting that assumption. CISOs should stop pretending “patch faster” or getting a risk acceptance is sufficient. And organizations should invest in reducing vulnerability exposure at the source so the next audit report isn’t a spreadsheet of accepted risks, but evidence of a shrinking attack surface.

Shameless plug, this is where Chainguard’s approach is designed to change the math: start with secure-by-default software components that minimize vulnerabilities from the outset and reduce vulnerability accrual over time. That means fewer critical findings landing in your environment, fewer emergency patch cycles, and less operational disruption when the next high-profile CVE hits.

By structurally reducing vulnerability backlog and remediation toil, teams can redirect engineering time from zero-ROI firefighting into high-ROI innovation that actually drives competitive advantage and revenue.

Because when the finger-pointing starts after the breach, and someone asks why the company chose to live with 13,000 Highs in production, the only defensible answer is: we didn’t. We changed the system.

*For more hot takes and practical advice from – and for – engineering and security leaders, subscribe to Unchained or reach out to learn more about Chainguard. *

**Note: **This article was expertly written and contributed byQuincy Castro, CISO, Chainguard.