Simon Willison put it plainly in a recent post: cybersecurity now looks like proof of work. The comparison is sharp. In proof-of-work blockchains, miners expend real computational resources to demonstrate effort, and that demonstration is the point. The work has no value beyond its own existence as proof. The analogy lands because something similar has happened to enterprise security, where the primary output of a security program is increasingly a portfolio of evidence that a security program exists.
This framing is worth sitting with for a while, because it explains a lot of puzzling observations about how organizations actually behave around security.
The Compliance Stack as Work Demonstration
Consider the standard enterprise security certification ladder: SOC 2 Type II, ISO 27001, FedRAMP, PCI DSS, HIPAA. Each of these frameworks generates significant paperwork, audit trails, and remediation effort. Each also generates a certificate or attestation at the end. That certificate is what customers, regulators, and procurement teams check. Not the underlying controls. Not the threat model. The certificate.
SOC 2 audits, for instance, are conducted by licensed CPA firms against the AICPA Trust Services Criteria. The criteria are reasonable in aggregate: availability, confidentiality, processing integrity, privacy, security. But the audit methodology is a point-in-time examination of documented evidence. An organization can have excellent documentation practices and terrible actual security hygiene. The audit, by design, cannot distinguish between them with high confidence. What it can do is verify that controls were documented, procedures were written, and logs were retained.
This is proof of work. You expended the effort. Here is the receipt.
FedRAMP is a more extreme version of the same dynamic. The authorization process for a cloud product can take 18 to 24 months and cost between $250,000 and $500,000, according to FedRAMP’s own working group estimates. The resulting Authorization to Operate is not a statement that the system is secure. It is a statement that the system completed the authorization process. Federal agencies still get breached. FedRAMP-authorized systems have had significant vulnerabilities. The authorization process is thorough documentation that a process occurred.
Why the Market Rewards This
The frustrating part is that the market incentive structure is nearly coherent, even as the outcome is incoherent.
If you are a procurement officer at a hospital choosing between two EHR vendors, you cannot meaningfully evaluate their security posture from the outside. You can check whether they have a SOC 2 report. If one has it and one does not, you have a differentiator that your legal and compliance teams can act on. The certificate is legible to your organization. The underlying security architecture is not.
This is adverse selection operating at scale. Vendors learn that completing compliance processes unlocks sales. Security engineers learn that their work is measured by audit outcomes. CISOs learn that their job security tracks closer to compliance posture than to actual incident rates, partly because incident rates are hard to attribute and compliance posture is auditable.
The result is an industry optimized around producing the artifacts that audits require, staffed by specialists in exactly that skill. Compliance automation platforms have built significant businesses selling tools that help companies collect evidence faster. The underlying security outcome is secondary to the throughput of evidence collection.
The Asymmetry That Makes This Dangerous
Proof-of-work cryptocurrency mining is wasteful but mostly harmless. The energy goes into the network and the network functions. The waste is real but contained.
Security theater has a different failure mode. An attacker does not need to defeat your compliance posture. They need to find one path that your compliance posture did not cover. The defender must protect every surface; the attacker needs one successful approach.
The 2020 SolarWinds compromise demonstrated this clearly. Affected organizations included companies and agencies with mature compliance programs, dedicated security teams, and extensive audit histories. The attack went through the software supply chain, a vector that compliance frameworks of the time treated as an attestation problem: get your vendors to sign a questionnaire. SolarWinds signed the questionnaire. The malicious update shipped anyway.
The XZ Utils backdoor in 2024 showed the same failure mode at a different layer. A patient, multi-year social engineering campaign compromised a core open-source library. No compliance framework anticipated this attack pattern. The organizations running FedRAMP-authorized systems running the vulnerable SSH daemon had no idea they were exposed until a Microsoft engineer noticed anomalous CPU usage during unrelated performance testing.
These are not edge cases. They are the natural exploitation surface that forms when defense concentrates on auditable controls and attackers look for the gaps in between.
Supply Chain as the Persistent Gap
Supply chain security is the area where the proof-of-work analogy becomes most uncomfortable, because the scale of the problem is genuinely incompatible with the compliance approach.
A typical web service in 2026 depends on hundreds of direct npm or PyPI dependencies, each of which has its own dependency tree. The npm registry hosts over 2.5 million packages. The Python Package Index has over 550,000 projects. Conducting meaningful security review of this graph is computationally intractable for any individual organization. The compliance response to this has been: require a Software Bill of Materials, check for known CVEs in automated scanning, and have vendors sign attestations.
SBOMs are useful. CVE scanning catches a lot. But both are reactive measures against known, documented vulnerabilities. The XZ attack was not in any CVE database until after it was discovered. A sophisticated supply chain compromise specifically targets the period before detection. The compliance artifact confirms you checked against yesterday’s list of known threats.
SLSA (Supply-chain Levels for Software Artifacts) from the OpenSSF represents a more technically grounded approach, building provenance attestations into the build pipeline so that artifact integrity is cryptographically verifiable. SLSA Level 3 requires hermetic builds with auditable build service provenance. This is meaningfully harder to fake than a signed questionnaire. It is also significantly harder to achieve, which is why adoption remains incomplete across the ecosystem even several years after the framework was introduced.
The Measurement Problem Underneath
Part of what drives the compliance orientation is that measuring actual security outcomes is genuinely hard. Mean time to detect a breach, mean time to respond, the rate of successful phishing attempts against employees, the percentage of vulnerabilities remediated within SLA windows: these metrics exist and security teams track them internally. They are not, however, what procurement teams ask for, because they require context to interpret and vary wildly by industry and threat model.
A company in a low-visibility industry with a poor security team might have a low breach rate simply because nobody is trying to breach them. A company in financial services with an excellent security team might have a high detection rate because they are under constant targeted attack. Comparing raw numbers across organizations tells you almost nothing. Compliance certificates, by contrast, are binary and universally comparable.
This is the core structural problem. The metric that is legible to buyers is not the metric that reflects security outcomes. So investment flows toward the legible metric.
What Thoughtful Security Looks Like Instead
Organizations that do security well tend to share a few traits that compliance frameworks do not reward directly. They have active threat modeling that updates when their product or infrastructure changes, not just when an audit is scheduled. They run tabletop exercises against realistic scenarios derived from actual threat intelligence about their industry, not against generic compliance scenarios. They instrument their systems to detect anomalous behavior at runtime, building detection capability that extends beyond the known CVE list.
The MITRE ATT&CK framework provides a useful vocabulary here. It catalogs observed adversary tactics and techniques based on real-world incidents, giving defenders a way to think about coverage that is grounded in how attackers behave rather than how auditors think. Using ATT&CK for purple team exercises, where red and blue teams work together to test detection capabilities against realistic attack chains, produces fundamentally different security work than preparing for a SOC 2 audit.
None of this is incompatible with compliance. The best security programs do both. The problem is when compliance becomes the ceiling rather than the floor, and when the organizational incentive structure treats the certificate as the goal.
The proof-of-work comparison stings precisely because it is accurate. Proof of work is expensive, it produces a verifiable artifact, and it is formally correct within its own rules. It just does not tell you what you actually need to know.