Docker Security Scanning safeguards the container content lifecycle

Toli Kuznets

May 10 2016
written by Lily Guo, Toli Kuznets and Nandhini Santhanam

Today we announced the general availability of Docker Security Scanning, formerly known as Project Nautilus. Available today as an add-on service to Docker Cloud private repositories and for Official Repositories located on Docker Hub, Security Scanning provides a detailed security profile of your Docker images for proactive risk management and to streamline software compliance. Docker Security Scanning conducts binary level scanning of your images before they are deployed, provides a detailed bill of materials (BOM) that lists out all the layers and components, continuously monitors for new vulnerabilities, and provides notifications when new vulnerabilities are found.


When you consider the modern software supply chain, it typically includes a number of different development and IT teams in a company coordinating across time zones, stacks and infrastructure to build, ship and run software. The primary concerns of app dev teams are to build the best software and get it to their customer as fast as possible. However, the software supply chain does not stop with developers, it is a continuous loop of iterations, sharing code with teams and moving across environments. Docker makes app portability frictionless and secure by default with a secure platform, controls for secure access and capabilities to secure content. Docker Security Scanning delivers secure content by providing deep insights into Docker images along with a security profile of its components. This information is then available at every stage of the app lifecycle.

Let’s dig into Docker Security Scanning in more detail and walk through how it works.

Docker Security Scanning sits alongside Docker Cloud (and soon with Docker Datacenter) to trigger a series of events once a new image is pushed to a repository. The service includes a scan trigger, the scanner, a database, plugin framework and validation services that connect to CVE databases.


Deep visibility into security profile

The Docker Security Scanning service starts when a user/publisher pushes an image to a repo in Docker Cloud. The scanner service takes the image and separates it into its respective layers and components. Then the components are sent to the validation service to check against multiple CVE databases for not only the package name and version, but also a binary level scan of the content inside the package.

This last step is very important because this approach ensures the package is exactly what it claims it is.

A Docker image is made up of many layers and there can be many components/packages in a single layer and each package having a corresponding name and version number. When vulnerabilities are reported to the CVE databases, they are tied to a package name and specific version number.


Many services do a simple check of the package names against the database of known packages with issues. This alone is not enough as it does not guarantee an answer to the question of “What’s running in my container?” In addition to checking the package names, we do a binary-level analysis of every layer, and match the underlying signatures of each binary to known components and their versions, and cross reference that with a database of known vulnerabilities. This allows us to find components not only listed in the standard BOM (i.e. dpkg -l or yum list installed), but also any statically linked libraries to correctly identify components whose libraries have been patched and backported to a version that was previously vulnerable. This method reduces the rate of false positives that may occur when previously reported packages are remediated without a package version change and also protects against the situation where someone purposely renames a bad package for distribution.

To help protect you, Docker Security Scanning includes support for a broad range of operating systems including all major Linux distributions and Windows Server, languages and binaries.

Once everything is scanned and results returned, the detailed BOM is generated and stored in the Docker Security Scanning database for each image and tag. The results are sent to Docker Cloud to be presented in the UI along with the BOM for each scanned repo tag.


Continuous monitoring and notifications

The ability to scan an image provides insight at a given point in time. Docker Security Scanning goes a step further to make sure your images stay safe with ongoing monitoring and notifications. The Docker Security Scanning database stores the detailed image BOMs and the respective vulnerability status of all the components. When a new vulnerability is reported to a central CVE database, Docker Security Scanning checks our service database to see which images and tags contain that affected package and notify the repo admin via email.

These notifications contain information about the vulnerability itself, as well as list out the repos and tags that contain this vulnerability. With this information, IT teams can proactively manage software compliance requirements by knowing what vulnerabilities impact what pieces of software, reviewing the severity of the vulnerability and making informed decisions on a course of action.


Secure across the content lifecycle

Docker Security Scanning is an exciting addition to the Docker workflow to help companies build, ship and run the safest software possible. When combined with Content Trust, you can guarantee that the software is what you say it is, made by who you say it was and that is hasn’t been tampered with along the way. For example, Official Repos have been using Security Scanning since DockerCon EU in Nov 2015 to understand their vulnerability profile, remediate issues and distribute updated images signed with Content Trust. This feature enabled Docker to work with upstream partners to provide better and safer images for you.


Availability and Getting Started

Docker Security Scanning is available today in Docker Cloud for private repo plan customers for a limited time free trial. You can also see scan results for Docker’s Official Images on Docker Hub as long as you are logged in, regardless of if you are a subscriber or not. Security scanning will be expanding soon to Docker Datacenter and Docker Cloud public repo users.

Try in Docker Cloud:

To try this feature, go to Account Settings > Plans and select the checkbox. Once activated, the three most recent tags for each private repo will be scanned and the resulting BOM displayed in the tags section within 24 hours. Afterwards, Docker Security Scanning will scan your image tag every time you push.

The screenshot below shows the plans page of a user with a 5 private repo plan. The checkbox to opt-in to Docker Security Scanning appears at the bottom of the Plan summary.

We are so excited about this that we are giving every private repo plan customer a limited time free trial for three months starting today.

If you have a Docker Hub account and have never tried Docker Cloud – don’t worry! Your same login credentials work in Docker Cloud. The native integration ensures that your Docker Hub repos display within the Docker Cloud “Repositories” section. Private repo plans start at $7 per month for 5 private repositories and are available within Docker Cloud.

More Resources for Docker Security Scanning:


Learn More about Docker


31 thoughts on “Docker Security Scanning safeguards the container content lifecycle

  1. Hey, is there a way to enable this for an organisation account?

  2. Hi Toli,

    How can I view the security scan on ?

    Love this!

  3. Avatar

    Giampiero Gabbiani

    Hi Toli,
    very interesting article.

    We are testing on premis, a Docker Datacenter based solution for running enterprise application on containers.

    Some questions about this topic:

    – Will be possible to bring such a service on premis?
    – Will be possible to customize the policies according to enterprise specific security rules (our customer has very challenging requirements)?
    – Is this solution based on Notary project or it is a completely new one?

    Many thanks in advance

    • Victor Coisne

      Victor Coisne

      A. on-premise DDC scanning is coming, working on that.

      B. We will have some amount of customization, don’t have it finalized yet, but will definitely listen to customer feedback

      C. Scanning is a separate solution, it hooks into Notary only when you decide to sign images that pass the scans

  4. Avatar

    Stefan Lueders

    Hello !

    Great tool!!!!

    Any chance to be able to install/port it towards local installations not using Docker Hub (we run our own Docker instance…)?

    Cheers, S>>L

    • Docker Security Scanning will be integrated with Docker Data Center in the future.
      We don't have plans to integrate it with other self-hosted local instances yet.

  5. It was really nice to see all those images we depend on heavily being scanned. Not so nice that they had lots of vulnerabilities but it was nice of Docker to offer this service for official images.

    I just can't find that information anymore on Docker Hub. I hope it is a temporary hiccup and we'll see the security scanning results again there 🙂

    • Gio,

      Weird – I can see the Official Images scans on Hub just fine, you just need to be logged in.
      If you are still experiencing problems, please open a ticket with our support and we'll figure out what the issue is.

  6. Hi,
    I am curious about how you guys dealing with the vulnerability? is there a chance you can share more detail?

  7. For Official Images, when a new vulnerability is discovered we reach out to the upstream maintainers or app developers, and apply any available patches and rebuild images as soon as possible.
    We've worked closely with Canonical, for example, to get Ubuntu images cleaned up; and we did the same with Debian and Alpine teams as well.

    If the patch is not yet available, we apply them whenever the upstream gets fixed. For some images, we've created the pull requests to have the fixes be applied upstream so that the fixes benefit everybody.

  8. Is this solution available for private enterprise registries?

  9. May I please ask you to elaborate more on the layers scanning concept? I am submitting an image that was build by apt-get upgrade on one layer then on next few layers I put another repo and upgrade certain packages so they are with higher versions and the final image. But with this layered concept you report this image has vulnerabilities because on the lower layers these same packages are with lower versions although in the final image they are fine!

    • Your observations are the intended behaviour.
      If you have some vulnerable components in the intermediate layers, we will still report them for that layer even if the final image is "free of vulnerabilities".
      It is what it is – the vulns are there, and we show them.
      If possible, use a newer base image that has resolved the vulnerability (we update base images frequently); or make the appropriate modifications if you own the base image as well.

  10. Hi

    After free scan how to proceed with other scan ? where get the further details of it ???

    can I run the security scan on my own created images ????

  11. If you have multiple layers, and one of them has a vulnerability we will report it, even if a different layer overwrites the file so that the resulting binary is different.
    You technically have the vuln in your image, so we report it.
    Is it possible for you to update the actual layer that contains the vulnerability?
    If you are basing on a base layer, we update those as soon as they are fixed, so you will need to rebuild your image.

    • Is there a way to see a list of vulnerabilities at the end? I understand the base layers need to get fixed but maybe we don't want to update them as often. If I update a vulnerable component in another layer then it's been fixed. This final summary list of vulnerabilities would be useful.

      • That's an excellent feature request – reporting all the vulnerabilities is currently on our roadmap, we'll work on getting that out sometime soon.

  12. Avatar

    Georg Sauthoff

    Where should I report Docker Security Scanning service bugs?

    For example false positives.

    Example: currently lists CVE-2016-7543 for bash 4.3.43.

    But I've checked it and the included bash-4.3.43-4.fc25.x86_64 isn't vulnerable.

    See also:

  13. You can report false positives by clicking the "Provide Feedback" link, and sending us the information by email.
    We take false positives seriously, and we'll work to clean them up.

  14. Two month later, CVE-2016-7543 is still reported for library/fedora:latest. Is there any progress in fixing false positives?

    • Ingo,

      We are in the middle of a big push to clean up all the RedHat variants – RHEL, Fedora and CentOS right now.
      So a major cleanup of false positives in RedHat-derivatives is coming.
      About CVE-2016-7543 specifically – isn't it still applicable according to Feel free to email us directly via the "Provide Feedback" link at the top of the scan page.

  15. We have several private repositories in Docker Cloud, but we cannot get vulnerabilities report after images pushed.

    I enabled Firebug to trace response when viewing images tag list, and found error message:
    "Code": 404,
    "Message": "Failed to validate user with error: [Not nautilus enabled]"

    While in another organization, the same Docker ID can view vulnerabilities reports from other private repos.
    Would someone advise why we cannot get vulnerabilities reports here?

Leave a Reply