Why the Security Industry Optimizes for Auditors, Not Attackers

The framing Simon Willison offers in his recent post is worth sitting with: modern cybersecurity has come to resemble Bitcoin’s proof-of-work consensus mechanism. Not because security is cryptographically structured, but because the evaluation criteria have drifted in the same direction. In proof-of-work, the accepted hash is the one that required computational energy to produce. The energy burned is the point. In contemporary security practice, the work that gets recognized is the work that produces visible artifacts: reports, questionnaires, certifications, audit trails. Whether it produces actual security is secondary.

This is not a cynical take on security professionals. Most of them know this. The problem is structural, and it has been compounding for about fifteen years.

How Compliance Became the Product

The compliance framework industry has legitimate roots. PCI-DSS emerged from real payment card fraud problems in the early 2000s. HIPAA security rules tried to address genuine healthcare data exposure risks. SOC 2 gave software vendors a standardized way to demonstrate basic security hygiene to enterprise buyers. These frameworks captured reasonable minimum standards at the time they were written.

The problem is that compliance has become the deliverable, not the floor it was meant to be. A SOC 2 Type II certification means an independent auditor reviewed a company’s described controls across a period of six to twelve months and found them consistently applied. It does not mean the company is secure against the threats targeting it in 2026. Okta, which has strong compliance posture and handles authentication for a significant portion of enterprise software, experienced a serious incident in 2023 where attackers accessed a support system and exfiltrated customer data. The certification and the breach coexist without contradiction, because they measure different things.

Enterprise procurement has reinforced this dynamic. The standard vendor security review process involves questionnaires that can run to several hundred questions. Industry standards like the Cloud Security Alliance’s Consensus Assessments Initiative Questionnaire (CAIQ) and the Shared Assessments Standardized Information Gathering (SIG) questionnaire exist to reduce duplication, but most large enterprises layer proprietary questionnaires on top. Security teams spend weeks answering them. A vendor with genuinely good security practices but thin documentation will score worse than one with thorough policy documents and mediocre actual controls. The questionnaire evaluates the description of the security program, not the program itself.

The CVE Treadmill

The vulnerability management side of the industry has developed its own proof-of-work character. The National Vulnerability Database published approximately 28,902 CVEs in 2023, up from around 18,000 in 2020. Every CVE gets a CVSS score on a 0-10 scale, with scores of 9.0 and above classified as Critical. The score models severity in a vacuum: how bad would exploitation be under ideal conditions for an attacker. It does not model the probability that this specific CVE will be exploited in your specific environment.

Security teams run vulnerability scanners, receive lists of thousands of findings, and spend substantial time triaging them. The triage process asks whether each finding is exploitable in context, whether a patch exists, whether the patch breaks anything, and what the remediation timeline should be. For large organizations, this is a continuous process with no natural end state.

The realistic exploitation rate for CVEs is low. Research by Kenna Security and the Cyentia Institute found that roughly 5% of CVEs are ever observed being exploited in the wild. Vulnerability management programs typically require touching all of them regardless. The proof-of-work dynamic means an unreviewed CVE is a compliance gap, whether or not it represents actual risk in your environment.

Alert Fatigue as a System Property

Security operations centers run on alerts. SIEMs aggregate logs from across an environment, detection rules fire when patterns match, and analysts review the queue. The volume at scale is high enough that the industry has developed a term for what happens to analysts: alert fatigue. The analyst who has reviewed several thousand alerts in a week and found no actionable threats will start processing the queue differently by Thursday afternoon. This is not a discipline problem. It is a predictable consequence of the signal-to-noise ratio in systems optimized to generate alerts rather than to surface threats.

The standard response to alert fatigue is to invest in more tooling, refine detection rules, or hire more analysts. The underlying incentive structure does not change. SLAs typically require that alerts be reviewed and closed within a defined time window, because reviewed-and-closed is measurable. Whether the review was substantive is harder to audit. The metric that satisfies compliance requirements is the one that gets optimized.

Better metrics exist. Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) are outcome-oriented: how long did it actually take to find a real threat, and how long to contain it. Tabletop exercises scored on whether the team successfully detected and contained a simulated breach produce different information than exercises scored on attendance. Red team engagements where the red team’s success rate is the primary deliverable tell you something about actual defensive posture rather than about the depth of your policy documentation. These measurements exist and get used. They are just not what most compliance frameworks require.

Why the Incentive Structure Persists

The proof-of-work dynamic emerges from a principal-agent problem. The people who evaluate security at most organizations, including procurement teams, board-level risk committees, and auditors, cannot directly assess security outcomes. They can assess observable work. This is a consequence of information asymmetry, not a failure of sophistication. Auditing whether a company responded to all CVEs within policy timelines is tractable. Auditing whether a company’s detection capability would have caught a sophisticated intrusion requires running the intrusion.

Cyber insurance is one area where this is beginning to shift. Insurers have financial exposure when breaches occur, which gives them genuine incentive to price risk accurately rather than to price compliance posture. Some insurers now require security telemetry from endpoint detection platforms as a condition of coverage, or use it as an input to pricing. This is outcome-adjacent measurement: what does your security tooling actually observe in your environment, rather than what policies do you have documented. The economic pressure behind that shift is real in a way that audit-driven pressure often is not.

Bug bounty programs represent a different signal. A program that pays researchers based on findings creates a market for actual security weaknesses. The findings from a mature bug bounty program tend to be more operationally relevant than the outputs of a compliance-driven penetration test, which is typically scoped to avoid disruption and produces a report full of findings that the vendor can categorize as out-of-scope or accepted risk. When the researcher’s payout depends on finding real exploitable issues, the incentive aligns with the security outcome.

What Outcome-Based Security Looks Like

The compliance infrastructure is deeply entrenched and serves real purposes, even where it has calcified in ways that reduce its security value. SOC 2 as a baseline for enterprise procurement is not disappearing. CVE tracking as a shared vocabulary for vulnerabilities is genuinely useful. The problem is not that these things exist but that they have become ends rather than means.

Progress requires buyers who evaluate security outcomes alongside security documentation. It requires procurement processes that weight red team results and bug bounty history alongside compliance certificates. It requires that the people setting security budgets have enough grounding in what security tools actually do to ask whether the alert queue is being processed meaningfully or just cleared on schedule.

The proof-of-work framing Willison offers is useful because it names the incentive structure clearly. When you understand that the current system rewards demonstrating that work happened, you can at least begin asking whether the work being demanded is the work that would actually improve outcomes. That question does not always get asked in security planning conversations. It should get asked far more.