Warning message

Log in to add comments.

Security Scoring and Grading for Container Images

Vincent Danen published on 2017-04-25T16:26:09+00:00, last updated 2017-05-12T00:57:17+00:00

We have just rolled out an update to the interface of the Red Hat Container Catalog that attempts to answer to the question of whether or not a particular container image available in the Container Catalog can be considered secure. In the interests of transparency providing as much information as available to deploy the right container image for their needs, we are excited about these new capabilities in the Red Hat Container Catalog and wanted to give a little insight on our rationale.

Vulnerability scoring and rating is nothing new in the security ecosystem. We rate the severity of vulnerabilities using our four-point security rating scale where an individual flaw can be rated as Critical, Important, Moderate, or Low. Security errata (RHSA) that are released also are assigned an impact rating based on the highest impact rating of the flaws being fixed in the erratum. These ratings are based solely on the merit of the flaw itself, without any concept of possible impact over time (for example, a Moderate-rated flaw remains Moderate forever because the flaw itself is being rated). While exploitability comes into account when the flaw rating is assigned (in terms of whether it is wormable, remotely exploitable, locally exploitable, etc.), we don’t look at the risk of exploitation over time when assessing it.

Container images, being a static selection of software for a specific purpose, subtly change the way flaws should be rated. The security of a container image is not based on the concept of an isolated system on the host. Users should not expect a container image to remain secure indefinitely. The older a container image, the higher the probability of it containing a security exposure.

Curtis Yanko from Sonatype, during a talk at Red Hat Summit 2016 entitled "Secure Your Enterprise Software Supply Chain with Containers" was quoted as saying that "code ages like milk, not like wine." When we were looking at how to rate or score container images, we felt that this explained it quite well: containers age like milk, not like wine. Old, stale containers are much more likely to contain security risks, while new, fresh containers are less likely. The Red Hat Container Catalog (or more specifically the “Container Health Index”) will rate the container images based on known security flaws and the length of time the software in the container images is exposed to those flaws. Because container trust is temporal, we chose to grade container images with a simple time-based rating system rather than just a vulnerability-based one.

The challenges we faced were to make sure that at a glance the grade was relevant and easy to understand. It had to account for known security exposures and associated age, but could not account for individual users’ relevant risk as we do not know what individual users may be doing with any given container (we can’t know if it is performing some critical action or running a critical service). Each user needs to determine risk based on the Container Health Index, their use-case and any other information available to them.

So, using the line of thought that fresh containers are better than older ones, we use a grading system of A through F to describe the freshness of a container image and associated security exposures. Specifically, the age and the criticality (rated Critical or Important) of the oldest flaw that is applicable to the container image.

As container images age, the scores get worse:

  • Grade A: This image does not have any unapplied Critical or Important security errata
  • Grade B: This image is affected by Critical (no older than 7 days) or Important (no older than 30 days) security errata
  • Grade C: This image is affected by Critical (no older than 30 days) or Important (no older than 90 days) security errata
  • Grade D: This image is affected by Critical (no older than 90 days) or Important (no older than 12 months) security errata
  • Grade E: This image is affected by Critical or Important security errata no older than 12 months
  • Grade F: This image is affected by Critical or Important security errata older than 12 months
  • Unknown: This image is missing metadata required to calculate a grade and cannot be scanned

For example, a Grade A container image does not contain known unapplied errata that fix Critical or Important flaws, although the container image may have missing errata that fix Moderate or Low flaws. Ideally you will always be running Grade A containers.

Container images of Grade B may be missing errata that fix flaws of Critical or Important rating, however no missing Critical flaw is older than 7 days and no missing Important flaw is older than 30 days. The number of days is based on the initial date an erratum was released to fix the flaw.

Currently, the information that is required to generate this grade is based on Red Hat errata published for Red Hat products that are available in the RPM packaging format. Containers that include other software layered on top of a Red Hat RPM-based base layer are not included in the grade. In this case, you will need to consider the possible impact of the ungraded components with the underlying container image’s grade and the age of the container itself to determine what is acceptable for you.

While we would love to provide similar ratings to all container images, we currently only rate Red Hat RPM-based container images because of the data available for analysis. We hope to continue to build on the breadth of analytics available on the Red Hat Container Catalog.


About The Author

Vincent Danen's picture Red Hat Community Member 70 points

Vincent Danen

Vincent Danen lives in Canada and is the Vice President of Product Security at Red Hat. He joined Red Hat in 2009 and has been working in the security field, specifically around Linux, operating security and vulnerability management, for over 20 years.