We have just rolled out an update to the interface of the Red Hat Container Catalog that helps provide the answer to the question of whether or not a particular container image we provide can be considered secure. In the interests of transparency and ensuring customers have as much information as possible 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 how we do it.
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 point-in-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 semi-static selection of software for a specific purpose, subtly change the way flaws need to considered. The security of a container is not based on the concept that it is an isolated system on the host. One cannot expect to download a container image and have it remain secure, without updates, based on this premise. The longer a container remains in use, the higher the probability of exposure to potentially flawed software.
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 bad while new, fresh containers are good. Red Hat intends to provide, through the Red Hat Container Catalog, consistently refreshed container images with the latest security fixes so that they are always fresh, and thus more secure. Because container trust is temporal, we chose to grade container images with a simple time-based rating system rather than a vulnerability-based one, and it is part of what makes up the “Container Health Index”.
The challenges we faced were to make sure that the grade was relevant and easy to understand — that it made sense, at a glance, to anyone looking at it. It had to account for age, but could not account for risk as we have no idea what someone may be doing with any given container (we can’t know if it is performing some critical action or running a critical service). We leave it to the end-user to determine risk based on the information we can provide, so the key is to provide highly useful information that can be easily understood.
So, using the same line of thought that fresh containers are good and old ones are bad, we are using a grading system of A through F to describe the freshness of a container image. The criteria we use are the age of the oldest flaw that is applicable to the container image, and the criticality of that flaw — based on flaws that are rated Critical or Important.
If your container image shows Grade A then there are no unapplied errata that fix flaws of Critical or Important rating. It may have missing errata that fix Moderate or Low flaws, however, because Moderate and Low flaws do not contribute to the grade. An “A” grade is the optimal grade, and ideally you will always be running the latest version, or an “A” grade, container.
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 date the flaw was first fixed in an erratum.
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
The information that is required to generate this grade is based on Red Hat errata published for Red Hat products. As a result, with containers layered on top of a Red Hat container image base, it is difficult to grade anything other than the Red Hat components as we may not know what has been added to or removed from the container or image. When it comes to containers like this, your best bet is to consider 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-provided container images because we have all of the metadata at our disposal to make an accurate determination of what the container image contains — we know what the software is, we know whether or not there are applicable updates, and we know the age of those updates and the impact rating of them. With this information we can generate an easy to understand grade to describe the current age and vulnerability “state” of the contents of any given Red Hat-provided container image. And because these container images consume the same bits that are present in other software that we support, such as Red Hat Enterprise Linux, you know they are trustworthy and provided by Red Hat and that, once an update is released for that product, a refresh of the container image is not far off.
While the container image grading system was primarily implemented to provide customers and users with an easy to understand way to see the initial state of a container, it’s also helpful for us as well since we can easily determine which container images need to be refreshed and which ones, like milk in the fridge, are still safe to consume for a little while longer.
And the best part? The grade is automatically adjusted based on age and new errata releases so it, at least, is guaranteed to be fresh.
Source From: fedoraplanet.org.
Original article title: Red Hat Security: Security Scoring and Grading for Containers and Images.
This full article can be read at: Red Hat Security: Security Scoring and Grading for Containers and Images.