Vulnerability Management
1. 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. |
2. 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.
3. Definition Review
3.1. CVE
A CVE is a publicly disclosed vulnerability with a unique ID (e.g. CVE-2024-1234), description, and optional CVSS score. See MITRE.
3.2. CVSS
CVSS scores severity from 0.1 (low) to 10.0 (critical): Low 0.1–3.9, Medium 4.0–6.9, High 7.0–8.9, Critical 9.0–10.0. See NIST.
3.3. Red Hat Security Advisory (RHSA)
RHSA advisories notify you of vulnerabilities in Red Hat products with severity, affected products, and patch links. See Red Hat errata guide.
4. Vulnerability Management in RHACS
RHACS categorizes vulnerabilities by workload, platform, and node so you know which team owns remediation. Focus on process—keeping images updated and blocking vulnerable promotions—not fixing every CVE in isolation.
4.1. 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 Vulnerability Management → Results tab
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
-
Click the first dropdown and select Namespace.
-
Click the second dropdown and select name.
-
Then, type patient-portal to filter for your container image.
| 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. |
-
Click the 3 images button
-
Next, click on your image. The quayadmin/frontend:0.1 image.
Here you will see all of the vulnerabilities that the "developers" 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 vulnerabilities present. Speed is security when it comes to containers. |
-
Click the CVE-2020-14343 blue link.
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 Vulnerability Management → Results tab
-
Click the first dropdown and select CVE.
-
Click the second dropdown and select name.
-
Then, type CVE-2021-44228 to filter for the log4shell vulnerability.
Take a look at the results
| You should see a single CVE, image, and deployment are affected. There’s a CVSS score of 10.0 (Yikes!), an NVD CVSS score of 10 (Double yikes!), and an EPSS score around 95%. |
| EPSS is a percentage that shows the likelihood of exploitability. |
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.
-
Select the "1 Deployment" button
How many deployments are impacted? How many images? What would your response be if you had 10+ images with the log4shell vulnerability vs. 1?
4.2. 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
-
Click Vulnerability Management → Results → Platform tab.
| Filter by Cluster name, CVE name, or CVSS severity. Clear filters to return to default results. |
-
Search by Cluster → Platform Type → OPENSHIFT4_CLUSTER
-
Click on CVE-2025-21613 vulnerability
Information on scoring and the RHSA response is available. Also note the impacted operators.
How would you address this issue?
-
Click the "View in Red Hat CVE database"
| 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?
4.3. Node CVEs
You can identify vulnerabilities in your nodes by using RHACS. The same logic that applied to the Platform CVEs applies here.
Procedure
-
Click Vulnerability Management → Results → Platform tab.
-
Find and review the vulnerability we previously looked at RHSA-2025:4025
The libxslt package contains this vulnerability but cannot be found on the node. It can be found in the platform vulnerabilities.
What does this tell you? Does it change your response to the issue?
4.4. More Views
For the sake of time, we will not review all of the extra dashboards, but their functionality is extremely important.
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 anomalies 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.
5. Vulnerability Reporting
Create a vulnerability report for the frontend deployment to notify your developer team.
Procedure
-
Start by clicking on the Vulnerability Management → Vulnerability Reporting tab
-
Click the Create report button.
You will see that creating a report is a three-step process: configure parameters, delivery destination, and review.
The configurable parameters include report name, CVE severity/status, image type, discovery date, and report scope.
-
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
-
When you are done, select the Select a collection dropdown
-
Click Create Collection
-
-
| The collection scope is where you are going to target the frontend application. |
-
Give your collection the name
frontend-collection
-
Click the deployment dropdown and select "Deployments with names matching," then "Exact value of," and type "frontend"
| You can create collection rules by deployment, namespace, and cluster. The collections are set up this way so that you can easily attach policies, vulnerability reports, and notifications by the logical groupings of your organization. |
-
Review the collection
-
Scroll to the bottom of the page and click Save
-
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.
-
Click Next
-
Review your masterpiece and click Create
Let’s review the results!
-
Click the vertical ellipses on the right side of the UI and click Generate Download
-
Then click the "ready for download" link and review the results!
6. 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?
7. Security Exercise: ACME Incident Response
After the payment gateway breach, Morgan asked Sarah to assess whether container hardening would have limited exploitability in ACME’s Socket.IO workloads.
You are participating in the ACME Financial Services security incident workshop. Sarah, a senior OpenShift Platform Engineer, and Morgan from Infosec are responding to a breach in the payment-gateway production namespace. An attacker used a compromised CI/CD service account to exec into the payment-gateway pod, deploy a hidden toolkit (/tmp/.hidden_toolkit/exfil.sh), and beacon outbound to a command-and-control server.
Each ACS module ends with a hands-on exercise that advances this incident response story using RHACS and OpenShift platform tools.
7.1. Scenario
We have a real RCE in python-socketio—CVE-2025-61765. Show me what RHACS sees in the vulnerable demo namespace before we talk image hardening.
Infosec
7.2. Your task
The steps are there for guidance. If you need help, expand the step and compare your approach to the lab commands.
Step 1 — Navigate to Vulnerability Management
-
In RHACS, navigate to Vulnerability Management → Images or Workloads.
Step 2 — Filter to the vulnerable workload
-
Filter to namespace
vulnerable-workload-1and deploymentsocketio-server.
Step 3 — Review CVEs on the image
-
Review critical and important CVEs on the image.
Step 4 — Verify pods and discuss hardening
Verify the vulnerable workload is running:
oc get pods -n vulnerable-workload-1
Discuss with your neighbor: the library still calls pickle.loads() on untrusted data. How does a hardened distroless image reduce blast radius even when the CVE is not yet patched?
