A quickstart guide on vulnerability scanners: how they work and why they differ

Many security software vendors in the industry today have their own container vulnerability scanner product. These scanners can have various implementations and leverage different security vulnerability databases, which leads to inconsistencies in vulnerability detection and scoring (i.e. how severe a given vulnerability might be). This variation often creates confusion for customers who expect consistent vulnerability detection and remediation in their Red Hat container environments.

To understand why these third party vulnerability scanners often produce an overwhelming number of false positives for Red Hat customers that need to be addressed manually, this guide will help to explain some critical factors: important terminology, vulnerability databases and how they differ, and how Red Hat vulnerability scanner certification helps to remediate these discrepancies for Red Hat environments.

CVSS (Common Vulnerabilities Scoring System)

Each vulnerability comes with a score (and a breakdown) that provides details about the potential attack vector and general vulnerability characteristics expressed in the C (confidentiality), I (integrity), and A (availability) base metrics. - (Note that the CVSS metrics do not measure the risk). This is an example of a score you can find associated with a specific CVE:

CVSS:3.0- 9.8/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

The score given to this CVE is 9.8, which is a very high score (meaning a potentially dangerous flaw). This number has been given according to the metric following the scoring number. This is their breakdown:

• AV: “Attack Vector” (Where does the attack come from? In this case N=Network)
• AC: “Attack Complexity” (How hard is it to get into the system from that flaw? In this case L=Low, which means that it’s easy to break in.)
• PR: “Privilege Required” (In this case in N=None)
• UI: “User Interaction” (In this case N=None)
• S: “Scope” (In this case U=Unchanged)
• C, I, A: “Confidentiality”, “Integrity”, ”Availability” (In this case they are all H=Highly compromised)

Why is it important to know this information?

The scoring metrics and the total score for each specific CVE can vary depending on the environment.

Let’s analyze how two different entities can associate different scores to CVEs. One provided by NIST which stores the vulnerabilities in the NVD (National Vulnerabilities Database), and the other from Red Hat (Red Hat Vulnerabilities Database). 

Not surprisingly, the CVSS scores given by these two entities frequently differ. This occurs because the NVD checks the generic information and sets the CVSS metrics that reflect only the vulnerable component issue. The NVD does not check or assess the real risk to the vulnerable artifact that could be included in the component and subsequently used in various products, while the Red Hat Vulnerabilities Database does. Here is an example showing how the same CVE can be associated with different scores:

CVE rated by NIST:                 CVSS:3.0- 8.6/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H

CVE rated by Red Hat:        CVSS:3.0- 7.7/AV:L/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H

We see the score breakdown is almost identical, but the Attack Complexity (AC) is different. NIST gave a ‘Low’ attack complexity, while Red Hat gave a ‘High’ complexity score. This means that it is harder to compromise the system in a Red Hat environment versus environments from other providers. As a result, the Red Hat CVSS score for this particular CVE is lower.

Risk assessment

The National Vulnerability Database, which most scanners use as the main source today, provides a simple qualitative severity score for vulnerabilities, without any incorporated risk assessment. Scanners consuming exclusively NVD security data, without Red Hat security data, will therefore not give information about the risk level of a given security flaw or consider any mitigation already in place on a Red Hat platform.

Red Hat analyzes CVEs in great depth based on how we build, configure, and ship our products. Red Hat leverages CVSS to score base characteristics of a CVE, then works to assess the real risk for the component and the product within which that component is used. For instance, Red Hat checks how the vulnerable component is compiled and what features are enabled or disabled that have an impact on the vulnerable component. This risk assessment is out of scope of NVD, which checks the generic information and sets the CVSS metrics that can reflect only the vulnerable component issue in isolation.

Red Hat Product Security rates the severity of a CVE using four-point scale severity ratings (low, moderate, important, and critical). This scoring system provides a prioritized risk assessment that is meant to communicate the true severity of each flaw associated with it.

Backporting Security Fixes.

Backporting security fixes ensures that Red Hat can deploy automated updates to customers while minimizing risk. We identify the fixes, isolate them from other changes, make sure they do not introduce unwanted negative impact, and then apply these fixes to our previously released product versions.  

The practice of backporting security patches may create false positives when incorrectly detected.  As an example, Red Hat might provide fixes for security flaws out of the most recent version of an upstream software package and apply that fix to an older version of the package we distribute downstream. Scanners that are only looking at the version number of a package and use external general security data (like from NVD) will not necessarily know if a component is vulnerable or not. This is because they do not take into account older versions of packages with backported patches applied. So, if a scanner is used against containers running on a Red Hat platform, but is referring to NVD data, it will detect and flag vulnerabilities that are already patched.

How does RH certification fix this problem?

The Red Hat Vulnerability Scanner Certification has a key objective to work closely with vulnerability scanning vendors and validate how their scanner uses Red Hat security data on Red Hat’s products.

The program requires the vendor to address these main problems by building their scanners using an assessment language that supports Red Hat fixes and refers to CVEs on the Red Hat database as a primary source of truth.

We supply Open Vulnerability and Assessment Language (OVAL) definitions (machine-readable versions of our advisories) that third-party vulnerability tools can use to determine the status of vulnerabilities, even when security fixes have been backported. In doing this, we hope to remove some of the confusion surrounding backporting and make it easier for customers to always keep up to date with the latest security fixes. (The current version is OVAL v2 will soon be replaced to support the evolving security landscape. Please read The Future of Red Hat Security Data to learn more).

Next steps

The vulnerability scanner certification program guarantees that the scanning tool being certified correctly consumes Red Hat’s security data. This, in turn, drastically reduces inaccurate vulnerability detection.

That being said, this certification is not a one-time activity. Maintaining this certification for each version of a given vulnerability scanner is imperative. The scanner vendors must also recertify when new test-harness images are released by Red Hat. This is a continuous and ongoing process and relationship between Red Hat and the vendor for our joint customers.

If you are a vulnerability scanner consumer, and you are having issues addressing all the findings with your scanner, mention the Red Hat Vulnerability Scanner Certification to your vendor or consider using one of the certified scanners listed in our Red Hat Ecosystem Catalog.

If you are a provider of a vulnerability scanner and have not yet pursued certification, review our certification guide to learn how to get engaged.

Further reading

• Vulnerability Walkthrough (series of video sessions covering key vulnerability scanning information)
• Understanding Red Hat Security Ratings
• Demystifying risk using CVEs and CVSS
• Red Hat Vulnerability Scanner Certification
• An Open Approach to Vulnerability Management - Red Hat’s Methodology
• Containers vulnerability risk assessment
• Tutorial on how to process vulnerability scans

Acknowledgements

• Taylor Smith, Senior Engineering Partner Manager
• Vivien Wang, Engineering Partner Manager
• Jeremy West, Senior Manager, Product Security Engineering