The Aftermarket She Diagnosed is the Aftermarket She Prescribed

Jen Easterly's Glasswing analysis argues that cybersecurity is fundamentally a software quality problem, advocating for security built into software creation rather than bolted on after deployment. Anthropic's Project Glasswing uses AI to find and fix vulnerabilities faster, but critics note this still operates in the aftermarket, not preventing flaws upstream. The piece contrasts this with deterministic verification methods used in safety-critical domains like aviation and nuclear power.

Jen Easterly's Glasswing analysis https://www.linkedin.com/posts/jen-easterly/ opens with the sharpest diagnosis of cybersecurity published this decade: "We do not actually have a cybersecurity problem so much as a software quality problem. For decades, we have built an enormous global industry to defend, detect, and respond to vulnerabilities — flaws and defects in software — that should never have existed in the first place." And later: "The long-term goal cannot be simply to use AI to clean up yesterday's insecure code more efficiently. It must be to use AI to move security to the point of creation — to help developers write better, safer, more resilient software from the start. To shift from an aftermarket of cybersecurity to a world in which security is built in upstream, not bolted on downstream." The diagnosis is correct. The destination is correct. The prescription doesn't match either one. Anthropic's Project Glasswing finds vulnerabilities in codebases and assists with remediation. In Easterly's own framing, it offers the potential to "identify vulnerabilities more quickly" and "reduce the cost, time, and complexity of fixing them — assist with root cause analysis, generate candidate patches, prioritize risk, and accelerate testing and deployment." This is the aftermarket she diagnosed, accelerated by AI. Finding vulnerabilities faster is still finding. Fixing them cheaper is still fixing. Generating candidate patches is still remediating. Every one of these activities happens after the vulnerability exists — in the code, in production, in the codebase of a systemically important financial institution. The vulnerability was created. It was deployed. It persisted. Then the AI found it. That's a faster aftermarket. Not the end of the aftermarket. "Security built in upstream, not bolted on downstream." That sentence describes a specific architecture — one that exists today, has been proven for decades, and doesn't require a frontier AI model to implement. Built in upstream means: declare what must be true before the code is written or the configuration is deployed. Not after. Before. "No public S3 buckets in production." "No IAM role may assume cross-account access without MFA." "No API endpoint may accept unauthenticated requests." "No dependency with a known critical CVE may be deployed." These are declarations — human-authored statements of what the system must satisfy, expressed in a form a machine can check. Not bolted on downstream means: verify the declaration mechanically at the point of creation — before the code ships, before the configuration propagates, before the vulnerability exists to be found. A type checker that prevents buffer overflows at compile time. A policy engine that rejects a configuration violating a declared invariant before it reaches production. A contract test that blocks an API change that breaks a declared interface. These are deterministic verification gates — not models forming opinions, but mechanical checks producing binary verdicts: pass or fail. The architecture is: This is not theoretical. Every safety-critical domain does this: | Domain | Human declares | Machine enforces | |---|---|---| | Aviation | Pilot sets heading and altitude | Flight computer enforces envelope — prevents unsafe states at machine speed | | Nuclear | Engineers declare safety limits | Automated interlocks enforce — shut down the reactor before a human reads the gauge | | Trading | Risk managers declare position limits | Pre-trade checks enforce on every order — no order executes unchecked | | Software the cure | Security team declares invariants | Verification gate checks every change — no deployment violates the declaration | Aviation regulator does not ask a pilot to find envelope violations after the flight and fix them next time. The flight computer prevents the violation from occurring. That's "built in upstream." Glasswing finds the violations after the flight landed and offer to help patch the plane. That's "bolted on downstream" — faster, with AI, but still downstream. Easterly makes this point herself. It's the most damning evidence for the declaration approach over the discovery approach: "What these systems are uncovering is not exotic. They are not revealing some radically new class of AI-discovered weaknesses but rather highlighting further evidence of poor-quality design: the same categories of flaws we have seen for decades — predictable, preventable vulnerabilities that persist because our incentives have never been aligned to eliminate them." If the vulnerability categories are known, predictable, and preventable — then the declarations can be written today. "No buffer overflow" is a property Rust enforces by construction. "No SQL injection" is a property parameterized queries enforce by construction. "No public S3 bucket" is a property a three-line policy check enforces before deployment. "No cross-account IAM trust without MFA" is a property a CEL predicate evaluates against the configuration snapshot. These aren't novel problems requiring a frontier model to discover. They're known problems requiring a declaration to prevent. Every vulnerability Glasswing finds in a "predictable, preventable" category is a vulnerability that a declared invariant would have blocked before it existed. AI that finds a SQL injection in production code is doing useful work. A parameterized query that makes SQL injection impossible by construction is doing better work — at zero token cost, zero remediation time, zero human-in-the-loop overhead. Easterly argues that discovery was never the bottleneck — remediation was. Finding the vulnerability is the easy part. Understanding root cause, developing a fix, testing it, ensuring it doesn't break functionality, deploying it across complex systems — that's the hard, expensive, human-heavy part. Glasswing makes that part faster. This is correct for vulnerabilities that already exist. It's irrelevant for vulnerabilities that were prevented from existing. A declared invariant that prevents a class of vulnerability at creation time has zero remediation cost. The vulnerability was never created. There's nothing to root-cause, nothing to patch, nothing to test, nothing to deploy. The remediation challenge Easterly correctly identifies disappears, because the declaration made it unnecessary. The distinction the article misses: the most effective remediation is prevention. The most cost-effective patch is the one that was never needed. The most efficient vulnerability disclosure is the one that never happened because the class was declared impossible. Easterly's closing is right: even with Glasswing, cybersecurity doesn't end. Even with declared invariants, cybersecurity doesn't end. No finite set of declarations catches everything — this was formalized mathematically by Vassilev's NIST proof June 2026 , extending Gödel's incompleteness theorems to AI and security systems. The architecture isn't "declare everything and you're safe." It's: Glasswing is valuable in layer 2 — discovering what the declarations don't yet cover. But without layer 1, Glasswing runs forever at the same rate, finding the same predictable, preventable categories Easterly says we've known about for decades. With layer 1, Glasswing focuses only on the novel. The classes nobody has declared yet, which is a much smaller, much more valuable set. There's a conflation in Easterly's framing that obscures where the cure applies and where it doesn't. Easterly frames the crisis as a "software quality problem." That framing collapses four distinct domains into one bucket. Each domain has different discovery mechanisms, different prevention tools, and different verification approaches: | Code | Configuration | | |---|---|---| Application | Source code bugs — buffer overflows, SQL injection, logic errors | App-level settings — authentication config, session management, API permissions | Infrastructure | IaC templates — Terraform, CloudFormation, Kubernetes manifests | Runtime cloud config — IAM policies, S3 bucket policies, security groups, network ACLs | Glasswing operates in one quadrant: Application × Code. It finds source code vulnerabilities — the buffer overflows, the injection flaws, the logic errors. That's real and valuable work. It's also one-quarter of the problem. Mythos reads source code. It reasons about source code. It finds patterns in source code that match known vulnerability classes. It generates patches for source code. Every capability is scoped to one cell of the grid: Application × Code. It cannot evaluate whether your IAM policy grants excessive cross-account access — that's Infrastructure × Configuration. It cannot detect whether your S3 bucket policy combined with your Cognito identity pool creates a privilege escalation path — that's compound risk across Infrastructure × Configuration resources. It cannot verify whether your Terraform template violates your organization's security policy — that's Infrastructure × Code. It cannot check whether your application's authentication configuration matches your security requirements — that's Application × Configuration. Mythos is the most powerful source code analysis model ever built. Source code is one cell. The grid has four. Three cells where the majority of cloud breaches originate are invisible to it. The hype positions Mythos as the future of cybersecurity. The grid positions it as the future of one-quarter of cybersecurity. The other three-quarters need a different instrument: declared invariants verified against configuration, not a model reading source code. The DDP Law breach — fined £60,000 by the ICO after a ransomware attack — had root causes exclusively in the Infrastructure × Configuration quadrant: no firewall, no MFA, unpatched systems, a dormant user account active for years. Every root cause was a boolean check against a declared rule. No AI needed. No source code scanning would have found them. They're not code quality problems. They're configuration posture problems, deducible from the infrastructure itself. Compound cross-resource risk lives at the intersection of quadrants. A Cognito identity pool Application × Configuration combined with an IAM trust policy Infrastructure × Configuration combined with an S3 bucket policy Infrastructure × Configuration creates a privilege escalation path that no single-quadrant tool sees. The risk is in the combination — the edges between resources, not the nodes. Glasswing scanning source code doesn't see it because the vulnerability isn't in any source code. It's in the relationship between three configurations across two quadrants. Breaches don't respect quadrant boundaries. A typical 2026 breach crosses all of them: Glasswing finds and fixes step 3. Steps 1 and 2 remain a loaded gun. The source code is patched. The IAM role is still over-privileged. The OIDC provider is still misconfigured. The next logic flaw or the next developer who introduces one walks straight through the same infrastructure path because the architecture was never fixed. This is why configuration risk is a graph problem , not a pattern-matching problem. An LLM reads code and matches patterns against its training data. Configuration risk lives in the relationships between resources — the edges of the graph, not the nodes. "Does this IAM role, combined with this trust policy, combined with this bucket policy, create an unauthenticated path to sensitive data?" is a graph reachability question. You don't need an AI to guess whether a graph is connected. You need a solver to prove it isn't. Deterministic reasoning engines — CEL predicates, Z3 constraint solvers, Soufflé/Datalog for graph reachability — answer these questions at the correct level of abstraction: mechanically, exhaustively, and with mathematical certainty. An LLM forming an opinion about whether a configuration graph contains a reachable path is using the wrong instrument for the question. The graph either contains the path or it doesn't. That's a computation, not a judgment call. Intent mismatches live in the gap between what was configured and what was meant. A security group that allows 0.0.0.0/0 inbound on port 22 may be intentional a bastion host or a misconfiguration an application server . No source code scanner can distinguish intent from error — because intent was never declared. A declared invariant "no production server may accept SSH from 0.0.0.0/0" makes the check trivial and deterministic. The "software quality problem" framing leads to a "better source code scanning" prescription — which addresses one quadrant and leaves three unprotected. The declaration approach works across all four quadrants: Glasswing makes one quadrant's aftermarket faster. Declared invariants prevent vulnerabilities in all four quadrants before they exist. Both are needed. Only one of them covers the full surface. The grid above assumes a mature organization where infrastructure is defined as code, configurations are version-controlled, and changes flow through CI/CD pipelines. That's the best case. The reality in most organizations is worse: ClickOps. Infrastructure configured through the AWS console, Azure portal, or GCP dashboard. No Terraform, CloudFormation or code at all. Someone clicked through a UI to create IAM roles, security groups, S3 bucket policies. The infrastructure exists only as runtime state — not in any repository, not version-controlled, not reviewable by any source code scanner. Mythos cannot scan what was never written as code. The Infrastructure × Code quadrant is empty. Everything lives in Infrastructure × Configuration as runtime state that nobody declared, nobody version-controlled, and nobody can verify without snapshotting the live environment. Shadow scripts. One engineer wrote a bash script three years ago that rotates credentials, manages DNS, or configures backup policies. It's on that engineer's laptop. It's not in any repo. Nobody else knows it exists. When that engineer leaves, the script keeps running or stops running and nobody knows until something breaks. This is undeclared intent: someone had a reason for the script, but it was never expressed in a form anyone else can verify. Tribal knowledge. "Dave knows how the production database failover works." "Sarah set up the VPN configuration." "The security group on the legacy account was configured by someone who left in 2023." The configuration exists. The intent behind it is gone. Nobody can distinguish a deliberate security exception from a forgotten misconfiguration, because the intent was never declared. Manual configuration drift. An engineer configured a security group correctly through IaC six months ago. Last Tuesday, someone opened port 22 through the console during an emergency and never closed it. The IaC template says the port is closed. The runtime state says it's open. No source code scanner sees the drift — because the drift isn't in the source code. It's in the gap between declared state IaC and actual state runtime configuration . In these environments, which are most environments, the four-quadrant grid overstates the problem's tractability. Mythos's limitation isn't just "one quadrant out of four." It's "one quadrant out of four, and in many organizations, that quadrant barely exists because the infrastructure was never written as code in the first place." The declaration layer becomes even more critical in these environments. A declared invariant — "no production security group may allow 0.0.0.0/0 inbound on port 22" — can be checked against a snapshot of the runtime state regardless of whether the configuration was applied through Terraform, the AWS console, a shadow script, or a manual change nobody documented. The invariant doesn't care how the configuration got there. It checks whether the configuration satisfies the rule. That's the only verification mechanism that works when the source of truth is the runtime environment, not a codebase Mythos can scan. Easterly frames the remediation challenge as: understand root cause → develop a fix → test it → ensure it doesn't break functionality → deploy across complex systems. She then argues AI will make each step faster. This frames the defender's job as a diagnostic chain — understand, then act. Viable systems don't work this way. A thermostat doesn't understand thermodynamics. It compares temperature to setpoint and acts. An aircraft interlock doesn't understand aerodynamics. It detects a parameter exceeding a limit and overrides the pilot. A circuit breaker doesn't understand electrical engineering. It senses current exceeding a threshold and trips. A viable system regulates itself in a changing environment without fully understanding the cause of failure. It doesn't need root cause analysis to prevent damage. It needs declared boundaries and the ability to act when they're violated. The root cause analysis happens later by humans, at human speed, for learning and improvement. But the system was already protected because the boundary was declared and the response was mechanical. This is the primary function of any control system: regulate, then understand — not understand, then regulate. Easterly's framing inverts the order. She says defenders must first understand, then fix. The viable-system model says: first prevent the damage the declared boundary catches the violation mechanically , then understand the cause humans analyze at human speed for future improvement . The ratchet connects both: the human's understanding — gained after the fact, at human speed — becomes a new declared boundary that prevents the class from recurring. The system didn't need to understand the cause in real time. It needed the boundary. The understanding came later and made the boundary set grow. Glasswing accelerates the "understand, then fix" chain. Declared invariants eliminate the need for the chain entirely — for every class that's been declared. Both have a role. But positioning AI as the solution to the remediation bottleneck assumes defenders must always understand before they act. Viable systems act first and understand later. There's a deeper issue with Easterly's prescription that the four-quadrant grid exposes: she's proposing a probabilistic tool for problems that require deterministic answers. An LLM reading source code and forming an opinion about whether it contains a vulnerability is probabilistic. It's pattern-matching against training data. It can be wrong. It can miss vulnerabilities. It can hallucinate vulnerabilities that don't exist. Its verdict is an opinion with a confidence score, not a proof. The problems in three of the four quadrants don't need opinions. They need verdicts: Using an LLM to answer questions that have deterministic answers is using the wrong instrument. It's measuring temperature with a poem instead of a thermometer. The poem might be approximately right. The thermometer is exactly right. Every time. At a fraction of the cost. This creates what should be called Verification Debt : when you use a probabilistic tool to answer a deterministic question, you need a human to check the AI's check. The AI says "this S3 bucket is probably public." A human must verify: is it actually public? The AI says "this IAM role probably has excessive permissions." A human must verify. Each probabilistic answer generates a verification task for a human — which is the review bottleneck Easterly was trying to eliminate. The declaration approach eliminates the debt entirely: "no public S3 buckets" is checked mechanically, produces a binary verdict, and requires zero human verification. The violation is either present or it isn't. No probability. No debt. AI has a role: the uncertain questions. "Is this code pattern likely to cause performance issues under load?" "Does this API design follow security best practices?" "Is this error handling sufficient for production use?" These are judgment calls where a model's pattern-matching adds value because there's no deterministic answer. But Easterly's prescription doesn't distinguish between questions that have deterministic answers and questions that require judgment. She prescribes AI for both. The result: an expensive, probabilistic tool answering questions that a three-line policy check answers definitively — while the three-line policy check doesn't exist because nobody built the declaration layer. Let's take Easterly's claim at face value and score it against the alternative: | Metric | AI-assisted remediation Glasswing | Deterministic prevention declared invariants | |---|---|---| Cost per check | $0.01–$0.50 per LLM call model inference, token cost, API overhead | $0.0001 or less a policy evaluation is CPU microseconds, no API call, no tokens | Time to resolution | Minutes to hours find → root cause → generate patch → test → deploy | Zero. The vulnerability was never created. There is nothing to find, root-cause, patch, test, or deploy. | Accuracy | Probabilistic — can miss vulnerabilities, can hallucinate false positives, requires human validation | Deterministic — same input, same answer, every time, no validation needed | Scales with volume | Cost scales linearly with codebase size and scan frequency | Cost is near-constant — adding a new invariant costs one declaration; checking it costs microseconds per evaluation | Handles compound risk | Poorly — LLMs reason about one file at a time, not across resource relationships | Natively — compound reasoning across configurations is what deterministic engines CEL, Z3, Soufflé, Datalog are built for | Reduces to zero | Never — AI always has a nonzero error rate and nonzero cost per scan | Approaches zero for every declared class — each invariant eliminates its class permanently | AI reduces cost, time, and complexity. Deterministic prevention eliminates them — for every class that has been declared. Reduce and eliminate are different words with different outcomes and different economics. Easterly says "for the first time, AI offers the potential to reduce the cost, time, and complexity of fixing them." For three of the four quadrants, deterministic approaches already beat AI on all three metrics — at a fraction of the cost, at zero time prevention, not remediation , and at zero complexity a boolean check, not a diagnostic chain . AI cannot reduce time to zero because it operates after the vulnerability exists — finding and fixing takes time regardless of how fast the AI is. Prevention reduces time to zero because the vulnerability never exists. There is no time between "vulnerability created" and "vulnerability fixed" when the vulnerability was never created. The economics are stark: an organization running Glasswing against a million lines of code pays for every scan in tokens. An organization running declared invariants against configuration snapshots pays microseconds of CPU per evaluation. The first cost scales with volume. The second is near-constant. At enterprise scale — millions of lines, thousands of configurations, continuous scanning — the cost difference is not marginal. It's orders of magnitude. AI has a role in quadrant one Application × Code where the questions are complex — buffer overflows in novel code patterns, logic errors in unfamiliar architectures, zero-day vulnerability classes nobody has declared yet. That's real value. But prescribing AI for all four quadrants — including the three where deterministic checks produce better results at near-zero cost is prescribing the most expensive instrument for problems that have the cheapest solutions. Easterly's article makes one argument: Mythos has arrived. It will solve cybersecurity. This is the silver bullet. The single technology that eliminates the problem. Fred Brooks named this fallacy in 1986: "There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement in productivity, reliability, or simplicity." Forty years later, the argument repeats with a different technology name. Cybersecurity is a software quality problem → Mythos finds and fixes software quality issues → therefore Mythos solves cybersecurity. Each step sounds reasonable. The chain is broken. Step one is correct but incomplete. Cybersecurity is four different quality problems across four quadrants, not one. Mythos addresses one quadrant. Step two is correct but narrow. Mythos finds and fixes source code issues. It cannot find configuration posture issues, compound cross-resource risk, or intent mismatches — because those aren't in source code. Step three doesn't follow. A tool that addresses one-quarter of the problem cannot solve the whole problem, regardless of how powerful it is within that quarter. A perfect source code scanner running on the DDP Law infrastructure finds zero issues. Because every vulnerability was in configuration, not code. The infrastructure is breached while the scanner reports all clear. Every silver bullet in cybersecurity history followed the same arc: | Era | The silver bullet | What it actually addressed | What it missed | |---|---|---|---| | 2000s | Firewalls | Network perimeter | Application-layer attacks, insider threats | | 2010s | SIEM | Log correlation and alerting | Prevention, configuration posture | | 2015s | Cloud-native scanners CSPM | Individual resource misconfiguration | Compound risk, intent mismatches | | 2020s | AI-powered detection XDR, CDR | Behavioral anomaly detection | Deducible configuration violations | | 2026 | Mythos/Glasswing | Source code vulnerabilities | Configuration posture, compound risk, intent verification — three of four quadrants | Each generation solved one class of problem and was marketed as the solution to all classes. Each generation's limitation became the next generation's market opportunity. Mythos is following the same pattern — powerful in its quadrant, blind to the other three, marketed as the answer to cybersecurity. The alternative to a silver bullet is a complete system. Not one tool that does everything. Five elements, each serving its function, each covering its quadrant. The specification layer declares what must be true across all four quadrants. The verification gate checks every change deterministically. The behavioral detection layer where Glasswing lives catches what the declarations don't yet cover. The ratchet converts each discovery into a new declaration. The casing enforces boundaries and prevents accumulation. No single element solves cybersecurity. No single tool covers all four quadrants. No single model — however powerful — replaces the declaration layer, the verification gate, and the ratchet. The silver bullet is always the same fallacy: one element elevated to the status of a complete system. Mythos is a sub-system. It's not the system. There's a reason Glasswing is popular in 2026: humans are bad at declaring. Writing CEL predicates for a multi-cloud environment is difficult. Authoring Rego policies across hundreds of AWS services is error-prone. Maintaining a corpus of invariants that covers every configuration pattern an organization deploys requires sustained effort that most security teams don't have the bandwidth. The declaration layer should exist. In most organizations, it doesn't — because declaring is hard. This is Easterly's implicit argument: AI will handle the mess because the declarations don't exist. If nobody is going to write the invariants, then a model that finds the violations is the next best thing. That's a legitimate position — pragmatic, grounded in the reality that most organizations don't have the discipline or capacity to build a complete declaration layer. But it concedes the aftermarket permanently. If the declarations never get written, the model runs forever — finding the same predictable, preventable categories Easterly says we've known about for decades. The system never learns. Each scan is a new expense. Each finding is a new remediation task. The treadmill runs at AI speed instead of human speed, but it's still a treadmill. The synthesis of both positions is the ratchet — and Mythos has a role in it: Use AI to generate the deterministic invariants that then render the AI unnecessary for that class of bug. Mythos finds a SQL injection pattern → a human reviews the finding → the finding becomes a declared invariant "no concatenated SQL in database queries" → the invariant is enforced deterministically on every commit → Mythos never needs to find that class again. Mythos finds an over-privileged IAM role → a human reviews the role → the finding becomes a declared invariant "no IAM role may have permissions on production resources" → the invariant is checked against every configuration snapshot → Mythos never needs to find that class again. Each cycle: AI discovers, human reviews, declaration is authored, deterministic gate enforces. The AI's workload shrinks. The declaration layer grows. The cost of verification drops toward zero for every class that's been declared. The AI focuses on the new classes nobody has declared yet — which is a smaller, cheaper, more valuable set each cycle. This is the role Easterly should be prescribing for Glasswing: not the permanent solution, but the discovery engine that feeds the declaration layer. Glasswing finds. Humans declare. Deterministic gates enforce. The ratchet turns. Each cycle permanently reduces what Glasswing needs to find. That's not "the beginning of the end of cybersecurity as we know it." It's the beginning of cybersecurity as it should have been built: human judgment upstream, machine enforcement downstream, AI in the middle discovering what hasn't been declared yet and getting less necessary every cycle. Easterly frames Glasswing as "a signal of something far more consequential: a shift in how we might fundamentally reduce cyber risk at scale." She's right that it's a signal. But the signal isn't "AI can find and fix bugs faster." The signal is: if the most powerful AI model in the world is finding the same categories of preventable vulnerabilities that have existed for decades, then the problem was never discovery and the solution is not better discovery. The solution is what she said in her opening paragraph: security built in upstream. Declared invariants verified at creation time. The aftermarket reserved for what the declarations can't cover — which, as the declarations grow, becomes an increasingly small set. Glasswing is the best aftermarket tool ever built. The declaration layer is how you stop needing it for the classes you already know about. Both exist. Both are needed. Only one of them ends the cycle Easterly correctly diagnosed. And it's the one she described in her opening and didn't prescribe in her conclusion. References: Jen Easterly's Glasswing analysis LinkedIn, June 2026 ; Anthropic, Project Glasswing; Vassilev, NIST/IEEE Security and Privacy June 9, 2026 — mathematical proof that no finite set of guardrails is universally robust. The three-layer architecture declare → detect → ratchet applied to cloud security in Cloud Computing is Missing One Component. Everyone Builds the Wrong Five.