Anthropic recently published a guide on — CrowdStrike fell 7%, Palo Alto Networks 6%, Tenable 9%, the iShares Cybersecurity ETF dropped 4.5%. The market's logic was the four-quadrant conflation in action: if AI finds vulnerabilities, cybersecurity companies are obsolete. But CrowdStrike does endpoint protection on live networks. Zscaler inspects live traffic through a Zero Trust Exchange. Rubrik does data resilience and recovery. None of them operate in Application × Code — the one quadrant Mythos actually covers. The market treated all of security as one quadrant, panicked, and then corrected: six weeks later, the same ETFs hit record highs as enterprises responded to the new threat by increasing security spend, not decreasing it. The selloff wasn't wrong about the technology. It was wrong about the classification — the same classification error this article exists to prevent.
The 6% signal
The guide's own data tells a story worth pausing on. "As of May 22, 2026, we had disclosed 1,596 vulnerabilities. To our knowledge, 97 of these have been patched." That's a 6% patch rate. Discovery is easy. Everything after discovery is hard.
The guide's response is to improve the post-discovery pipeline — better verification, better triage, better patching. That's correct for the reactive model. But the 6% also asks a different question the guide doesn't consider: how many of those 1,596 would have been prevented if the configuration and architecture that allowed them to exist had been verified against declared rules before deployment? A buffer overflow in source code can't be prevented by configuration verification. But a misconfigured trust boundary that exposes the vulnerable service to the internet — turning a local bug into a remote exploit — could have been caught as a posture violation before the source code bug mattered.
The reactive loop (find → verify → triage → patch) is necessary for the bugs that exist. Verification of configuration posture reduces the number of bugs that are reachable and exploitable in the first place. The two are complementary, not competitive. The guide presents only the first and frames it as comprehensive.
The stochastic acknowledgment
The guide makes an honest admission: "Models are stochastic, and a large codebase can have a long tail of vulnerabilities that continue to trickle in even when the code is unchanged." Each scan produces different results. Run it again and you find different bugs.
For a bug-hunting tool, that's acceptable — more runs, wider coverage. But this is also an acknowledgment that the tool cannot provide assurance. An auditor doesn't want "we found 47 bugs this run and might find different ones next run." They want "this configuration satisfies these rules, deterministically, reproducibly, same input, same verdict, every time." The guide doesn't distinguish between these two use cases — discovery (stochastic, more runs is better) and assurance (deterministic, reproducibility is the requirement) — because it treats all of security as discovery.
; Vassilev, NIST/IEEE Security and Privacy (June 9, 2026). If you work on a class of security problem this article says is missing from the LLM-scanning frame — configuration posture, compound risk, intent verification, architectural correctness — and you have a different view of how it relates to source code scanning, that's the conversation worth having.
SOCIAL SHARE CARD GENERATOR