Module 02: Vulnerability management and risk

"The page separates CVEs into three categories: user workloads, platform components, and nodes. That separation is important because remediation responsibility is different for each layer. Your application teams own user workloads; your platform team owns the platform layer and nodes."

"By default, RHACS filters to Important and Critical CVEs that are fixable. This is deliberate. We think it’s reasonable to ask your teams to pick up fixes published by upstream communities, but it’s not practical to ask them to remediate vulnerabilities with no patch available."

"You can view vulnerability data organized by CVE, by Image, or by Deployment. This gives you multiple angles into the same data set depending on what question you’re trying to answer."

"RHACS also scans the RHEL CoreOS nodes for CVEs. Each node is listed with its OS version and container engine. Drill down into any node to see the CVE list and the affected components."

"Expanding a CVE shows the affected component, the version present, the fixed version, and the source — whether it came from the NVD feed or from Red Hat’s own RHSA advisory feed."

"At the top, you can see the OS, when it was last scanned, and which scanner was used. Notice the warning that CVE data is stale — this image’s base OS has reached end-of-life and the distribution has stopped publishing security fixes. That means this CVE count is actually understated. New vulnerabilities are being discovered, but no patches will be issued."

"The findings are sorted by severity. This image’s base was pulled more than five years ago. Time is not kind to images — as vulnerabilities are discovered in components that existed at build time, they all accumulate here."

"Sorting by CVE number brings the most recently disclosed vulnerabilities to the top. This gives you a sense of how actively new findings are being associated with old components."

"This is a memory corruption flaw in SQLite. Under specific conditions, a query can be constructed where the number of aggregate terms exceeds the number of columns available, leading to memory corruption. It is ranked Critical with a CVSS score of 9.8, and it is fixable — a patched version exists."

"RHACS surfaces both the standard NVD entry and Red Hat’s RHSA advisory for the same CVE. The RHSA feed provides Red Hat’s assessment of real-world exploitability, which helps teams prioritize more accurately than NVD scores alone."

"This lower section shows every image in your environment that contains this CVE. If the vulnerability is in a base image layer, a single base image rebuild can eliminate it from all derived images at once. That is the leverage point for container security at scale."

"These are the deployments running right now with containers from images containing this vulnerability. Being actively deployed is itself a risk factor. A vulnerability in a running production container in the Payments namespace is materially different from one sitting in an unused image."

"RHACS displays which cluster, which namespace, how many images are linked, and when the vulnerability was first observed in that deployment. This context is what a security team needs to make a prioritization decision."

"Expanding this entry shows the specific package, the version present, the fixed version, the CVSS score, and the exact path in the container filesystem where the vulnerable library lives. This is the information a developer needs to confirm the fix."

"This is the Risk view. Every deployment in every cluster and namespace, ranked by the likelihood that it will be successfully exploited. RHACS computes this score automatically using the factors I described — vulnerability data, deployment configuration, and runtime activity."

"Deployments with a red dot have runtime activity that could indicate a breach in progress. Those go to the top of your investigation queue."

"Let me walk through why this deployment is ranked first."

"It has serious, fixable vulnerabilities — that contributes to the score. But it also has network ports exposed outside the cluster, which makes it more likely to be attacked from outside. And it is running as a privileged container, which means a successful attacker can access the underlying host network and filesystem."

"Service Reachability shows how exposed this service is — whether traffic can reach it from outside the cluster. Components Useful for Attackers shows what tools an attacker could use after gaining a foothold: shells, network utilities, package managers. RHACS picks these up automatically from OpenShift with no manual configuration. This Risk report is available from the moment RHACS connects to your cluster."

"This shows every process RHACS has observed running inside this deployment since monitoring began. This is the behavioral baseline. Any new process that does not appear here will be flagged as anomalous."

"The Event Timeline is a little hard to find — it is the header bar with 'View Graph' in the label, near the top of the Process Discovery section."

"This shows process activity per pod over time. Each marker represents a process execution event. A healthy container should show a brief spike at startup and then settle into a very small, stable set of processes. Anything unusual after that startup window stands out immediately."

"Clicking an event shows the process name, the timestamp, the UID it ran as, and the container ID. This is forensic data — the who, what, when, and where that incident response needs."

"Five deployments in production have been seen running bash. That is not necessarily a breach, but it is worth investigating. Which of those processes were interactive shells? Which were scripted? RHACS gives you the data to answer that."

"Once you have identified criteria that matters — like bash execution in production payment services — you can create a policy directly from this filter. That policy then runs continuously. RHACS will automatically flag any new deployment that matches, and you can configure it to notify your team or enforce a block."