Your Phishing Simulation Score Is 99%. Here's Why That Worries Me.

#devops #devsecops #security #appsec

The 2025 Verizon DBIR has a number that should change how you think about security training budgets.

The median phishing click rate after years of repeated, ongoing simulation training: 1.5%.

The Verizon 2025 DBIR tracked over 22,000 incidents across 139 countries. The researchers stated it plainly: the failure rate was unaffected by training.

Not "slightly improved." Not "trending in the right direction." Unaffected.

If your organization runs quarterly phishing simulations and your click rate is 1%, you have not solved the problem. You have measured it. Those are different things.

The Test Is Not the Threat

Here is the structural problem with phishing simulations: they are known tests.

Your employees have taken them before. They know what a suspicious email looks like — because you showed them what a suspicious email looks like. They are pattern-matching against a template you trained them on. And they are good at it.

The attacker has read the same template.

In the EtherRAT campaign, attackers did not compromise GitHub. They created repositories that looked exactly like what employees had been trained to expect from a trusted source. The training pointed employees toward a category — "GitHub is official" — and the attacker moved into that category and waited. No phishing simulation would have caught this, because no phishing simulation teaches employees to distrust GitHub.

In May 2025, Coinbase disclosed a breach that cost between $180 million and $400 million in remediation and compensation costs. The attack did not involve phishing at all. Contractors with legitimate system access were recruited and bribed to exfiltrate data over an extended period. It looked like a normal workday for an insider who had decided to monetize their access.

No simulation score predicted this. No click rate measured this. The threat did not look like the test.

The Uniformity Problem Nobody Talks About

There is a second issue that receives almost no attention in security awareness discussions.

When every organization trains on the same framework, the attacker does not need to study each organization. He studies the framework once. He builds one attack that works against the trained behavior pattern, and it scales horizontally across every company that completed the same curriculum.

The same standardization that makes training cost-efficient for defenders makes exploitation cost-efficient for attackers.

The NIST framework, the CIS controls, ISO 27001 — these are public documents that describe, with precision, how a compliant organization behaves. An attacker reading them does not see security guidance. He sees a map of expected defensive behavior, annotated with the locations where trust is assumed and inspection stops.

Every standard that says "employees should trust X" tells the attacker: here is your entry point.

What the Data Actually Shows

Unit 42's incident response data from 2024-2025, across 700+ cases, found that more than one-third of social engineering intrusions involved non-phishing techniques entirely: SEO poisoning, fake system prompts, help desk manipulation, and voice phishing that surged 442% in the second half of 2024 compared to the first half.

These attacks succeed not because employees failed their simulations. They succeed because the attacks were specifically designed to look nothing like them.

The simulation is a known test. The attacker did not take it. He read the answer key.

The Dead Zone Between Tools

The same pattern appears in the technical layer.

In April 2025, Blue Shield of California disclosed a breach: no vulnerability, no exploit, no CVE. For almost three years, a single analytics configuration quietly sent protected health information for 4.7 million people to an advertising platform. The configuration was legal. The tool was legitimate. The data flowed exactly as it was configured to flow.

SAST, DAST, and SCA were never positioned to catch this — not because they failed, but because none of them treat configuration as part of the attack surface. Each tool correctly answered the question it was designed to answer. None of those questions covered what was actually happening.

The breach lived in the space between tools. The same space where the phishing attack lives — in the gap between what the simulation tests and what the attacker actually does.

Both failures share the same root cause: the defense model assumes the layer next to it already checked what it needed to check. Nobody owns the boundary.

A Different Organizing Principle

The goal of compliance training is to produce employees who can pass the simulation. The goal of compliance scanning is to produce a dashboard that turns green.

Neither measures exposure. Both measure performance against a known test.

The alternative is not more training or more scanners. It is a different question: not "did this pass the check," but "can these findings be chained" — and "does the training prepare people for attacks that look nothing like the simulation?"

Employees who understand why trust laundering works can reason about attacks they have never seen. Defenders who model findings as a graph instead of a list can see paths that per-domain tools cannot.

The attacker is not waiting for someone to fail the test. He is building for the ones who passed.

This is the subject of Episode 2 of They Read The Manual — a series for DevSecOps engineers and security leads on how attackers actually think. If you want to see the full breakdown of the Blue Shield case, the DBIR data, and the inter-tool correlation gap with visuals: https://youtu.be/0frXXZqjxvs

Sources cited: