Summer of Clearinghouses

Why everyone is suddenly building clearinghouses, and why the clearinghouse is the least interesting part.

Everyone seems to have announced a clearinghouse over the past few weeks. We did too. Ours is called Athena, and the main thing that sets it apart is that it was already real and running when we announced it — built quietly months earlier, heads down, taking findings and shipping fixes, because customers kept asking us to. We only announced it now because everyone else started announcing theirs, and staying quiet started to look like something it wasn't. The others arrived louder and, as far as anyone outside the press releases could tell, didn't exist yet.

Here's the part none of those announcements will tell you: the clearinghouse is the least important thing to build.

When a project we'd deliberately kept private, a five-billion-dollar press release, and the White House all reach for the same word inside a few weeks, that's not a trend. Trends are optional. This is the shape of a problem changing under everyone at once. So let me explain why these things are appearing, why most of them won't matter, and why the few that do are quietly racing to put themselves out of business.

A clearinghouse is just data

Clearinghouses aren't new to open source. We've had them for decades.

The NVD is a clearinghouse. So is the GitHub Advisory Database, and OSV, and every security feed you've ever pulled from. Every vendor with a vulnerability portal is running one too, scoped to its own software. They are all the same thing: a pool of vulnerability data with a front door.

The "clearinghouses" being announced this summer aren't a new species, but they do pool a new kind of data: pre-disclosure vulnerabilities scattered across the long tail of open source. Some in critical projects, some in tiny ones nobody's heard of; some at the latest version, some at whatever older release happened to be running. It amounts to the least organized but most thorough security research project ever assembled. And because of the Unix process model, they all matter the same: a flaw in the most obscure dependency runs with the exact same privileges as the application that loaded it, so the smallest leaf in the tree can hand over the whole process.

If the pool isn't new, the pool isn't the story.

The pool was never the point

Data is inert. A finding sitting in a database has never patched anything. The value, the part that has always been hard, is actuation: turning that finding into a rebuilt, tested, signed artifact, backported into the version you're actually running, sitting in the registry your tooling already points at. Not "here's an advisory, good luck." A fix, where you'll consume it, before you go looking for it.

This is the part Chainguard has done for years, sitting downstream of every public clearinghouse there is. Our build system watches thousands of open source projects and reacts the moment an advisory lands: fetch, rebuild from source, test, sign. Most CVEs are remediated in roughly two days, and the overwhelming majority never touch a human hand. We hold a one-day SLA on the vulnerabilities CISA says are actively exploited. We've remediated well over 100,000 of them. The clearinghouse data was always the input. The factory was the product.

Which is exactly why Athena is the least important thing we built. We already had the factory. A clearinghouse is just a new front door to it. A few months ago, when the people running the frontier model programs asked us to start doing this for non-public vulnerabilities, that's all it was. Same machine. New pipe.

The flood is a byproduct

Forget the clearinghouses for a second: why is there suddenly a flood of private vulnerabilities in open source, and why is everyone scanning the same code?

The answer is that nobody set out to. It's a byproduct.

The best way to get a real signal out of a model like Mythos isn't to point it at a file and ask politely. It's to put it in front of a running application — the thing actually executing, a debugger attached, a sandbox to play in, the source in context — and hand it a vague, adversarial prompt. "Break this." And it does.

It finds the flaws in your first-party code, and those you just fix. You own that code. You don't need a clearinghouse to patch yourself.

But almost none of a real application is your code. The overwhelming majority is open source, a lot of it is out of date, and the model does not care about the line between what you wrote and what you imported. It chains across the entire surface. The exploit it hands you doesn't stop at your border. It runs straight through some dependency three layers down that you've never heard of, and nobody has maintained in years.

That artifact — a live working exploit for code that isn't yours to fix — is the thing with nowhere to go. That is what every one of these clearinghouses is actually a response to. It also explains the data's two strange properties at once: it's private because it's a loaded weapon, and it lands on a shared target, because the few dozen libraries that show up in everyone's apps are exactly the few dozen libraries every one of these models is now crawling over. The findings themselves barely overlap. But the code they surface in does.

That concentration decides the next question.

A few large ones

How many of these should exist?

Start with the thing that makes the timing brutal. The mean time to exploit is now estimated at negative seven days. Across the vulnerabilities weaponized last year, exploitation started, on average, a full week before the patch was even public. That number used to be sixty-plus days. It crossed zero in 2024. Mandiant, Google, and CrowdStrike all tell the same story — CrowdStrike puts it at 42% of exploited vulnerabilities hit before public disclosure. The attacker is no longer racing the patch; the attacker is finishing before the patch begins.

And when there is a patch, the patch is the map. A published fix is a diff that points straight at the bug. In our own experiments, we've watched an advisory become a working exploit, with no public proof-of-concept to crib from, in under an hour. Disclosure is the starting gun, and you fire it at yourself.

So the entire game becomes: how much of the world is already protected at the instant disclosure happens? It can't be everyone. The fix is the map, so pre-disclosure protection extends exactly as far as the people you can vet and hold to an embargo. But it can be a lot of people, and from there, if you move quickly and carefully, you can protect a lot more the instant the embargo lifts. And that is a question of scale.

Bigger pools win, for four reasons that compound. The findings rarely overlap, but they pile onto the same few dozen libraries that sit in everyone's stack — so a bigger pool maps that shared handful more completely than any single team could alone. Every fix to one of those libraries protects every member who depends on it, so coverage compounds with membership faster than attackers can outrun it. Scale buys leverage upstream, too: a volunteer maintainer engages with one recognized security team, not thirty strangers. And scale buys orchestration reach, because you can only fire the layers that are in the room — no CDN, no network rule; no security vendors, no detection content; no one touching production, no backport.

There's a quieter reason: a channel full of unembargoed exploits is the single most valuable target in the ecosystem, and only a well-funded operation can defend it to the bar that requires. A thin one isn't a smaller version of the same thing. It's a skeleton key.

But it was never going to be one. The fear of a monoculture is real and rational — one pool holding everyone's pre-disclosure exploits is a skeleton key for the whole internet, and nobody should be comfortable with that, including whoever holds it. Regulators aren't: APRA, Australia's banking regulator, tells its banks to move at AI speed and manage concentration risk in the same breath. Competitors aren't: nobody who just spent five billion dollars announcing a clearinghouse folds it into someone else's. And no sovereign is: no country routes the pre-disclosure exploit feed for its own critical infrastructure through another country's pool.

But if one is impossible, dozens are a mess. The findings land on the same shared code, so the winners can't ignore each other — overlapping embargoes, fixes racing each other upstream, one pool's disclosure detonating another's. Every pair is a standing negotiation, and that surface grows with the square of the count. A few is a working group. Dozens is the fragmentation everyone was trying to avoid, rebuilt one press release at a time.

So you land where critical trust infrastructure always lands: root DNS, cloud providers, the CAs after Let's Encrypt. Not one, not a thousand. A few large ones. And a few is stable, because a clearinghouse isn't a cloud provider: nothing accumulates that you can be held hostage to. Stop sending data, send it elsewhere, and one disclosure period later, you're free. That's not the concentration anyone needs to fear.

Which means most of the clearinghouses about to be announced are noise. There's a clean test for the rest, and I'll get to it.

The pool is a flow, not a vault

If bigger is better, doesn't bigger also mean a bigger secret to leak?

It would, if the pool were a vault. It isn't. It's a flow. Findings arrive, get actuated, and leave. What's exposed to a leak at any given moment isn't everything you've ever pooled. It's only what's currently in flight, under embargo, waiting.

That inverts the intuition completely. You don't reduce your leak risk by staying small and taking fewer findings. You reduce it by actuating faster, so each finding spends less time in the pool. The dangerous clearinghouse isn't the big one. It's the slow one, where findings pile up under embargo because the operator can't push fixes out the door fast enough. A backlog is the leak surface.

So here's a line you can hold me to: if our pool is growing, we're failing. A healthy clearinghouse runs at steady state: what comes in goes out, and the standing size stays flat. A growing pool isn't a sign of success. It's the alarm that actuation is losing the race. The size of the pool is a thermometer, not a trophy.

Throughput is the value and the safety property at the same time. That's the whole game.

From coordinated to orchestrated

Coordinated vulnerability disclosure was a protocol: a handshake between one finder and one maintainer, built for a world where bugs were found slowly and one at a time. The word gives it away. "Coordinated" means two parties agreeing on a timeline.

That world is gone. You cannot hand-coordinate ten thousand findings. But you can orchestrate them. The same automation that lets a model find them at machine speed is what lets you fix them at machine speed. The shift is from coordinated to orchestrated disclosure: not two parties negotiating a date, but a conductor driving every control point to land on a single downbeat.

You already know what the absence of that looks like. It looks like log4j.

The disclosure worked. The patch existed early. What turned log4j into a lost month wasn't a failure to disclose. It was a hundred thousand security teams independently doing the same emergency by hand. Everyone grepping for the same class, hand-writing the same WAF rule, flipping the same flag, hunting the same shaded copies, and then doing all of it over again when the first patch turned out to be incomplete. That wasn't a disclosure problem. That was the absence of an orchestration layer.

Orchestrated disclosure is log4j, where the conductor fires everything on the downbeat — the WAF rule, the network signature, the backport, the VEX data telling you where you're not affected, the detection content, the upstream pull request — the moment the embargo lifts. The firefight is over before most teams wake up. That's why the layer matters more than the pool, and why reach is a function of who's in the room.

Coordination doesn't vanish, to be clear. It shrinks down to the one thing that's still genuinely human: negotiating the embargo and getting the durable fix accepted upstream. Everything downstream of the downbeat gets orchestrated.

What happens next

There's a short game and a long game, and they're not the same game.

The short game

There will be a flood of clearinghouse announcements. There may have been another one while you read this. It's hot, there's money and headlines in it, and everyone wants a piece. Ignore almost all of it. The launch is never the metric.

Here's the clean test I promised, and it's simple enough to ask any vendor pitching you a clearinghouse. Ask two questions. First: from finding to rebuilt, tested, signed fix, how long, on median, and what fraction never touch a human hand? That's throughput, and if they can't give you a number, they haven't measured the thing that matters.

Second: of the fixes you've shipped, how many landed upstream, in the source, versus how many only reached people pulling directly from you? That's reach, and it's the difference between a vendor patching its own customers and a vendor actually shrinking the problem. Any operator worth trusting can answer both with a number. The ones who answer with pool size are telling you they haven't measured the right thing yet. Findings are vanity. A fix nobody can reach is barely better than a finding.

So the metric was never how many vulnerabilities you're holding. It's how many people you actually help per month: directly, the ones pulling fixes straight from you, and indirectly, the many more protected because the fix landed upstream or shipped through a partner, people who will never know your name.

For whatever it's worth, ours has already taken in more than twenty thousand findings and shipped over two thousand patches across five hundred projects. By our own test, though, those aren't the numbers that count. Shipping a patch into our own registry is the easy half; it's still downstream of the fix that actually subtracts from the problem instead of just managing it — the one accepted upstream, in the source, protecting everyone else, whether they've heard of us or not. That indirect number is the one that counts.

So here's another line you can hold me to: we're going to publish all of it — the median time from finding to shipped fix, the fraction that never touch a human hand, and the share that lands upstream. The early numbers won't be pretty, for us or for anyone; upstreaming at this scale is weeks old. We'll publish them anyway, because a test you won't take yourself isn't a test.

The ones that last won't be the ones built to make a quick buck. This is infrastructure you stand up because it's necessary to survive the wave, not because it prints money this quarter. You can tell the serious ones by where they spend effort nobody's paying them for: the integrations, the partnerships, the upstream pull requests that don't generate revenue but do generate trust.

If you're deciding who to trust with this, that's the whole job: run the two-question test above on anyone who shows up asking for your data, ask what happens to a finding after it's found, and don't let pool size stand in for an answer. If you're deciding whether to build one yourself, ask whether you already have the factory — the fetch, rebuild, test, sign pipeline — because without it, a clearinghouse is a mailbox nobody's checking.

The long game

All of this is temporary. It has to be. We don't know whether the next generation of models finds ten times more vulnerabilities in the same code we've already scanned to exhaustion. Vulnerability patching has always been a treadmill. We've just turned the speed up and expected everyone to hold it for a marathon — and let's be honest, most of us weren't even walking on it before.

Cybersecurity teams have known for a decade that patching, minimizing attack surface, and keeping dependencies current is good hygiene. Almost nobody actually does it at the pace they swore to on January 1. I'm not judging; I've met my own dependency trees.

Clearinghouses are a safety net behind the treadmill. Maybe they nudge the speed down a notch. But we're not all getting into marathon shape overnight, and we shouldn't have to. We need a way off the treadmill, not a faster one.

Secure by design is that way off: new versions of the libraries and frameworks and tools, rebuilt so entire classes of these attacks are simply impossible — not patched after the fact, impossible. The endgame isn't a better clearinghouse. It's an open source base layer so hard to break that the models come up empty, and the clearinghouses can finally sit idle. That's the tell for the ones that matter: they're racing to make themselves unnecessary.

Will it work? Honestly, I don't know. Secure by design has been the right answer for thirty years, and the world has found thirty years of reasons not to do it. But the treadmill has no finish line, and I'm done pretending it does. We were never going to win this one on speed.

This summer of clearinghouses won't last forever. If we get it right, it won't have to.