Refreshing the Data
Almost a year ago we looked at the frequency with which some of the most popular images in the Docker registry are updated and compared the frequency of base image (alpine, debian, etc) updates with that of popular non-OS images. We found that while updates to base images came in around once a month, non-OS images updated much more frequently - up to eight to ten updates in the case of the widely used node:latest and php:latest packages.
We learned that while all official images should follow DockerHub best practices and should, therefore, be well maintained it is clear from our historic data that many images can be updated infrequently and carry security vulnerability for many weeks. Understanding these gaps in the update is crucial to a comprehensive and container and application security policy, so we decided it was time to take a second look.
Using Anchore Cloud (anchore.io) makes it easy to check the update history of each image:
This lets us easily see the image creation date as well as the date of the most recent Anchore analysis.
The Anchore service continually polls DockerHub and when an update to a repository has detected the list of tags and images are retrieved and any new images are downloaded and analyzed. In addition, Anchore scans images on a regular cadence to ensure that the results of each scan include the latest CVEs and other known vulnerabilities.
We went ahead and pulled the data from the last 18 months for the library/debian:latest images from the database:
Our last analysis was in September of 2017 you can see that since then updates have become more infrequent. We observed in September that while a monthly cadence can seem ideal, what really matters is the timeliness of updates, particularly updates that fix new critical vulnerabilities. With updates coming less frequently (as seen above) this image becomes less likely to have rapidly addressed any issues that may have arisen.
Users of these base images need to be proactive about their own image fixes during these periods to avoid exposure. Tools like Anchore.io allow users of images to subscribe to the results of each Anchore CVE analysis, an analysis that is conducted regularly in-between image updates and well as immediately after updates occur.
Update Frequency - Most Popular Images
Let’s look at the relative update frequency across popular base images:
We see a similar pattern across the major operating system repositories. None have a fixed update schedule, and while some such as Ubuntu and Oracle Linux are consistent, repositories like Fedora and Alpine can go up to four months without an update!
As we pointed out in our previous post on this topic, these gaps do not immediately imply vulnerabilities. Lightweight operating systems like Alpine and BusyBox require less maintenance due to the relatively small number of packages and therefore potential vulnerabilities. However, if an image hasn’t been updated it is always worth analyzing and confirming the image you are using for production applications is still protected.
An encouraging pattern to look for is present in the Ubuntu and Oracle Linux update timings as well. In addition to the semi-regular monthly updates, updates are pushed at seemingly random times throughout the month. These updates each represent opportunities for the various teams to address new security concerns in a timely fashion. Anchore’s regular post-update scans serve to confirm this to be the case.
Moving on to some popular non-OS images we see a much greater update frequency. The increased complexity in the images necessitates these shortened update cycles and ideally, there is also an update that follows soon after the underlying base image is updated. This is not always the case our analysis shows that some applications are not rebuilt for several weeks or are rebuilt on top of an older base image.
Our assessment from September holds true today. While all official images should follow DockerHub best practices and be well maintained many images can be updated infrequently and carry security vulnerabilities for many weeks.
The timing of an image update can be an indicator of the health of the image, but the content of an image is even more important. Check out the Anchore Cloud to explore image contents, update timelines, and vulnerabilities as well as subscribe to the analysis of the images you use every day.
If you'd like to do this scanning on-prem, check out the open source anchore-engine.
For a great follow-up and to help understand the best course of action to take when it comes to determining how often you update the images your applications rely on, check out Just because they pushed doesn’t mean you need to pull.
