Improved vulnerability reporting on Quay.io

Quay.io is Red Hat’s hosted container registry service that serves enterprise users, open source community projects, and Red Hat customers worldwide. One of the most used features of Quay.io, besides storing and serving container images, is the comprehensive security vulnerability reporting for any uploaded image. Because Red Hat is committed to making open source software more accessible, this functionality is also available on the free tier, provided by the Clair static vulnerability analyzer project.

Clair allows users to analyze millions of container images and billions of layers, and provides reports in real-time without manual resubmission. In the coming weeks, we’re rolling out a significant update to the Clair backend service that changes the vulnerabilities for Red Hat content reported on Quay.io.

Introduction of CSAF/VEX

Red Hat content includes all container images that either use Red Hat Enterprise Linux (RHEL) or the Universal Base Image (UBI) as the base images, and contain Red Hat components as RPM packages or non-RPM artifacts. The Red Hat Product Security team releases vulnerability data specifically for this content. This data in turn, is consumed by the Clair instance behind Quay.io, which produces the vulnerability reports for container images.

Previously, those kinds of reports were published in the OVAL v2 format. The OVAL v2 format will remain available, but it won’t receive new features, and upcoming products like RHEL 10 won’t have OVAL v2 feeds.

The vulnerability reports for Red Hat content on Quay.io is changing with the introduction of CSAF/VEX vulnerability data in Clair. The Common Security Advisory Framework (CSAF) is a standardized security advisory format that Red Hat is switching to in order to communicate vulnerabilities affecting Red Hat products.

In particular, the Vulnerability Exploitability Exchange (VEX) profile in CSAF format is now used to describe (with greater detail than before) which Red Hat products and which components are impacted (or known not to be impacted) by a specific vulnerability identified by the Common Vulnerability and Exposures ID (CVE).

The new format generally leads to more accuracy in vulnerability reports, which helps users cut through the noise generated by security vulnerabilities originating from base images or language package manager imports.

Changes to vulnerability reports for Red Hat content

With the introduction of CSAF/VEX support in Clair, vulnerability reports for Red Hat content on Quay.io become CVE-centric.

Previously, Red Hat image content vulnerability reports were focused on Red Hat Security Advisories (RHSA). These informed you when specific product components were vulnerable to a known CVE, and how to remediate the vulnerability. A RHSA could encompass multiple CVEs of different severity levels and products affected.

This approach made it difficult to report on the actual severity of a vulnerability, because one report could cover multiple packages (each with different severity levels). Also, when you searched for a specific CVE identifier, you had to look at the synopsis of each vulnerability reported in the Quay.io UI.

But with CSAF/VEX, each vulnerability is shown separately, with one CVE identifier on each line item. This makes it easier to understand which CVE is matched against a particular container image.

This means you’ll see more vulnerabilities reported for a given container image than before, but that’s good! Now you have precise information about vulnerabilities detected in a given container image. The reporting change will affect existing and new images pushed to Quay.io, so you get precise detail on all images.

Unfixed vulnerabilities are now included by default

As part of the format change of Red Hat product security data, unfixed vulnerabilities are shown by default for Red Hat product content discovered by Clair in a container image. These are vulnerabilities for which no security errata from Red Hat exist. This may happen when a patch is still in the works, or the development efforts of a patch are out of proportion with the exploitability of the vulnerability and combination with its severity rating.

Previously, Quay.io’s Clair instance was configured to not report unfixed vulnerabilities due to historical concerns with the growth of vulnerability reports and system scalability. These concerns have been addressed, and Quay.io is now in line with the Red Hat Quay product, which ships Clair and is configured to report unfixed vulnerabilities by default.

In Quay.io, you can hide unfixed vulnerabilities from the report in the UI:

With these changes, Quay.io makes verifying whether a given vulnerability impacts a specific image easier. Many users search by CVE identifier (for instance, CVE-2024-6387). With CVE-centric reporting, the search function in the vulnerability report table reveals whether a given CVE impacts Red Hat container images.

Another improvement is the accuracy in severity grading. Each vulnerability reported by Red Hat comes with its own VEX file, and has a severity grade. The severity grade is then used to report the vulnerability inside Quay.io for the specific CVE matched against a particular package found by Clair. Security reports no longer aggregate severity ratings behind security advisories, but list each vulnerability identified individually, along with its own severity rating. Note that Clair harmonizes severity ratings across different vulnerability sources to aid with prioritization according to this mapping logic.

At first, this may seem like an increase in vulnerabilities for an existing image, but it actually reflects the enhanced precision of reporting. You can put this new information to good use by updating your runtime dependencies, and rebasing on a newer version of your base image to address vulnerabilities. If you host a base image, you can even use Quay.io’s repository notifications on a newly pushed image tag to automate rebuilds of a new base image.