Last updated at Sat, 20 Jan 2024 23:54:04 GMT

A question that often comes up when looking at vulnerability management tools is, “how many vulnerability checks do you have?” It makes sense on the surface; after all, less vulnerability checks = less coverage = missed vulnerabilities during a scan right?

As vulnerability researchers would tell you, it's not that simple: Just as not all vulnerabilities are created equal, neither are vulnerability checks.

How “True” Vulnerability Checks Work

At Rapid7 we pride ourselves in generating “True” Vulnerability Checks, which leverage vulnerability information right from the source, the vendor. Our content is composed of two fundamental components; fingerprinting and vulnerability check data. Researchers spend considerable effort in-order to provide our expert system the capability to accurately identify vendor products such as applications and operating systems. “True” vulnerability checks are executed within our expert system, which utilizes these fingerprints to determine characteristics for each asset it encounters, then comparing these characteristics against our vulnerability check data to identify any vulnerabilities.

Looking at vulnerability check count alone is a meaningless metric as security vendors could easily inflate this number by spreading their check logic across multiple check files. There is only a finite amount of ways to test for the presence of a vulnerability, which is most often prescribed by the vendor.

“Informational” Vulnerabilities

This brings us to what vendors usually describe as “Informational Vulnerabilities.” In the act of doing a vulnerability scan (especially during credentialed scans), a vulnerability scanner gleans a ton of useful information that doesn't necessarily have a CVSS score or real risk, such as installed software, open ports, and general information about what a system is and how it operates.

A common way vendors show these findings to users is by making them “informational or potential” vulnerabilities, categorizing them in the same way they categorize CVSS-scored issues. Most scanners that do this thankfully make it easy to filter out informational vulnerabilities from “real” ones so you can focus on the vulnerabilities with actual risk; however, it still leads to several issues:

  • Users that are new to vulnerability management may not understand what is informational and what isn't, leaving those vulnerabilities in reports and making it appear that their scan is catching much more than others (when in reality the actual vulnerability information is likely very similar)
  • There's no industry standard for classifying “informational” vulnerabilities like there is for CVSS scored “real” vulnerabilities. This leaves it to the vendor's discretion what they consider is pertinent information. There's a huge amount of incidental information that can be gathered from a vulnerability scan; labeling ALL of it as vulnerabilities is impractical, and so is leaving out data by labeling only SOME of the data. It's a lose-lose situation
  • Thanks to the above point, vendors often tout their total number of vulnerability checks as proof of their superiority over each other, without pointing out that a sizeable chunk of these checks are largely irrelevant to prioritizing important vulnerabilities

The Nexpose Approach

Nexpose doesn't have any informational vulnerabilities. For example, identifying that the target has a resolvable FQDN isn't something you will find in our vulnerability list. This is simply a characteristic of the target not necessarily a vulnerability and therefore is found in the asset details page. We know that no one wants to be bogged down with irrelevant vulnerabilities or spend extra time filtering out information they don't need; that's why we focus on making it easy to filter down your assets to identify relevant information and report off of assets based on these filters. Need to see all assets that are virtual machines (yes, believe it or not, being a virtual machine is classified as a vulnerability in some tools!)? Simply create a dynamic asset group to automatically filter your assets down to just virtual machines, a group that updates automatically as new devices are added. Strip away informational vulns, and you'll be surprised with how may real vulnerability checks are left over.

In the end, the number of vulnerability checks isn't much of a differentiator anymore; as those new Sprint commercials say, its 2016, and every enterprise level vulnerability scanner has pretty similar coverage across even uncommon types of assets. Vendors that tout the # of checks as a differentiator often do it because they know that have more informational checks than their competition, and conveniently fail to mention that a sizeable chunk of these would never be used in actual remediation, only slowing down your security team and giving you more 1000 page irrelevant reports.