The board question is not the CVE count

What it says#

The piece starts from Anthropic's April 2026 preview of Claude Mythos, a model presented as able to find and exploit software vulnerabilities on its own. Anthropic's own account lists a 27-year-old bug in OpenBSD's TCP SACK handling and a 16-year-old vulnerability in FFmpeg's H.264 codec ¹. It also lists a 17-year-old remote code execution flaw in FreeBSD's NFS service, tracked as CVE-2026-4747 ¹. If the pattern holds, Anthropic adds, there would be over a thousand more critical vulnerabilities and thousands more of high severity ¹. The model went first to Project Glasswing, a group of twelve organisations that includes AWS, Apple, Google, Microsoft, the Linux Foundation and Anthropic itself ². The stated aim is to secure critical software before such capability spreads ².

From there the article makes three moves. First, the old rhythm of scan, score, rank and patch to a service level cannot keep up when discovery is automated. A severity score says nothing about whether a flaw is reachable in a given environment. Second, the intrusions that mattered most in the last decade did not arrive through a scored vulnerability. It recounts a trusted software update, a two-year social-engineering campaign against one maintainer, a developer's personal computer and a ten-minute phone call to a help desk. Cleaner vendor code, it argues, pushes attackers further towards identity, trust and people, and adds a new unscored surface of shadow AI integrations, over-permissioned tokens and agents with write access.

Third, the board conversation should change. The article proposes three questions.

• What would the business impact be if the three most critical systems were breached through stolen credentials or a misconfigured AI integration rather than a CVE?
• How many of the AI tools in use have been through a security review, and what permissions do they hold?
• How many suppliers sit outside the twelve Glasswing members, and would a tampered update from one of them be detected?

What we take from it#

The three questions are good, and they are good because each one produces evidence rather than reassurance. A modelled attack path to a named asset, a reviewed inventory of AI tools with their permissions, and a tested detection for a bad supplier update are all evidence. A board can ask to see each of them again next quarter. A patch completion percentage is not.

The reporting language matters for the same reason. "We are working the CVE backlog" describes activity. "This path from a stolen token to the payments platform is open today, and here is what it would cost" describes a decision the board can take. Our risk-register method asks for the second form on every row: a named owner, a treatment decision and a date. Board reporting is that register, filtered.

We also agree that identity has become the load-bearing control. An agent or an integration with write access is a privileged account by another name, and the question of who approved its permissions belongs in the same review as any other privileged access.

Where we would push back#

This is a vendor's article, written by a company that sells exposure management, and its slogans about eliminating assumptions and blind spots are product copy. The argument does not depend on the product, but the reader should know where the "how" goes quiet.

The piece also discounts vulnerabilities further than the evidence allows. The claim that only a small share of a year's CVEs is exploited cuts both ways once a capable discovery model is widely available. The unexploited majority is a stock of future weapons, and automated discovery shortens the time to use them. The right conclusion is not that CVEs matter less. It is that exploitability in context has to be measured, which is what the article's own first question asks for.

Finally, the "attackers go for people" observation is old. Phishing and social engineering have led incident statistics for years. The article restates it under a new headline without offering a new control for identity in an agent-heavy environment. That control layer exists, and a regulator has now written it down; see the companion note on agent governance.

Related on GRCIDE#

• The risk register other people trust, on decisions per row rather than lists.
• Agent governance is a permissions problem before it is a model problem, the companion note.
• Building an ISMS people actually use, section 3.5, on an operating rhythm that produces board evidence.