In-memory micropatching introduces a minimal possible change to the code with minimal possible risk area where unexpected things could happen. For each micropatch 0patch writes, they know exactly where it is injected in the vulnerable module, and once they test its impact and assess possible side effects, it’s ready for distribution. There is minimal room for surprises there as long as there’s a deep understanding of the logic of the code they’re patching well enough. (Granted, sometimes they 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 0patch believes everyone should issue security fixes as micropatches.