Forem: Martin Kambla

Project Glasswing: What Software Companies Should Actually Do in the Next 12 Months

Martin Kambla — Tue, 14 Apr 2026 04:14:56 +0000

Anthropic's Project Glasswing gave limited access to Claude Mythos Preview — a model reportedly able to identify and exploit zero-day vulnerabilities across major operating systems and browsers, including multi-stage exploit chains. Anthropic says more than 99% of the vulnerabilities it found remain unpatched.

That is the data point that matters.

The usual reaction to announcements like this is a philosophical debate about how many of those bugs were already known to someone and just unreported. That is a rabbit hole not worth digging. Assume the less flattering answer - act on that.

Software will not suddenly stop working. Codebases are not worthless. Nobody has to rewrite everything next quarter.

What changed is the economics of offense.

What actually got cheaper

A model like Mythos does not need to invent new classes of vulnerabilities to cause disruption. It only needs to reduce the skill, time, and cost required to find real bugs, weaponize them, and chain them together.

Anthropic explicitly warns that defenses whose main value is friction rather than a hard barrier will erode against model-assisted attackers, because models can grind through tedious exploit-development work at scale.

An example of what "friction" means in practice: a stripped closed-source binary that used to cost a specialist a weekend of reverse engineering to map. A heap-grooming sequence only one in ten offensive researchers could reliably land. A logic bug buried three layers deep in a state machine nobody wanted to audit by hand.

That kind of work compresses.

Mythos reportedly found memory-corruption bugs, logic bugs, cryptographic implementation weaknesses, browser exploit chains, and vulnerabilities inside closed-source binaries via reverse engineering. Five bug classes. One pipeline.

The short version:

exploit development gets faster
exploit chaining gets easier
reverse engineering gets cheaper
patch windows get more dangerous
"annoying but probably fine" exposures get less fine

What software companies should actually do

Most writing about AI risk becomes either philosophy or panic. Neither is operationally useful. Here is the triage.

1. Build an honest asset inventory

Not a compliance spreadsheet. An actual map: what is internet-facing, what runs with elevated privilege, what is written in memory-unsafe languages, what parses untrusted input, what sits before authentication, what cannot be patched quickly, what third-party components quietly expand the attack surface.

Without this, you are not doing prioritization. You are doing vibes.

2. Split the estate into rewrite, isolate, monitor

Rewrite: high-risk parsers, security-critical low-level services, old C/C++ components exposed to hostile input, brittle auth or crypto-adjacent implementations.

Isolate: legacy services you cannot replace in 12 months, components with known rough edges and clear business dependency, anything that can be boxed into stricter privilege boundaries, seccomp profiles, sandboxes, or service segmentation.

Monitor: lower-risk business logic, standard SaaS code in managed runtimes, internal tooling with constrained exposure.

The point most teams miss: the right response to Mythos is not "rewrite everything." It is "be much more honest about what deserves rewriting first."

3. Make patch latency an executive KPI

If 99% of Mythos-found vulnerabilities remain unpatched, the bottleneck is not discovery. It is organizational response speed.

The question is no longer could someone find this bug? It is could we fix, validate, and deploy the patch before someone industrializes it?

Patch velocity is now a business capability. Not just a security metric.

4. Discount "attacker effort" in your severity model

A vulnerability that used to be dismissed as "the exploit path is too tedious" is more dangerous than it looked six months ago. A chain that used to require an unusually strong offensive researcher may increasingly be available to a competent operator with a good model and enough compute.

That does not mean every bug is suddenly critical. It does mean your severity rubric should stop leaning on attacker inconvenience as a mitigation.

5. Default new security-critical code to memory-safe stacks

Not ideology. Risk concentration. You do not need to rewrite mature systems tomorrow. You should probably stop creating fresh long-term exposure in exactly the places where a language choice removes entire bug classes.

6. Add model-assisted workflows to defense now

Anthropic's own framing is that the long-run equilibrium may still favor defenders — the way fuzzers eventually did — but the transitional period favors attackers if defenders are slower to adapt.

That means AI-assisted code review, exploitability analysis, dependency triage, fuzzing and testcase generation, and regression verification after patches.

If offense becomes automated while defense stays ticket-driven and manual, the gap widens fast.

7. Stop treating architecture as separate from security

The companies that look smartest in 18 months will not be the ones that wrote the most urgent memos.

They will be the ones that quietly reduced blast radius.

Least privilege, segmentation, sandboxing, narrow interfaces, ephemeral credentials, isolated parsers, fast rollback paths. All of those become more valuable when exploit development gets cheaper.

The real question

Mythos does not mean software companies need to rewrite everything.

It means they have to stop pretending their backlog is neutral.

A lot of organizations have accumulated technical debt under the quiet assumption that the exploit-development bottleneck was mostly on the attacker side. That assumption is weakening.

What used to be "we should clean this up eventually" is increasingly "this is a compounding liability."

The next 12 months are not about panic. They are about sorting your projects into three buckets:

things you can still safely defer
things you must isolate now
things you should never have built that way again

Not "do we rewrite everything?"

But "which parts of our system can no longer rely on attacker friction to stay safe?"

That is a much better executive question.

And a much more expensive one to answer late.

The Commoditization Thesis: What Actually Happens When Software Gets Easy

Martin Kambla — Wed, 08 Apr 2026 01:03:48 +0000

The data is clear on what’s already happening.

Labor’s share of GDP fell to 53.8% in Q3 2025 — the lowest in the modern BLS series back to 1947. Capital is eating labor’s lunch, and AI is accelerating it.
Entry-level pressure is already visible: Stanford’s Digital Economy Lab found declines concentrated among 22–25 year-old workers in AI-exposed jobs such as software development, customer service, and clerical work.
The narrower BLS category of computer programmers is projected to decline 6% through 2034, even while broader software development roles still grow. That distinction matters: implementation-heavy work gets pressured first.
Meanwhile, workers with AI skills command meaningful wage premiums. PwC found an average 56% wage premium for workers with AI skills in 2024, and other labor-market reporting showed premiums up to 43% for jobs listing multiple AI skills.
Tech salary growth slowed to 1.6% in 2025, down from 3.5% in 2023.

This is not speculation. The compression is measurable.

Historical pattern — this has happened before, twice

Web development (late 90s → 2008): Developers charged premium rates to technically naive clients. WordPress, Squarespace, and frameworks killed the implementation premium. Value migrated to architecture, product strategy, integration.

Mobile apps (2008 → mid-2010s): App Store gold rush → React Native / Flutter commoditized a large chunk of standalone app building. Same outcome: implementation became cheaper, judgment became more expensive.

The arc is usually the same: scarcity premium → tool-driven commoditization → value migrates upward to domain expertise, architecture, integration, and judgment.

Historically, that took 5–8 years. AI appears to be compressing the cycle closer to 2–3 years.

What the capital side of this looks like

Piketty’s r > g framework feels increasingly visible in current data.

The S&P 500 is dramatically above its January 2023 level.
AI captured close to 50% of all global venture funding in 2025, with roughly $202.3B invested across infrastructure, foundation labs, and applications.
McKinsey has explicitly warned that when real estate and equity values rise faster than GDP, capital can get pulled toward asset inflation and repurchases rather than the kinds of investment that generate broad long-run growth.

Labor income alone is becoming a weaker wealth-building vehicle. The gap between returns on capital and returns on labor is widening, not narrowing. For someone starting from near-zero capital, that is the fundamental challenge.

The critical prediction for 2026–2030

Middle-class software developer income will likely bifurcate.

Bottom 60% of current developers: real income stagnation or decline. Implementation work commoditizes.
Top 20%: premium widens. Architecture, security, compliance, domain-specific systems, AI integration, and judgment-heavy work become more valuable.
The gap between these groups likely widens through at least 2030.

Not because software disappears.

Because undifferentiated software work gets repriced downward, while the value of high-context, high-trust, high-complexity work rises by contrast.

The uncomfortable truth

Software commoditization means the floor rises — more people can build — but the ceiling also rises. Complex integration, security, compliance, architecture, and domain-specific work become more valuable precisely because raw implementation gets cheaper.

That usually hollows out the middle.

The real risk is getting distracted by opportunities that look easier, when in practice they are just more crowded.

I scanned 8 popular npm projects for quantum-vulnerable cryptography. Here's what I found.

Martin Kambla — Wed, 01 Apr 2026 15:25:03 +0000

This week Google published a paper that changed the post-quantum timeline. Breaking ECDSA-256 — the signature scheme protecting Bitcoin, Ethereum, and most of the web — now requires roughly 1,200 logical qubits and under 500,000 physical qubits. That's a 20x reduction from previous estimates.

I wanted to answer a simple question: how exposed are the projects we all depend on?

So I built pqaudit, an open-source CLI that scans source code and npm dependencies for quantum-vulnerable cryptography — algorithms broken by Shor's algorithm (RSA, ECDSA, Ed25519, ECDH, Diffie-Hellman) and weakened by Grover's algorithm (AES-128) — and flags the NIST-approved replacement for each one.

Then I pointed it at 8 popular projects.

The results

Project	Files	Critical	High	PQC Ready
Express	142	0	0	Yes
Fastify	295	1	0	No
Next.js	22,478	17	1	No
Prisma	3,291	0	0	Yes
jsonwebtoken	65	21	0	No
Solana web3.js	104	17	0	No
Ethereum web3.js	1,194	12	3	No
Signal Desktop	2,854	12	0	No

30,423 files scanned. 6 of 8 are not quantum-ready.

Let me walk through the interesting ones.

jsonwebtoken: 21 critical findings in 65 files

This one hit hardest. node-jsonwebtoken is the most popular JWT library on npm — and it's fundamentally built on quantum-vulnerable algorithms.

[!!] RSA — RS256, RS384, RS512, PS256, PS384, PS512
     sign.js, verify.js, lib/validateAsymmetricKey.js
     Fix: ML-DSA-65 (FIPS 204)

[!!] ECDSA — ES256, ES384, ES512
     lib/validateAsymmetricKey.js
     Fix: ML-DSA-65 (FIPS 204)

Every signing algorithm the library supports — RS256, ES256, and their variants — is broken by Shor's algorithm. If your app uses JWTs for authentication (and most Node.js apps do), your auth tokens are signed with quantum-vulnerable cryptography.

There's no PQC JWT standard yet. The IETF is working on it, but it doesn't exist today. This is a systemic gap in the entire web ecosystem.

Solana web3.js: Ed25519 everywhere

Solana's entire identity and transaction model is built on Ed25519:

[!!] Ed25519 — src/account.ts, src/keypair.ts, src/transaction/legacy.ts
     Fix: ML-DSA-65 (FIPS 204) — blocked by Solana protocol

17 critical findings across 104 files. Every account, every keypair, every transaction signature depends on an algorithm that Shor's breaks. The secp256k1 program (for Ethereum compatibility) adds more.

The migration path exists — ML-DSA-65 is the NIST replacement — but it requires a protocol-level upgrade across the entire Solana network. This isn't something you can fix in your app.

Next.js: 17 critical findings (but it's not what you think)

Next.js has 17 critical findings across 22,478 files. Sounds bad, but the nuance matters — every single finding is in vendored bundles, not in Next.js source code:

crypto-browserify bundled in packages/next/src/compiled/ contains RSA, ECDSA, Ed25519, ECDH, and Diffie-Hellman polyfills
jsonwebtoken compiled into the same directory
constants-browserify exposes RSA padding and ECDSA engine constants

Next.js doesn't use quantum-vulnerable crypto itself. But it ships it to every application that depends on it, through vendored dependencies. This is a supply-chain problem.

Signal Desktop: the only one migrating

Signal Desktop had 12 critical findings (X25519 key exchange, ECDSA), but it's also the only project in this scan that has active PQC adoption. pqaudit detected ML-KEM (Kyber) usage through @signalapp/libsignal-client — Signal's implementation of the PQXDH protocol.

Signal is ahead. Everyone else is at zero.

Express and Prisma: PQC ready

Express and Prisma both passed with zero critical findings. The pattern is clear — frameworks that delegate cryptography to the runtime or database layer don't have this problem. The vulnerability lives in libraries that implement or wrap cryptographic primitives directly.

What breaks and what doesn't

Not all cryptography is quantum-vulnerable. Here's the split:

Broken by Shor's algorithm (must migrate):

RSA (any key size) — key exchange and signatures
ECDSA, Ed25519, EdDSA — signatures
ECDH, X25519, Diffie-Hellman — key exchange
DSA — signatures

Weakened by Grover's algorithm:

AES-128 — reduced to 64-bit effective security. Fix: use AES-256.

Already quantum-safe (no action needed):

AES-256, ChaCha20-Poly1305 — symmetric encryption
SHA-256, SHA-3 — hashing
ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+) — the NIST PQC standards

Why this matters now

You might think quantum computers are far away. Google's paper says otherwise. And even before a quantum computer exists, "harvest now, decrypt later" attacks mean adversaries are collecting your encrypted traffic today for future decryption.

The NSA's CNSA 2.0 mandates PQC for new national security systems by January 2027. Google has set a 2029 deadline for its own products. NIST finalized the standards (FIPS 203, 204, 205) in August 2024.

The migration window is open. The first step is visibility — knowing where quantum-vulnerable cryptography lives in your stack.

Try it

npx pqaudit .

One command, no signup, no config. It scans your source code and npm dependencies, classifies findings by severity, and tells you the NIST-approved replacement for each one.

Outputs: human-readable text, JSON, CycloneDX CBOM, or SARIF for GitHub Code Scanning.

For CI/CD:

npx pqaudit . --ci --format sarif --output pqaudit.sarif

It's MIT licensed and on GitHub. Issues and contributions welcome — especially detection rules for languages beyond JavaScript/TypeScript.

Full results

The detailed scan data for all 8 projects is published at pqcworld.com/scan-results.html.