Vulnerability Management

Module goals

  • Understand reports in the Vulnerability Management Dashboard

  • Set and manage risk acceptance workflows

  • Create a simple report to email to stakeholders

The locations and size of your panels may vary depending on your screen size and zoom.

Introduction to vulnerability management in RHACS

Vulnerability management protects the software supply chain by preventing known vulnerabilities from being used as entry points. In this lab, you’ll explore Red Hat® Advanced Cluster Security’s vulnerability management features, including reports on widespread or recent vulnerabilities and the security of container images in OpenShift. More important than fixing individual vulnerabilities is maintaining an ongoing process to keep container images updated and prevent the promotion of vulnerable images.

Definition review

You’ll encounter several scores in the following sections. Understanding how vulnerabilities are scored, ranked, and triaged is important.

CVE

A Common Vulnerabilities and Exposures (CVE) is a publicly disclosed cybersecurity vulnerability. It includes a unique identifier (e.g., "CVE-2024-1234"), a description, references, creation date, and optional CVSS score. This system helps track vulnerabilities across software and hardware. Learn more at the MITRE website.

Find out more at the MITRE website.

CVSS

The Common Vulnerability Scoring System (CVSS) is a framework for assessing vulnerability severity. It includes:

  • Base Metrics: Constant characteristics of a vulnerability.

  • Temporal Metrics: Characteristics that change over time.

  • Environmental Metrics: Characteristics unique to the user’s environment.

CVSS scores range from 0.1 (low) to 10.0 (critical). While it helps assess vulnerability risk, it may lack context sensitivity and be prone to misinterpretation. Learn more at the NIST website.

The CVSS score is computed using a formula that combines these metrics, giving more weight to the base metrics. Temporal and environmental metrics adjust the base score to reflect the current threat landscape and specific user environment considerations. The resulting scores are categorized as follows:

  • Low (0.1 - 3.9)

  • Medium (4.0 - 6.9)

  • High (7.0 - 8.9)

  • Critical (9.0 - 10.0)

The structured approach of CVSS allows organizations to assess the risk of vulnerabilities consistently and to make informed decisions regarding vulnerability management and remediation prioritization. However, it does have its drawbacks, such as a Lack of context sensitivity, a static nature, and a potential for misinterpretation, to name a few.

Find out more at the NIST website.

Red Hat Security Advisory (RHSA)

RHSA provides notifications on security vulnerabilities in Red Hat products. It includes an advisory ID, a description of the issue, affected products, severity, and resolution details. This helps users stay informed about necessary updates and patches.

Key components of RHSA:

  • Advisory ID: A unique identifier for the advisory, typically including the year and a sequential number (e.g., RHSA-2024:1234).

  • Description: A summary of the vulnerability, including affected components and potential impacts.

  • Severity: The criticality of the vulnerability, often classified as Low, Moderate, Important, or Critical.

  • Affected Products: A list of Red Hat products and versions impacted by the vulnerability.

  • Resolution: Information about the patch or update that resolves the issue, including links to download the necessary updates.

  • References: Additional resources such as CVE (Common Vulnerabilities and Exposures) identifiers and links to detailed reports.

Find out more at the link: Red Hat website

Vulnerability Management in RHACS

Vulnerability Management has recieved a lot of love over the past year.

Vulnerability management in RHACS has become more focused on the categorizing vulnerabilities by workload so that it can scan RHEL CoreOS and node-level vulnerabilities along with platform and application vulnerabilities. This is because security teams want to understand at what software layer of vulnerability resides so they know what team it can reach out to to resolve a fix.

Rather than focusing on fixing individual vulnerabilities, it’s more important to establish a process for keeping container images updated and preventing the promotion of vulnerable images through the pipeline. RHACS highlights this through the Top Risky Deployments by CVE and CVSS Score, which shows the most at risk deployments in your cluster by displaying container configuration and vulnerability details.

Vulnerability Management - Results

CVEs and numbers will vary due to the updating of vulnerability feeds.

Let’s start by looking at the vulnerability results of those applications that we deployed in the first module.

Go to the the Vulnerability Management → Results tab

02 vuln 00

The Results dashboard will show the results of all of the vulnerabilities on the system to help you analyze risk. Let’s start in the User Workloads tab and find the frontend application.

Procedure

  1. Click the first dropdown and select Namespace.

  2. Click the second dropdown and select name.

  3. Then, type patient-portal to filter for your container image.

02 vuln 01
You will notice that an extra filter (Namespace name "patient-portal") was added to the default filters, showing only the application that the "Developer" built in the Quay module.

  1. Click the 3 images button

02 vuln 02

  1. Next, click on your image. The quayadmin/frontend:0.1 image.

02 vuln 03

Here you will see all of the vulnerabilites that the "devoplers" introduced into the environment from module 0, the setup module.

Since CVE-2017-18342 & CVE-2020-14343 both are critical and are specific to the PyYAML package. This package is a high impact fix for the developers to focus on.

Container OS age and the age of its components are a massive correlating factor to the number of vulnerabilites present. Speed is security when it comes to containers.

  1. Click the CVE-2020-14343 blue link.

02 vuln 04

If you’re focused on a specific vulnerability, it’s very helpful to see all the components it affects. With this dashboard you can see that our response to this vulnerability needs to be targeted, you should reach out directly to the development team that needs that PyYAML package.

As a security team our next step is to inform the development team about these vulnerabilities.

Being able to view individual deployments and their images is essential. With multiple clusters and thousands of vulnerabilities, you’ll have the same workloads spread across different clusters, and you’ll need to dive deep into each deployment.

Go back to the the Vulnerability Management → Results tab

  1. Click the first dropdown and select CVE.

  2. Click the second dropdown and select name.

  3. Then, type CVE-2021-44228 to filter for the log4shell vulnerability.

02 vuln 05

Take a look at the results

02 vuln 06

You should see a single CVE, image and deployment are affected. There’s a CVSS score of 10.0 (Yikes!), and NVD CVSS score of 10 (Double yikes!), and and EPSS score around 95%.

EPSS is a percetage that show the likelihood of exploitability.
Container OS age and the age of its components are a massive correlating factor to the number of vulnerabilites present. Speed is security when it comes to containers.

While we are focusing on the log4shell vulnerability, it is extremely useful to be able to see all of the components affected by that vulnerability.

  1. Select the "1 Deployment" button

02 vuln 07

How many deployments are impacted? How many images? What would your response be if you had 10+ images with the log4shell vulnerability vs. 1?

Platform CVEs

The platform CVEs page provides information about vulnerabilities in clusters within your system. This refers to OpenShift core services and layered products. The goal is to help you understand responsibility and determine the impact.

Let’s go through a simple use case to demonstrate.

Procedure

  1. Click Vulnerability Management → Results → Platform tab.

02 platform 00
You can filter CVEs by entity by selecting the appropriate filters and attributes. You can select multiple entities and attributes by clicking the right arrow icon to add another criteria. Depending on your choices, enter the appropriate information such as text, or select a date or object. The filter entities and attributes are listed in the following table.
Entity Attributes

Cluster

Name: The name of the cluster.

Label: The label for the cluster.

Type: The cluster type, for example, OCP.

Platform type: The platform type, for example, OpenShift 4 cluster.

CVE

Name: The name of the CVE.

Discovered time: The date when RHACS discovered the CVE.

CVSS: The severity level for the CVE. You can select from the following options for the severity level:

- is greater than

- is greater than or equal to

- is equal to

- is less than or equal to

- is less than

Type: The type of CVE:

- Kubernetes CVE

- Istio CVE

- OpenShift CVE
Once you select a filter, you will need to clear it to reture to the default results

  1. Search by Cluster → Platform Type → OPENSHIFT4_CLUSTER

02 platform 01

  1. Click the CVE filter then Click on RHSA-2025:4025

02 platform 02

Information on scoring and the RHSA response is available. Also not the impacted operators.

How would you address this this issue?
02 platform 03

  1. Click the "View in Red Hat CVE database"

02 platform 04
Being able to quickly understand the difference between what is your responsibility to fix and what is Red Hat’s responsibility is one way RHACS is making vulnerability management easier for our users.

How would you implement this fix to the system?

Node CVEs

You can identify vulnerabilities in your nodes by using RHACS. The same logic that applied to the Platform CVEs applies here.

Procedure

  1. Click Vulnerability Management → Results → Platform tab.

02 nodes 00

  1. Find and review the vulnerability we previously looked at RHSA-2025:4025

02 nodes 01

The libxslt package contains this vulnerability but cannot be found on the node. It can be found in the platform vulnerabilies.

What does this tell you? Does it change your response to the issue?

More Views

For the sake of time, we will not review all of the extra dashboards but their functionality is extremely important.

02 moreviews 00

All vulnerable images

This tab shows ALL vulnerability results in a single dashboard.

Inactive images only

Findings for watched images and images not currently deployed as workloads based on your image retention settings

Images without CVEs

Images and workloads without observed CVEs (results might include false negatives due to scanner limitations, such as unsupported operating systems)

Some image formats are not supported by RHACS or are too old to have accurate information. It’s critical that RHACS points these anomolies out.

Kubernetes components

RHACS tries to show vulnerabilities for OpenShift, AKS, EKS and GKE here. However, certain providers do not disclose vulnerabilities associated with their platforms.

Vulnerability reporting

Internal vulnerability reporting improves software security by helping development teams fix issues early, reducing the risk of breaches and failures. This proactive approach promotes a security-focused culture and best practices. Clear reporting channels allow teams to prioritize and quickly address critical vulnerabilities, resulting in a more reliable product and greater user trust.

Next, you will create a vulnerability report for the frontend deployment to notify your developer team.

Procedure

  1. Start by clicking on the Vulnerability Management → Vulnerability Reporting tab

02 vr 00

  1. Click the Create report button.

02 vr 01

You will see that creating a report is a three step process. It requires you to configure the report parameters and the delivery destination, and then you have to review and create your report.

The configurable parameters are the following:

  • Report Name

  • Report Description

  • CVE severity

  • CVE status

  • Image type

  • CVEs discovered since (with a date)

  • And a Report scope.

  1. Fill out the information with the following updates

    • Report Name

frontend-vuln-report

  • Report Description (optional)

  • CVE severity

    • Critical & Important

  • CVE status

    • Fixable & Unfixable

  • Image type

    • Deployed & Watched images

  • CVEs discovered since (with a date)

    • All time

  • Optional columns

    • Check NVD and EPSS Scores

      1. When you are done, select the Select a collection dropdown

      2. Click Create Collection

The collection scope is where you are going to target the frontend application
02 vr 02
02 vr 03

  1. Give your collection the name

frontend-collection

  1. Click the deployment dropdown and select "Deployments with names matching" then "Exact value of" and type "frontend"

02 vr 04
You can create collection rules by deployment, namespace and cluster. The collections are setup this way so that you can easily attach policies, vulnerability reports and notifications by the logical groupings of your organization.

  1. Review the collection

  2. Scroll to the bottom of the page and click Save

  3. Click Next once you are back in the Configure report parameters tab

You WILL NOT set up the email notifier as it’s not needed to view results.

02 vr 05

  1. Click Next

  2. Review your masterpiece and click Create

itsalive

Let’s review the results!

  1. Click the vertical ellipses on the right side of the UI and click Generate Download

02 vr 06

  1. Then click the "ready for download" link and review the results!

02 vr 07

What would you do?

It’s clear that our notification selection and collection process wasn’t the most efficient way to target a single vulnerability.

Before the next module, think about how you’d organize your notifications and collections. Would you use labels or groups? Would you make sure emails are included in the Kubernetes and OpenShift deployment labels to easily reach the right groups?

When sending these communications, keep these questions in mind:

  • What schedule would have the greatest impact when communicating with stakeholders?

  • Who is the intended audience?

  • Should the report focus only on specific severity vulnerabilities?

  • Should it only include vulnerabilities that are fixable?

Summary

giphy

Great job!!

On to risk profiling!