June 30, 2014 By John Lucassen 3 min read

When selecting an information technology (IT) vendor, it is important to consider what the vendor does to mitigate security vulnerabilities. Since no IT system or product can be made completely secure, you should expect your IT vendors to design their systems and products to be part of a comprehensive security approach that will also involve operational procedures and may even require other systems, products or services to be most effective.

A Comprehensive Approach to Security

One important factor to consider is whether the vendor has a comprehensive approach to security. IT vendors are both consumers and developers of information technology, and should have policies and practices for addressing security in both domains:

  • As a consumer of IT, vendors need to be aware of the need for security-related development practices for products, solutions and services used in their Enterprise Computing environments.
  • As a developer of IT for the global marketplace, vendors need to work to understand and address common requirements for the functionality, performance, scalability and security of their offerings.

As an example of a vendor’s approach to security, IBM’s Secure Engineering Framework reflects best practices from across the company and directs its development teams to give proper attention to security during the development lifecycle. This framework is not only limited to development of IT products by the vendor, but can also be used to inform the development of IT solutions by the vendor’s customers. Additional information about IBM’s product security practices is available at IBM’s Secure Engineering Portal.

Product Security Incident Response Team (PSIRT)

A key element of a vendor’s approach to security is its approach to Product Security Incident Response — how it manages the receipt, investigation and internal coordination of security vulnerability information related to its offerings, and how it provides a focal point for security researchers, industry groups, government organizations and vendors to report any suspected product security vulnerabilities.

As an example of a vendor’s approach to incident response, IBM has a global PSIRT that performs these functions and provides a focal point for third parties to report to IBM any suspected IBM product security vulnerabilities.

Staying Current with Security Vulnerabilities

  • Customers of IT should: Understand what products are in use in their organization, monitor each vendor’s support sites for security information such as security bulletins, apply security fixes and updates promptly, and report any suspected vulnerabilities to the vendor. As an example, for IBM products, customers should use the links below to:
  • Vendors and security researchers should report any suspected product security vulnerabilities promptly to the vendor of the software in question. As an example, for IBM products, vendors and security researchers should report suspected IBM product security vulnerabilities to IBM PSIRT.

A Closer Look at Product Vulnerability Statistics

To better understand the numbers of published vulnerabilities for a particular vendor, here are a few points to consider:

1. Normalize the data to understand average defects per product

To put the number of vulnerabilities published by a particular vendor in context, consider how many products the vendor has.

Figure 1: To get a normalized view of product vulnerabilities, this figure shows the average number of vulnerabilities per product (the fewer, the better). As an example, as shown in this figure, IBM compares favorably to both the Top 5 and Top 50 vendors, according to data from CVE Details.

2. Consider what is driving the number of vulnerabilities

Some vendors may only respond to vulnerabilities that are reported by their vendors, customers and third parties. Other vendors also proactively find and fix vulnerabilities. As an example, IBM uses security testing tools and methods, such as threat analysis (see Threat analysis in the software development lifecycle), to proactively find and fix vulnerabilities.


Figure 2: In 1Q2014, about 20 percent of the vulnerabilities that affected IBM products were proactively discovered by IBM; another 20 percent were reported by customers or third parties; the remaining 60 percent were vulnerabilities in open-source and third-party software used by IBM products, according to the IBM X-Force report and IBM PSIRT.

The following people contributed to this article: Lisa Bradley, Ed Flickinger, Bob Sisk, Jim Whitmore

More from Software Vulnerabilities

FYSA – Critical RCE Flaw in GNU-Linux Systems

2 min read - Summary The first of a series of blog posts has been published detailing a vulnerability in the Common Unix Printing System (CUPS), which purportedly allows attackers to gain remote access to UNIX-based systems. The vulnerability, which affects various UNIX-based operating systems, can be exploited by sending a specially crafted HTTP request to the CUPS service. Threat Topography Threat Type: Remote code execution vulnerability in CUPS service Industries Impacted: UNIX-based systems across various industries, including but not limited to, finance, healthcare,…

X-Force discovers new vulnerabilities in smart treadmill

7 min read - This research was made possible thanks to contributions from Joshua Merrill. Smart gym equipment is seeing rapid growth in the fitness industry, enabling users to follow customized workouts, stream entertainment on the built-in display, and conveniently track their progress. With the multitude of features available on these internet-connected machines, a group of researchers at IBM X-Force Red considered whether user data was secure and, more importantly, whether there was any risk to the physical safety of users. One of the most…

X-Force releases detection & response framework for managed file transfer software

5 min read - How AI can help defenders scale detection guidance for enterprise software tools If we look back at mass exploitation events that shook the security industry like Log4j, Atlassian, and Microsoft Exchange when these solutions were actively being exploited by attackers, the exploits may have been associated with a different CVE, but the detection and response guidance being released by the various security vendors had many similarities (e.g., Log4shell vs. Log4j2 vs. MOVEit vs. Spring4Shell vs. Microsoft Exchange vs. ProxyShell vs.…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today