How can you create a micropatch so much faster than the original vendor? – Help Center

In-memory micropatching introduces a minimal possible change to the code with minimal possible risk area where unexpected things could happen. For each micropatch we write, we know exactly where it is injected in the vulnerable module, and once we test its impact and assess possible side effects, we're ready to distribute it. There is minimal room for surprises there as long as we understand the logic of the code we're patching well enough. (Granted, sometimes we don't, depending on the nature of the vulnerability - memory corruptions are easy to understand and fix, logical errors less so.)

Vendors using traditional "fat updates" produce a fix by changing the source code and rebuilding the product. Many things can go wrong in that process, such as:

source code might have been changed in many places since the last release (especially for products developed by large teams), and chances are that at least some of it will introduce new flaws;
wrong code versions could be used for the new build, especially in large teams;
the build process and scripts could have been changed since the last release, possibly causing flaws in the new build;
...,
and down to many much less likely but not impossible events such as flaws introduces by errors in compilers.

In other words, a product re-built from modified source code after a month or more of code changes is a very different product than its previous build, and things can break in many places.

This forces software vendors to perform extensive full-coverage tests, and often to delay patching of individual vulnerabilities due to other fixes and enhancements that may have more impact on their bottom line. With the sizeable cost of preparing a new release it can be incredibly expensive for vendors to issue out-of-band updates. (Which is why we think they should all issue security fixes as micropatches.)

So in short, a micropatch changes a tiny bit of product's behavior and doesn't require full-blown testing or the entire product, while a "fat update" effectively replaces the entire product and potentially affects any and all parts of its behavior.