We spend so much time on patching because we’re a vulnerability management vendor. Finding vulnerabilities and remediating them are two interrelated processes; neither is particularly effective alone.

This interplay between vulnerability and patching isn’t unique to Tripwire as a vendor. It’s part and parcel of running information security in any large organization. Our survey aimed to gain a valuable perspective on the state of patching in the enterprise so that we could build better products that help to reduce risk.

The survey included responses from 483 IT professionals directly involved in patching, and while there are more than a handful of interesting data points to discuss, I’d like to pull out just a few for consideration here.

Fifty percent of respondents feel their IT team doesn’t understand the difference between applying a patch and remediating a vulnerability.

There are generally two reactions to this response: “of course!” and “huh?” If you don’t spend quality time with the mechanics of vulnerability identification, you’re probably a little confused by the question. The fact is that we, as an industry, consistently conflate vulnerabilities with patches. They are not the same thing!

I tried to diagram this relationship for a different blog post but ultimately gave up because of the number of variations. The fact is, we identify known vulnerabilities with CVE IDs, and vendors release increments of code that address some of those CVE IDs. It’s not a one-to-one relationship, except when it is, and bundles are common, except from vendors who don’t roll up patches.

Sometimes patches don’t fix all the vulnerabilities, and sometimes they fix multiple vulnerabilities on some platforms but not others. Sometimes a patch is an upgrade, sometimes it’s not, and sometimes you can apply an individual patch or an upgrade to fix disparate but overlapping sets of vulnerabilities.

After writing that sentence, it’s no wonder we experience confusion about patching and remediation. It’s usually possible to unwind this confusion for a single condition or patch, but we haven’t discussed the volume of patches and vulnerabilities that organizations have to deal with (the survey covers that).

I’ll give one example to illustrate the point here. Microsoft was deemed the easiest platform to patch by 43 percent of respondents, so that’s a good place to look at patch volumes.

In 2015, Microsoft released 535 patches across 122 platforms resolving 501 vulnerabilities. For the vendor deemed easiest, there were basically 1.5 patches per day in 2015. If only a fraction of those patches included the complexity we’ve just been discussing, it’s truly an unmanageable burden on organizations that just want to keep doing business securely.

The confusion between remediating vulnerabilities and applying patches is one example of the complexity surrounding enterprise patch management. We haven’t touched on the technical challenges of distribution, auditing performance, or organizational silos. When we look at the steady stream of patches that vendors push, with multiple strategies, it’s no wonder that we see gaps.

This complexity is a key contributor to the gaps between perceived maturity around patch management and real vulnerability risk reduction (or lack thereof). In fact, the misalignment between vulnerability remediation and patch application may be a significant contributing factor in the increasing volume of breaches overall.