What pre-disclosure patching actually requires (no, not threat intel)

Every security vendor eventually sells the same story: pre-disclosure patching is about getting the right intel before anyone else. The pitch is seductive — be the first to know, be the first to fix, sit closer to the source than the adversary. It is also, in practice, a distraction. The teams that actually ship a patch before a CVE goes public are almost never the teams with the best intel. They are the teams with the tightest remediation loop.

Intel is not the bottleneck

If you spent any time inside an enterprise security org, you watched this play out again and again. A piece of intel lands — a private Slack DM, a zero-day in a library half your services use. The clock starts. You email a maintainer. They forward it to a Slack channel. Someone volunteers to pick it up after the stand-up. By the time a fix lands in the dependency graph, the intel has usually cooled or has been replaced by the public CVE, which is now competing with three thousand other public CVEs for the same on-call rotation.

The intel did not fail you. The remediation loop failed you. There was no pre-baked way to atomically update the dependency across the org, no test harness that could validate the patch without a human in front of it, no PR-generation pipeline that could mint a fix and route it for review without anyone in the loop going on PTO.

What "before disclosure" actually requires

Three primitives, in roughly this order:

• A dependency graph you trust. Every service, every transitive dep, with an owner line. If the operator has to hunt down a maintainer before fixing, you already lost the clock. Your package.lock files and SBOMs have to be first-class inventory, not a quarterly exercise.
• A test harness that runs without a human. A patch is not a fix until you know it still passes the tests that were already failing, plus the test the bug actually breaks. If your CI sits behind a manual approval or averages double-digit-minute queue times, you do not have a test harness, you have a validation step.
• A delivery pipeline that mints a PR, not a ticket. Tickets route to humans, and humans route to a backlog with a manager, and the backlog has a sprint. PRs route to reviewers, and reviewers have merge buttons. The shape of the artifact matters more than the artifact itself.

Why vendors keep selling the wrong thing

Because intel is a feature you can charge for. Operational automation is mostly an internal ask that nobody budgets for until after the first post-disclosure incident. The vendor story writes itself: vendor with secret channel sells you proximity. You buy proximity, you feel safer, the procurement line item closes.

Meanwhile, the teams that run the boring discipline — graph, harness, PR minting — are usually the ones whose post-mortems read "we patched and rolled two hours before the CVE went public." They didn’t have better intel. They had a tighter loop.

What ZeroPatch is, plainly

ZeroPatch sits inside that loop. It watches emerging software vulnerabilities, picks up the upstream patch when it lands, and opens a pull request against your dependency graph with the patched version pinned. The PR includes the test that proves the fix is live. You land it when your review pipeline says you land it. The intel piece is upstream of us; the loop piece is the product.

If your team is buying pre-disclosure intel and not buying pre-disclosure automation, you are overpaying for proximity and underpaying for the thing that actually closes the window. That is the trade, plainly.

Want a closer look at the loop itself? See how ZeroPatch works.