We saw this with Heartbleed too: given sure confidence that there is a vulnerability in a particular diff, skilled security researchers can find it very quickly. It makes me want to find such and firmly tell them that there are vulnerabilities in TLS 1.2.
That reminds me of the old QA technique / tactic of only telling the developers where a bug was found. Sometimes you don't even have to find an issue, you can just pick a complicated module.
True quality comes from good process and systems, nothing more, nothing less.
http://en.wikipedia.org/wiki/Lincoln_index
http://allendowney.blogspot.com/2014/07/last-year-my-occasio...
I also ruefully remember how Halvar Flake did this to Dan Kaminsky's embargoed DNS vulnerability.
I thought that was pretty funny.
"given sure confidence that there is a vulnerability in a particular diff, skilled security researchers can find it very quickly."
Was there previously an announcement that a vulnerability existed, without details of what the vulnerability was?
That announcement implied that the vulnerability was SSL 3.0 only. Knowing that, the obvious place to look at would be the differences between SSL 3.0 and its successor TLS 1.0.
In Heartbleed, we knew that it was introduced with a particular OpenSSL version. That had 12 changes; 8 were DTLS. Two were clearly not relevant. One was heartbeat. Dan Franke took about fifteen minutes to go from that set of inputs to a sketch of heartbleed.
I now advocate QA by what I call "virtual tests": you don't have to write the tests, just the failure messages. Developers will do the rest of the work on their own.