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

X-Force Prevents Zero Day from Going Anywhere

8 min read - This blog was made possible through contributions from Fred Chidsey and Joseph Lozowski. The 2023 X-Force Threat Intelligence Index shows that vulnerability discovery has rapidly increased year-over-year and according to X-Force’s cumulative vulnerability and exploit database, only 3% of vulnerabilities are associated with a zero day. X-Force often observes zero-day exploitation on Internet-facing systems as a vector for initial access however, X-Force has also observed zero-day attacks leveraged by attackers to accomplish their goals and objectives after initial access was…

8 min read

Patch Tuesday -> Exploit Wednesday: Pwning Windows Ancillary Function Driver for WinSock (afd.sys) in 24 Hours

12 min read - ‘Patch Tuesday, Exploit Wednesday’ is an old hacker adage that refers to the weaponization of vulnerabilities the day after monthly security patches become publicly available. As security improves and exploit mitigations become more sophisticated, the amount of research and development required to craft a weaponized exploit has increased. This is especially relevant for memory corruption vulnerabilities.Figure 1 — Exploitation timelineHowever, with the addition of new features (and memory-unsafe C code) in the Windows 11 kernel, ripe new attack surfaces can…

12 min read

Direct Kernel Object Manipulation (DKOM) Attacks on ETW Providers

17 min read - Overview In this post, IBM Security X-Force Red offensive hackers analyze how attackers, with elevated privileges, can use their access to stage Windows Kernel post-exploitation capabilities. Over the last few years, public accounts have increasingly shown that less sophisticated attackers are using this technique to achieve their objectives. It is therefore important that we put a spotlight on this capability and learn more about its potential impact. Specifically, in this post, we will evaluate how Kernel post-exploitation can be used…

17 min read

Dissecting and Exploiting TCP/IP RCE Vulnerability “EvilESP”

10 min read - September’s Patch Tuesday unveiled a critical remote vulnerability in tcpip.sys, CVE-2022-34718. The advisory from Microsoft reads: “An unauthenticated attacker could send a specially crafted IPv6 packet to a Windows node where IPsec is enabled, which could enable a remote code execution exploitation on that machine.” Pure remote vulnerabilities usually yield a lot of interest, but even over a month after the patch, no additional information outside of Microsoft’s advisory had been publicly published. From my side, it had been a…

10 min read