An informal analysis of vendor acknowledgement of vulnerabilities
Many disclosure debates focus on researchers who discover vulnerabilities. Little attention is given to the impact on busy security analysts who must determine which vulnerabilities exist, and if they can be patched. There is little or no emphasis on the role of vendors of the vulnerable software. Given continued discussions of vulnerability disclosure practices, most recently regarding vendor contacts on the PEN-TEST list, we decided to offer some results of an informal analysis we performed in October 2000. We also make some recommendations for improvements.

In anticipation of the Guardent/eWeek vulnerability summit in early November 2000, we conducted an informal experiment in which we tried to obtain the following information:

1) Whether the vendor publicly showed awareness of an announced vulnerability, and admitted that the problem was real ("vendor acknowledgement," also referred to as confirmation).

2) Whether the vendor provided contact information for security problems.

Although our results are not quantitative, we do consider them to be useful in understanding some of the problems in assessing which vulnerabilities can be patched.


This is an informal analysis. It is the sole product of the
individual authors, and does not represent an official position of The MITRE Corporation.

This analysis does not attempt to identify or address the various reasons for why vulnerability information may be incomplete or unavailable, as that topic has often been discussed in the past.

The analysis evolved as it was being conducted, and as such was not subjected to normal scientific rigor. Thus, it is not appropriate to list specific vulnerabilities, vendors, or researchers.

This analysis focuses on a test set of "worst case" vulnerabilities. It is not necessarily typical of all vulnerabilities or all vendors.

Basic Conclusions

1) Without a standard location for security vulnerability information on vendor web sites, it is often extremely difficult to even find the appropriate page where vulnerability and patch information might be discussed.

2) Without a standard contact name for asking questions about vulnerabilities, it is difficult for a security analyst to find out which individuals or groups at a vendor web site have the information needed. This problem also makes it difficult for the vulnerability researcher to reach the right people.

3) The customer-focused nature of vendor web sites often makes it difficult for security analysts to access vulnerability information, even if the site has that information. Security analysts normally are not the vendor's customers.

4) Frequently, there is no apparent public acknowledgement of the vulnerability, or the web site is too difficult to navigate.

5) In some cases, the vendor may or may not have acknowledged the vulnerability, but the vendor's information is too vague to be certain.

6) When the researcher's original report did not include detailed vendor and product information (such as URLs and version numbers), it made it more difficult for the security analyst to find the proper vendor web page to examine for acknowledgement.

Focus of the Analysis

We examined a test set of approximately 150 announced vulnerabilities. This test set EXCLUDED any vulnerability with a well-established advisory, e.g. from CERT, well-known software vendors, or well-known security companies with vulnerability analysis teams. Most were announced between 1997 and 2000. The most recent vulnerabilities had been publicized at least 2 months before the analysis took place.

Vendor acknowledgement of vulnerabilities was examined from the point of view of a "busy security analyst." Assumptions were:

1) The analyst is responsible for identifying and mitigating IT security vulnerabilities in a relatively large enterprise with diverse platforms, applications, and security requirements.Thus, every announced vulnerability may need to be addressed in one way or another.


Critical bug found in Cisco ASA products, attackers are scanning for affected devices

Several Cisco ASA products - appliances, firewalls, switches, routers, and security modules - have been found sporting a flaw that can ultimately lead to remote code execution by attackers.

Weekly newsletter

Reading our newsletter every Monday will keep you up-to-date with security news.

Daily digest

Receive a daily digest of the latest security news.

Fri, Feb 12th