Is your Docker container secure? Ask Vulnerability Advisor!

Share this post:

As of May 23rd IBM Bluemix Container Service now provides a native Kubernetes operations experience while removing the burden of maintaining master nodes. Kubernetes itself is based on the Docker engine for managing software images and instantiating containers. Get the details.

Is your Docker container secure? To understand the importance of this question, consider the recent study by Banyan, which raised concerns over security vulnerabilities in official images of Docker Hub.

Additionally, a US State Department Study reported that “80% of attacks leverage known vulnerabilities and configuration management setting weaknesses”.

While Docker brings about great benefits in sharing and reuse of software components packaged as images, these benefits are greatly diminished if the images cannot be trusted. The best opportunities in security remediation are to identify and correct, in real time, any misconfiguration or known vulnerable systems. These reports amplify the importance of discovering and remediating these issues at build and deployment time, as opposed to the more typical post-deployment security checks and audits.

Vulnerability Advisor helps you design secure applications

At DockerCon, IBM announced Vulnerability Advisor – a capability of IBM Containers to discover vulnerabilities and compliance policy problems in Docker images hosted in Bluemix.

Vulnerability Advisor gives container developers a view into their image security properties and gives guidance on how images should be improved to meet common sense best practices and upgrade to known industry fixes. Using Vulnerability Advisor, developers can design secure applications with very little effort.

registry vulnerability

Read on as I describe our approach and capabilities today, and then our future directions.

How Vulnerability Advisor works

No setup required functionality is built into the cloud: Vulnerability Advisor introspects Docker containers without requiring any agents and it integrates with the DevOps life cycle.

Key objectives:

  • No setup required — functionality is built into the Bluemix cloud platform
  • No agents or no guest credentials/access needed by service provider
  • Tamper proof — we don’t rely on embedded agents to perform data collection
  • Support near realtime vulnerability assessment of images as part of the ‘Docker Push’ build process
  • Simple to interpret results

Our Vulnerability Advisor service is a core part of the Container platform. We monitor all images that are pushed to your registry regardless of where they originated or how they got there (pipeline, Docker Hub, CLI, or UI). We then introspect each image to inventory packages, configurations, ports opened, and Docker metadata. This is just a small subset of the deep crawling of images we are able to do with our platform. All this data is stored in its original form as the foundation to run analytics on top of.

Below are some of the things Vulnerability Advisor does for vulnerability and security given the above implementation:

  • Automatically inventory the packages installed on your Docker image and compare them against known vulnerability databases to determine if installed versions have any issues
  • Provide a detailed list of packages with known vulnerabilities and links to remediate those vulnerabilities
  • Initially scanning for Ubuntu security notices based on looking at what the majority of images are in the catalog, but we’ll move to support RHEL, CentOS, etc shortly

Below is a screenshot of the resulting report:

Vulnerability Report

Beyond package vulnerability scanning, we’ve taken some of the best practices around container development, coupled with some lessons learned from IBM’s own internal deployment standards, and created a base set of ‘policies’ that we inspect. Frankly, this is the far more interesting part of the process for me, as this space will evolve, and change. Now, admittedly some of these things are basic items like password expiration should be 90 days, should be greater than 8 characters, etc. We’re testing the waters to see what our clients like / dislike here. None of these ‘violations’ are positioned as blockers in your deployment process. They are an advisor-like alert at this stage, but the introspection we are doing to examine the above, should give you a feeling for the capability we have for data collection, all at image build/push time. Your image is NOT instantiated into production as part of the vulnerability advisor scan.

Example of Vulnerability Advisor policy check

Some of the more interesting policy checks are in the area of what makes sense in a Docker container environment. For instance, if you are a purist, there really is no reason to have an SSH Daemon running in your container. Containers should be immutable and therefore having someone SSH into a running container will only break the development chain of image development. We’re also scanning for FTP,Telnet, RSH. We’re also checking permissions on key files in the event that you do allow multi-users as admin into your container (although not a recommended approach).


A few words on how one fixes the issues when you find your image has vulnerabilities. One of the key foundation principles in DevOps is to have an immutable image build and deploy process. Practically speaking, what that means in this context is that the days of SSHing into your container and patching running software are no longer valid. Containers may live for only a few seconds, or could potentially be scaled up/down as part of load balancing, disaster recovery, and load balancing.

Patching things in a running machine won’t give a durable fix. The container will be redeployed from the image over and over again. Therefore, as I’ve had to learn the hard way, the proper way to remediate these items is by altering your Dockerfile and rebuilding your image. This will become a more detailed blog topic in itself, but here’s an example:

This Dockerfile inherits from a base image and then overlays and replaces the password configuration file with a known ‘compliant’ one. It also updates packages on the image, and finally removes SSH from the image. This is a relatively simple example, but the key design point for developers is that Docker images should be immutable and all changes are from the source Dockerfile. Stay tuned for greater integration and automation in this area.

Looking forward

Going forward, we’ll begin to open up all of the raw data we’ve collected via APIs and high level abstractions. We’ve also previewed this with some key clients and have heard loud and clear the need to have customized policy rules for their enterprise requirements. We’ve already begun work in both of these areas.

We’ll also be surfacing deeper analytics and insight such as looking at default passwords, password versus key authentication, potential open ports and which packages are using those. We can also optimize the image contents by looking for packages which are never used and therefore can be purged.

Stay tuned for updates, as we continue to improve the capabilities of the Vulnerability Advisor! Your feedback is important to help shape how we go forward. Join the conversation!

More stories
May 7, 2019

We’ve Moved! The IBM Cloud Blog Has a New URL

In an effort better integrate the IBM Cloud Blog with the IBM Cloud web experience, we have migrated the blog to a new URL:

Continue reading

April 19, 2019

Reach Out to the IBM Cloud Development Teams on Slack

Get the help you need fast—directly from the IBM Cloud Development Teams and other users on Slack.

Continue reading

April 11, 2019

Permanent Redirect to from

Starting on April 27, 2019, we will be turning on permanent redirects from to All of the same functionality that existed on is still available in

Continue reading