Grade Your Docker Images with Docker Scout Health Scores
This feature makes it easy for developers to get a security assessment of their images on Docker Hub.
Prefer video? Here it is on YouTube.
The idea of grading is pretty embedded in most cultures. In US schools it’s common to be graded with an A, B, C, D or F where A is the highest grade and F is the lowest. In Europe and other areas of the world E is also possible to get.
Docker will grade your Docker images on the Docker Hub using A to F (E included).
There’s also a weight attached to each policy:
- [20] Fixable critical and high vulnerabilities
- [20] High-profile vulnerabilities
- [15] Supply chain attestations
- [15] Unapproved base images
- [10] Outdated base images
- [05] AGPL v3-licensed software
- [05] Default non-root user
It’s very possible Docker changes this list over time. I’d suggest checking the docs for the latest scoring criteria.
# Is This Feature Available for Everyone?
At the time of this post, it’s currently in limited beta and free to use. If you want to get invited, ask within Docker’s community Slack or DM Docker on Twitter.
It’s quite possible by the time you read this post that it’s generally available, in which case Docker’s plan is to make this a paid feature for Docker license holders.
How Can You Check Your Score?
In order to see your score you need to belong to the Docker Hub organization where the Docker repo resides AND you need at least read-only repo access.
If you meet both of those conditions then if you visit your image on the Docker Hub you should see your score in the “General” tab for one of your repos. You can also find scores on your org’s repo list page and a specific repo’s tag page.
It works for both public and private images but as a reminder, end users or consumers of your public image won’t be able to see this score unless they belong to your org.
# Is It Useful?
My first impression is yes, it’s serving its purpose. I have a public Docker image that I use quite frequently as part of a small open source project.
When I saw that I got a D grade I was immediately taken back. It triggered something inside me to think “hey now, there’s no way I can accept a D, it’s time to improve that”.
Now I’ve scored an A and I can sleep much better at night!
Bumping my Python version improved it from a D to B. Then I set sbom: true in
the GitHub
Action
that builds and pushes the image to the Docker Hub to get an A.
I like video games and generally overcoming challenges. Seeing a poor grade to me is a form of a challenge. Given it provoked me to take an action, I’d say it was a success. As a double win I got to learn something new about SBOM attestations.
If you’re within a bigger org with lots of images I can see this being very helpful to get a quick idea of where you stand. You can see all of your scores at a glance and then start figuring out which ones to improve based on what’s important to you.
Is This a Case of Security Theater?
In case you haven’t heard this phrase, it’s associated with taking security related actions that don’t move the needle around offering “real” protection or providing meaningful value.
Oftentimes you hear this within orgs where they mostly take security actions to click compliance boxes to cover their butts in case they get sued after being compromised.
I don’t think that applies here. All of the callouts and policies I’ve seen so far from the health checks seem reasonable and impactful which put the health of your project in a better spot.
Most critical and a substantial amount of high security vulnerabilities do pose a real threat. Of course you can look into each one to see if it applies directly to your use case but generally speaking if you can choose to have vulnerabilities or not, you’d probably go with not having them.
The unapproved or outdated base images is a nice callout too. It’s a friendly reminder that you probably need to update your base image’s version. That was the case for me. I was using an older point release of the official Python image.
The non-root user check is also nice to see at a glance. It’s a very good idea to run your containers as a non-root user.
Checking against licenses like AGPL v3 is also interesting. You could technically get into legal trouble if you distribute your code that violates a license’s agreement.
# Wishlist
Given this is a new feature from Docker, I’m sure it’s going to change over time based on feedback from folks who are using it.
Here’s my top 4 suggestions:
- A way to get a score without pushing your image to the Docker Hub, this way you can get score updates before pushing your tag to see if your adjustment changed the score. That would be similar to testing your code before you push it to production.
- Getting emailed when your score drops so you can be prompted to take an action.
- Suggestions from Docker on exactly how to improve your score based on your image.
- Ability to see your score through the CLI so you can hook it up to a CI server or perhaps Docker could offer integrations with git hosting providers to generate reports.
The video below goes over this post in more detail and shows the before and after where I improved the score for one of my repos.
# Demo Video
Timestamps
- 0:32 – How does the grading system work?
- 1:02 – Scoring policies and their weights
- 1:43 – How do you get access to it?
- 2:05 – How do you access your score and who can see it?
- 3:04 – Is it useful?
- 4:44 – Is this security theater?
- 6:18 – Going from a D to an A
- 8:27 – A few things I’d like to see, what’s wishlist items?
A very important public service announcement
Çiğdem (Docker Captain) and I recorded a video together about Docker Scout health scores to celebrate international cat day which is every August 8th.
Are you going to try health scores out? What do you think? Let us know below.