{"id":232,"date":"2026-03-11T15:11:01","date_gmt":"2026-03-11T15:11:01","guid":{"rendered":"https:\/\/thedigitalfortress.us\/?p=232"},"modified":"2026-03-11T15:11:01","modified_gmt":"2026-03-11T15:11:01","slug":"what-boards-must-demand-in-the-age-of-ai-automated-exploitation","status":"publish","type":"post","link":"https:\/\/thedigitalfortress.us\/?p=232","title":{"rendered":"What Boards Must Demand in the Age of AI-Automated Exploitation"},"content":{"rendered":"
\n
<\/a><\/div>\n

\u201cYou knew, and you could have acted. Why didn\u2019t you?\u201d\u00a0<\/p>\n

This is the question you do not want to be asked. And increasingly, it\u2019s the question leaders are forced to answer after an incident.<\/p>\n

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

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: \u201cIf it was really as bad as you say, we\u2019d be compromised right now.\u201d<\/p>\n

That world is gone.<\/p>\n

AI has collapsed the cost of exploitation<\/strong><\/h2>\n

We\u2019re 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<\/a> 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.\u00a0<\/p>\n

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. \u201cWe\u2019re working the backlog\u201d stops sounding like a strategy and starts sounding like an excuse.<\/p>\n

<\/p>\n

The most dangerous sentence in the boardroom<\/strong><\/h2>\n

\u201cDon\u2019t worry, the CISO has it handled.\u201d<\/p>\n

I\u2019ve 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\u2019s responsibility. It\u2019s a system problem: legacy dependencies, release velocity constraints, fragile production environments, and limited engineering resources. Boards can\u2019t delegate governance.<\/p>\n

Delaware\u2019s Caremark line of cases<\/a> 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\u2019t to scare directors with legal theory \u2013 it\u2019s to make the practical governance point that if your reporting says \u201cwe have thousands of serious vulnerabilities open,\u201d the board\u2019s job is to exercise oversight.<\/p>\n

What boards should demand (and how CISOs should answer)<\/strong><\/h2>\n

If you\u2019re a board member, you should seek operational truth. Focus on the resiliency of your company\u2019s tech, not just compliance. And if you\u2019re 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:<\/p>\n

    \n
  1. What does our vulnerability management program look like end-to-end?<\/strong><\/li>\n
  2. How many vulnerabilities (especially Criticals and Highs) exist in our products right now?<\/strong><\/li>\n
  3. How long did it take to fully remediate new Criticals and Highs in the past quarter? The past year?<\/strong><\/li>\n
  4. 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?<\/strong><\/li>\n
  5. What is the dollar cost of our current vulnerability backlog? <\/strong>(Multiply people-hours to fix by fully loaded engineering cost, and you get a number the board can govern.)<\/li>\n<\/ol>\n

    This is how you make the backlog tangible enough that leadership stops hiding behind abstractions.<\/p>\n

    \u201cPatch faster\u201d is not a complete answer<\/strong><\/h2>\n

    Many organizations respond to board pressure by promising to patch faster. That helps, until it breaks production.<\/p>\n

    If emergency patching reliably causes customer impact (and in some environments it does), you\u2019re 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.<\/p>\n

    The supply chain reality: liabilities are shifting<\/strong><\/h2>\n

    We\u2019re seeing liabilities shift as regulators and courts focus on software supply chain hygiene and operational resilience.\u00a0<\/p>\n

    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.<\/p>\n

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

    We\u2019re 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.<\/p>\n

    You can reduce the backlog by design<\/strong><\/h2>\n

    In the age of AI-accelerated exploitation, \u201cmanaged risk\u201d too often means assuming attackers will keep moving at yesterday\u2019s pace.<\/p>\n

    Boards should stop accepting that assumption. CISOs should stop pretending \u201cpatch faster\u201d or getting a risk acceptance is sufficient. And organizations should invest in reducing vulnerability exposure at the source so the next audit report isn\u2019t a spreadsheet of accepted risks, but evidence of a shrinking attack surface.<\/p>\n

    Shameless plug, this is where Chainguard\u2019s 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.<\/p>\n

    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.<\/p>\n

    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\u2019t. We changed the system.<\/p>\n

    For more hot takes and practical advice from \u2013 and for \u2013 engineering and security leaders, subscribe to Unchained<\/a> or reach out<\/a> to learn more about Chainguard.\u00a0<\/em><\/p>\n

    Note: <\/strong>This article was expertly written and contributed byQuincy Castro, CISO, Chainguard.<\/em><\/p>\n

    Found this article interesting? This article is a contributed piece from one of our valued partners.<\/span> Follow us on Google News<\/a>, Twitter<\/a> and LinkedIn<\/a> to read more exclusive content we post.<\/div>\n<\/div>\n