Vulnerability Management in ACS

Vulnerability Management main panel

Let’s start with Vulnerability Management, a familiar topic for most security teams.

The overview provides several important reports - where the vulnerabilities are, which are the most widespread or the most recent, where my Docker images are coming from, and important vulnerabilities in OpenShift itself.

More important than fixing any one vulnerability is establishing a process to keep container images updated and to prevent the promotion through the pipeline for images that have serious, fixable vulnerabilities.

In the upper right, you’ll see buttons to link you to all policies, CVEs, and images, and a menu to bring you to reports by cluster, namespace, deployment, and component.
Point out the Top Riskiest Images panel in the upper right

For the following sections, please note that the order in which the images appear or the number of components affected may vary depending on the version of the demo app (changes prone).

Image overview and image details

In Top Riskiest Images panel, click on VIEW ALL button. Now you will see that the images are listed here in order of risk, based on the number and severity of the vulnerabilities present in the components in the images.

Lets see it:

We can see the images which are more exposed. Not only we can see the number of CVEs affecting the images but which of them are fixable. You can click and get information about the CVEs and the fixable ones.
In the Top Riskiest Images, click on #4, mastercard-processor:latest.

if you don’t have the exact image in the Top Riskiest Images, go to "View All" button, and filter by the name of Mastercard processor.

RHACS built-in vulnerability scanner breaks down images into layers and components - where components can be operating-system installed packages, or dependencies installed by programming languages like Python, Javascript, or Java.

The Image Summary provides the important security details of the image overall, with links to the components. For example, in the DETAILS & METADATA → Image OS panel, the information you see there tells you that this image has a serious security problem - the base image was imported several years ago (Debian 8 - 2015).

You can also see, at the top, the warning that CVE data is stale - that this image has a base OS version whose distribution has stopped providing security information on, and has likely stopped publishing security fixes for.

At the bottom, the Image Findings section focuses on Fixable vulnerabilities, sorted by CVSS.
Under the Image Findings section, Click on Dockerfile tab:

The Dockerfile tab view shows the layer-by-layer view and, as you can see, the most recent layers are also several years old.

Time is not kind to images and components - as vulnerabilities are discovered, RHACS will display newly discovered CVEs.

Scanning images for vulnerabilities

By default information about vulnerabilities is show for all the images:

Active images, which are those images that are deployed.
Inactive images, which are those images that are not deployed.

Only active images will be scanned for vulnerabilities. If we want to scan inactive images we will need to mark the image as watched, so you will need to click on Manage Watches:

Add the inactive image you want to scan for vulnerabilities:

Filtering vulnerabilities scans

Using the search box we can filter the results for the vulnerabilities scan:

As usual que can use some tags to filter, as CVE, CVE Type, …

We can use regular expresions as well. For instance, we are not usually interested in inactive images vulnerabilities because there is no deployment using it. For this reason we are not probably interested in checking the vulneratilities for the inactive images. We can filter them using Deployment r/.+ as filter. That filter means to list all the images where the deployment field is not empty, i.e. active images:

As you can see only the active images are displayed to check the vulnerabilities.

Image CVE Vulnerability Analysis

Click back to the Fixable CVEs tab.

The CVE list for each image focuses on the severe - CVSS >7 - and the “fixable,” where the upstream package maintainers have published a fix.
We don’t think it’s practical to ask your teams to fix Linux or Javascript - but we think it’s reasonable to ask them to pick up fixes published by those communities.
Click on a Fixable CVE in the list, like CVE-2018-14618

This CVE for example is very serious - scoring 9.8/10 - and fixable.

It’s a vulnerability in curl and libcurl - and these packages are present either because it was part of a base image, or it was deliberately added by a developer in one of the Dockerfile layers.

RHACS scanner uses to fetch and update the vulnerability definitions from http://definitions.stackrox.io/. On the other hand collector-modules.stackrox.io is the other FQDN that will be used in online mode. These two are used by Central in RHACS to fetch vulnerability details and collector modules.

Image CVE correlation with Deployments

All of this CVE detail is well and good, but it’s a bit noisy.

How do we judge the true risk - which vulnerabilities are likely to be exploited?

In other words. Which vulnerabilities do we really have to fix first?

RHACS can use other sources of information in OpenShift to judge the risk that a given vulnerability would be exploited, and hence to set priorities for fixes.

The first risk factor - is the vulnerable component actually in a running deployment?

Click on the 6 Deployments button in the Related Entities column on the right.

These are the five deployments running right now with containers that come from images with this vulnerability present. “Up and running” is a risk factor - vulnerabilities are only going to be exploited if they’re in a running container somewhere in the cluster.

We display the critical information here - so you can see that we have this present in the Production cluster, in Namespaces like Payments, which starts to provide context to the security team.

The last column on the right is the Risk priority - which RHACS has already determined from configuration and runtime activity in the deployment. So - of these five deployments, the visa-processor is most likely to be exploited. How is this determined?

Continue to the next section - Risks for find out!