The interval
The no-perfect-code argument says that defects are the constant and the response is the variable. This page is about one segment of that response: the gap between somebody knowing and everybody knowing.
It is the least technical part of security work and the one that most often decides how much damage lands on people who had no part in the decision. The cases below are arranged by what each one settled.
Coordination at scale is possible, and rare
Eighty vendors patched one protocol flaw on one day in July 2008, having been briefed in secret for months, because a resolver flaw was serious enough that no one of them could fix it alone. The Kaminsky flaw is the case the industry cites when it wants to prove coordination works, and it is cited so often partly because it has not been repeated at that scale.
Its companion is KRACK: submitted for review in May, vendors notified through a coordinating body in August, public in October with patches already shipped - and a fix that was backwards-compatible, so a patched client was safe on an unpatched access point. That property is why the response worked, and it is not always available.
An embargo protects the interval before the fix, not after it
A patch is a description of the vulnerability. Anyone competent can compare the new code with the old and work backwards. Researchers extracted a hardcoded password from Juniper's ScreenOS within six hours of the patch being public. A Microsoft responder said the same thing about Conficker ten years on: once a patch is released, many more people can reverse it. And Kaminsky's month of quiet between the patch and the conference talk was never going to be quiet.
The practical consequence is that the clock a defender is racing after a fix ships is set by whoever reads diffs fastest, not by the embargo.
Withholding buys nothing if someone else can find it
At GCHQ, public-key cryptography had been conceptualised by 1970 and implemented by 1973. None of it reached anyone, and so none of it protected anyone; the published 1976 work changed everything. Diffie-Hellman is that comparison in a single data point.
SATAN is the same argument about tools rather than mathematics. A researcher was fired for publishing a scanner in 1995; the industry then spent thirty years adopting his position as its business model. Whether the 1995 objections were unreasonable is a live question again with automated vulnerability discovery, and the article says so - but withholding a capability others can build has not yet been the thing that protected anybody.
Fixing it quietly has a shelf life
Intel found the arithmetic flaw internally, judged it not even an erratum, revised the circuitry without disclosing, and then asked customers to prove they were affected using information Intel had not published. The Pentium FDIV bug cost about $475 million, almost none of it because of the defect.
DigiNotar revoked certificates in silence for over a month and was found by a member of the public asking a question on a web forum, while the fraudulent certificates were used against roughly three hundred thousand people. Its companion, RSA, told customers there had been a breach without telling them what was taken - so nobody could work out whether to replace tokens, change PINs or firewall their administrative servers.
Against those, the counter-example: Juniper announced unauthorized code in its own shipping , which is close to the worst thing a network can say about itself, and was widely praised for it.
Telling people what to do is the product
The scanner that mattered was not the one that found the most; it was the one that explained each finding - what the problem was, what it could do, and which of four things to do about it. SATAN established that template in 1995 and a great many modern tools still do it worse. A list of findings creates work; an explanation creates capability.
The same distinction decides advisories. Fortinet published a named, checkable artefact - a symbolic link left behind after exploitation - so customers could determine whether patching had been enough. Most vendors do not, and the customer is left unable to answer the only question that matters.
The finder is usually an outsider who suspected themselves first
A mathematics professor spent four months blaming his own code before blaming Intel's chip. A Gmail user in Tehran posted a question on a forum. A statistics department produced a map. A patient insisted she had been burned by a machine that, according to its manufacturer, could not burn anyone - and Therac-25 is where that report going unbelieved cost lives.
The transferable instruction is short: an incident report that contradicts your model of the system is data about your model. The instinct to explain it away is the failure mode.
Sometimes the record does not resolve
Two cases here end without an answer, and are written that way on purpose. The STJ attack has an official account saying the backups survived and security reporting saying they were destroyed; both are on the public record and they cannot both be complete. The Silk Road has a government account of how the server was found, a technical rebuttal, and a court that closed the question on a procedural rule rather than deciding it.
Recording a contradiction and saying plainly that it is unresolved is not a failure of the write-up. It is the honest state of the evidence, and a reader is better served by it than by a clean story.
Where this leads
The other half of the picture - not what was said, but what broke - is how systems fail. What both of them argue for, in practices rather than in cases, is decided in advance.