Select a language
That is the question. Yes, I believe William Shakespeare was thinking about container security when he began Act 3 of Hamlet. He probably scanned his Red Hat Universal Base Image (UBI) 8 container with multiple vulnerability scanners, and with "the heart-ache and the thousand natural shocks", noticed each report told him something different. One report said his container had a vulnerability, another indicated the vulnerability was patched, and another didn’t even show the vulnerability. As Hamlet contemplates his fate, it’s no wonder he says: "With this regard their currents turn awry, And lose the name of action." In other words, he rips up the reports and does nothing!
In many ways our customers are experiencing the same vulnerability inconsistencies as Hamlet. But unlike our hero’s tragic fate, there is some good news: Red Hat is working with independent software vendors (ISVs) to help drive vulnerability consistency for both Red Hat and our partners.
The ultimate goal is for customers to have a consistent experience between Red Hat’s Container Health Index and third party vulnerability scanning reports. Simple goal, but it’s a complex problem with three major challenges.
Challenge #1: "Thou canst not then be false to any man!" (Scanning accuracy)
Not all vulnerability scanners are created equal, and identifying if a container is at risk can be complicated. The first step to addressing this challenge is component identification. Identification is a beast on its own because there are several methods for implementation, all with their advantages and disadvantages.
If a solution is able to identify open source components in a container fairly accurately, the next step is for those scanners to appropriately map the vulnerabilities associated with the identified components. This is fairly straightforward but not always completely accurate due to inconsistencies in how some packages try to adhere to the Common Platform Enumeration standard.
The final step in overcoming this challenge, assuming the steps above occur correctly, is to understand if your container is at risk. The correct version of the open source component has been identified and it’s clear that a vulnerability exists, but...
Challenge #2: "Doubt thou the stars are fire." (The confusion about risk & severity)
Even if a container has a vulnerable version of a package, it doesn’t guarantee the container is at risk. It may be confusing, but the National Vulnerability Database’s (NVD) CVSS scoring does not always mean risk. Risk is defined as "an issue that could happen." NVD provides CVSS base scoring, which helps to describe the severity of an issue or the impact of a possible risk, should it happen. But Hamlet wants to know, "will it happen?"
Base scoring is only a third of the equation. It’s important to factor in temporal and environmental scores, which ultimately provide a more precise risk score. In other words, a report that only shows NVD scoring when scanning containers is not enough. For example, take a look at the NVD Scoring Calculator. I like playing around with the dials to create a critical vulnerability score with the base score metrics and then quickly dial it down to a very low or non-existent vulnerability with the temporal and environmental metrics, like so:
The above example is not a rare condition. This could be a critical vulnerability that is present in a container. If the container is deployed in a company’s internal network and it requires privileges to access, and is part of an application that contains no confidential data, the severity would be reduced from a critical 10.0 score to a low 2.0 score.
I’m not saying to ignore all critical vulnerabilities in an intranet, but keep this concept in mind when looking at any vulnerability reports. Understanding the actual risk with base, temporal, and environmental metrics will likely require some manual steps.
Challenge #3: "And call the noblest to the audience." (The distribution authority nuances)
With the concept of backporting, Linux distributions have introduced an authority nuance to vulnerability scanning. For example, take a look at CVE-2019-5736, which scored a 8.6 critical severity from the NVD and affected the docker and runc packages. These packages are part of many Linux and Kubernetes distributions, including Red Hat Enterprise Linux 7 and some versions of Red Hat OpenShift.
Red Hat tested this vulnerability throughout our product portfolio and produced Red Hat Security Advisories (or RHSAs) for every product impacted . In this case, Red Hat produced RHSA-2019:0408 for OpenShift, which included a patch that was then backported to the version of the software shipped with those versions of OpenShift. Patches are then backported to the branch of code that we maintain for the life of the major or minor release.
With this in mind, Red Hat becomes the authority for vulnerabilities found in our products, and third party vulnerability scanners need to consume the following data to provide consistent reports:
Backport identification: A vulnerability scanner must identify the correctly patched Red Hat package version.
Red Hat State: Fixed, not affected, won’t fix? Some products where docker and runc exist, such as Atomic Host 7, are not affected because the location of the runc binaries are on a read-only file system.
Red Hat CVSS Score: Red Hat performs our own CVSS3 evaluation independent of the NVD. For example, in CVE-2019-5736 it was determined that the attack complexity was high, which brought the base score down to a 7.7.
Red Hat Severity: Red Hat uses an industry-standard four point scale rating to assess the severity of a vulnerability using objective criteria. Our ratings are based on that criteria and, while CVSS is used as a guide, it is not the primary determiner of severity.
"Though this be madness, yet there is method in't."
The good news is Red Hat provides all of this information in an Open Vulnerability and Assessment Language (OVAL) feed especially useful for security scanning partners who need this data for high volume commercial consumption.
We recently enhanced the OVAL feed to version 2, which includes new features like product streams and unpatched feeds, and are continuing to evolve it based on customer and partner feedback. With these updates, our security ISV partners can now understand if Red Hat has indicated whether a product is affected by a particular vulnerability. Typically, if a vulnerability does not exist in the feed, then it usually means that the product is not affected by that vulnerability.
"All this can I truly deliver"
Okay, maybe Shakespeare wasn’t actually thinking about vulnerability consistency. However, the concept of vulnerability was certainly present throughout Hamlet, and there’s no question that vulnerability is also top-of-mind for our partners. But while Hamlet faced his vulnerabilities alone, Red Hat and our partners are working together to help deliver vulnerability consistency to customers.
For questions or feedback regarding vulnerability scanning, please contact Red Hat’s Product Security team.
About the author
Dave Meurer currently serves as a Principal Solution Architect on the Red Hat Global Partner Security ISV team, where he owns technical relationships and evangelism with security independent software vendor partners of Red Hat. Before joining Red Hat, he spent nine years in the Application Security industry with Synopsys and Black Duck, where he served in similar roles as the director of technical alliances and sales engineering.