The resounding negative effects of silent patches

The alert from the Zero Day Initiative (ZDI) announcing changes to its disclosure policy for ineffective patches has come at the perfect time. A recent yet alarming trend with silent patches has been brought to the surface, as the reduction in communications surrounding patches has been overlooked for quite some time. As a result, enterprises are losing their ability to accurately estimate the risk in their coordinated vulnerability disclosure (CVD) systems – further harming IT protectors.

The updates to ZDI’s policy are intended to incentivize vendors to correctly patch the first time around and effectively communicate patches to offer an accurate depiction of risk. While the need for shortened patch timelines for the public disclosure of vulnerabilities has become an urgent action, not everyone truly knows the hidden harm of silent patching and where to start.

To better grasp the concerns surrounding the matter, it’s important to understand three main areas: the history behind the silent patch, the repercussions of limiting researchers in the process, and how organizations must respond quickly and efficiently improve their patch rates and avoid long-term consequences.

What to know about the silent patch

To start, most major software vendors were once infamous for sweeping vulnerability reports under the rug, which made it challenging for researchers to report vulnerabilities. Bug reports from researchers were often housed in a quiet, unobserved space until, without notice, their proof-of-concept exploits no longer work. No credit, no explanation, no CVE ID – this was the standard silent patching model.

While this was the norm of a very standard plan – it’s very dangerous today, per the ZDI announcement. In most cases, when it comes to these software patches, many companies were not using exotic packers, nor were they employing anti-forensics. Despite any level of encryption of obfuscation of this patch data, it does eventually need to modify the code on the running software, exposing it to anyone with armed with a debugger and a disassembler. In these instances, there was a high risk for skilled exploit developers to sweep in and take advantage of patch…