In an unexpected turn of events following the publication of this Guide, we were called on by the US House Committee on Energy and Commerce and the Senate Committee on Commerce, Science, and Transportation to address concerns regarding the coordinated disclosure of the Meltdown and Spectre vulnerabilities in early 2018. In particular, the committees were concerned about the timing of patch availability and deployment relative to the public disclosure of these vulnerabilities.

In their responses to the Committees' letters, many of the companies explained that it is industry best practice to embargo vulnerability information amongst the smallest possible group of stakeholders during CVDs to prevent "bad actors" from learning of the vulnerability or vulnerabilities before they have been corrected. Many of the companies further advised that they followed or otherwise cited the CVD protocol or guidance provided by the CERT Coordination Center (CERT/CC). In addition, many respondents further argued that it is critical to do so to ensure that patches are "in place," "delivered," or "implemented" prior to widespread public disclosure. As a company or user is not protected from a given vulnerability until an appropriate patch is "in place," "delivered," or "implemented," we agree that sound CVD strategies would seek to limit disclosure of vulnerability information before stakeholders are able to apply patches. Such a practice allows for the best protection of the end user–typically, consumers.

The committees went on to note:

However, based on the responses to our letters and information provided during company briefings, questions remain regarding...whether companies used precise terminology in describing the availability, not application, of patches. Companies outside the core group needed time to test and successfully implement patches, and the availability of a patch and the application of a patch are not the same. The fact that a patch or other mitigation is "available" simply means that it exists and is ready for a company or individual to use. But when a patch or other mitigation is described as "in place," "delivered," or "implemented," the distinction implies that companies and individuals have retrieved that patch and actually applied it to their systems.

In our response, we agreed. The relevant section of our reply is reproduced below.

Patch Availability is not Patch Deployment

The committees’ letter asks “...whether companies used precise terminology in describing the availability, not application, of patches” and points out “...the misapplication of such terms as ‘in place’ and ‘available’ when used to describe the status of vulnerability patches.”

CVD guidance can be more clear in both terminology and the boundary between the phases of patch availability and patch deployment. And while we agree that vendors should take care not to overstate the status of patch deployment, the best many vendors can do today is to make patches available, along with sufficient vulnerability information for users to make informed patching and other risk decisions.¹ Ultimate responsibility for installing patches often falls to deployers,² including end users.

While we appreciate the committees’ desire that “sound CVD strategies would seek to limit disclosure of vulnerability information before stakeholders are able to apply patches,” our experience indicates that it is impractical to privately notify all affected stakeholders without public disclosure. Thus, public disclosure is usually the best practice to inform affected parties—including end users—who may need to take action in order to apply patches to their software and devices.

The committees’ letter correctly points out that the deployers’ need to test patches “can lead to a lag time of weeks or months before a patch is applied.” We note that in the extreme, this lag time can become indefinite for reasons including:

• Some deployers (including many end users) will remain unaware of the availability of patches, or will lack the technical capability to deploy them successfully.
• Long or complex supply chains for patch distribution may result in patches issued by an originating vendor not making it through to the downstream vendors’ products in a timely manner.
• Some deployers will intentionally choose to accept the risk and not apply the patch at all. The decision to apply patches is a risk management decision.

For especially pervasive vulnerabilities such as Meltdown and Spectre, there is no clear optimal solution to balancing the diverse operational cadence across such a wide range of industries (including critical infrastructure sectors) with the need for timely public disclosure. It may be that the best we can expect is for consistent, accurate, thorough, and timely information to be provided in support of defender decisions.

1. Some products have secure, robust, and automated patch deployment features. Software-as-a-service (SaaS) and other cloud services can typically be updated by providers, requiring little if any action by end users.
2. By “deployers” we mean those responsible for choosing if, when, and how to install patches or perform other mitigating or compensating actions. Deployers can include system administrators, vulnerability management systems, vendors with the ability to push patches, and end users who must take manual action.