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.

image03
 

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.

 

dockerimagesecurity
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.

Safeguard your images with @Docker Security Scanning #dockersecurity

Click To Tweet

More Resources for Docker Security Scanning:

 

Learn More about Docker

Feedback

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

  1. Avatar

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

    Reply

  2. Avatar

    Hi Toli,

    How can I view the security scan on https://hub.docker.com/_/ghost/ ?

    Love this!
    David

    Reply

  3. Avatar

    Giampiero Gabbiani

    May 12, 2016 at 12:36 am

    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
    Giampiero

    Reply

    • Victor Coisne

      Victor Coisne

      May 12, 2016 at 2:31 pm

      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

      Reply

  4. Avatar

    Stefan Lueders

    May 12, 2016 at 6:36 am

    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

    Reply

    • Avatar

      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.

      Reply

  5. Avatar

    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 🙂

    Reply

    • Avatar

      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.

      Reply

  6. Avatar

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

    Reply

  7. Avatar

    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.

    Reply

  8. Avatar

    Is this solution available for private enterprise registries?

    Reply

  9. Avatar

    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!

    Reply

    • Avatar

      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.

      Reply

  10. Avatar

    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 ????

    Reply

  11. Avatar

    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.

    Reply

    • Avatar

      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.

      Reply

      • Avatar

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

        Reply

  12. Avatar

    Georg Sauthoff

    March 19, 2017 at 5:37 am

    Where should I report Docker Security Scanning service bugs?

    For example false positives.

    Example:
    https://hub.docker.com/r/library/fedora/tags/25/ 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:
    https://bugzilla.redhat.com/show_bug.cgi?id=1379634
    http://seclists.org/oss-sec/2016/q3/617

    Reply

  13. Avatar

    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.

    Reply

  14. Avatar

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

    Reply

    • Avatar

      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 https://access.redhat.com/security/cve/CVE-2016-7543? Feel free to email us directly via the "Provide Feedback" link at the top of the scan page.

      Reply

  15. Avatar

    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?

    Reply

Leave a Reply

Post Tags
Categories

Related Posts

The Docker Dashboard Welcomes Hub and Local Images

By October 01 2020

Docker Open Sources Compose for Amazon ECS and Microsoft ACI

By September 24 2020

Docker Github Actions

By September 22 2020