With each new security vulnerability, we’re forced to re-examine our current systems and processes. If you’re impacted by OpenSSL or Text4Shell (aka CVE-2022-42889), you’ve probably asked yourself, “Are we using Apache Commons Text (and where)?” or “Is it a vulnerable version?” — and similar questions. And if you’re packaging applications into container images and running those on cloud infrastructure, then a breakdown by image, deployment environment, and impacted Commons-Text version would be extremely useful. 

Developers need contextual data to help cut through the noise and answer these questions, but gathering information takes time and significantly impacts productivity. An entire day is derailed if developers must context switch and spend countless hours researching, triaging, and fixing these issues. So, how do we stop these disruptions and surface crucial data in a more accessible way for developers?

Start with continuously examining images

Bugs, misconfigurations, and vulnerabilities don’t stop once an image is pushed to production, and neither should development. Improving images is a continuous effort that requires a constant flow of information before, during, and after development.

Before images are used, teams spend a significant amount of time vetting and selecting them. That same amount of effort needs to be put into continuously inspecting those same images. Otherwise, you’ll find yourself in a reactive cycle of unnecessary rework, wasted time, and overall developer frustration.

That’s where contextual data comes in. Contextual data ties directly to the situation around it to give developers a broader understanding. As an example, contextual data for vulnerabilities gives you clear and precise insights to understand what the vulnerability is, how urgent it is, and its specific impact on the developer and the application architecture — whether local, staging, or production.

Contextual data reduces noise and helps the developer know the what and the where so they can prioritize making the correct changes in the most efficient way. What does contextual data look like? It can be…

• A comparison of detected vulnerabilities between images built from a PR branch with the image version currently running in production
• A comparison between images that use the same custom base image
• An alert sent into a Slack channel that’s connected to a GitHub repository when a new critical or high CVE is detected in an image currently running in production
• An alert or pull request to update to a newer version of your base image to remediate a certain CVE

Contextual data makes it faster for developers to locate and remediate the vulnerabilities in their application.

Use Docker to surface contextual data

Contextual data is about providing more information that’s relevant to developers in their daily tasks. How does it work?

Docker can index and analyze public and private images within your registries to provide insights about the quality of your images. For example, you can get open source package updates, receive alerts about new vulnerabilities as security researchers discover them, send updates to refresh outdated base images, and be informed about accidentally embedded secrets like access tokens. 

The screenshot below shows what appears to be a very common list of vulnerabilities on a select Docker image. But there’s a lot more data on this page that correlates to the image:

• The page breaks the vulnerabilities up by layers and base images making it easy to assess where to apply a fix for a detected vulnerability.
• Image refs in the right column highlight that this version of the image is currently running in production.
• We also see that this image represents the current head commit in the corresponding Git repository and we can see which Dockerfile it was built from.
• The current and potential other base images are listed for comparison.

Using Slack, notifications are sent to the channels your team already uses. Below shows an alert sent into a Slack channel that’s configured to show activity for a selected set of Git repositories. Besides activity like commits, CI builds, and deployments, you can see the Text4Shell alert providing very concise and actionable information to developers collaborating in this channel:

You can also get suggestions to remediate certain categories of vulnerabilities and raise pull requests to update vulnerable packages like those in the following screenshot:

Find out more about this type of information for public images like Docker Official Images or Docker Verified Publisher images using our Image Vulnerability Database.

Vulnerability remediation is just the beginning

Contextual data is essential for faster resolution of vulnerabilities, but it’s more than that. With the right data at the right time, developers are able to work faster and spend their time innovating instead of drowning in security tickets.

Imagine you could assess your production images today to find out where you’re potentially going to be vulnerable. Your teams could have days or weeks to prepare to remediate the next critical vulnerability, like the OpenSSL forthcoming notification on a new critical CVE next Tuesday, November 1st 2022.

Interested in getting these types of insights and learning more about providing contextual data for happier, more productive devs? Sign up for our Early Access Program to harness these tools and provide invaluable feedback to help us improve our product!

We are now making another update in our security journey, by bringing “docker scan” to the  Docker CLI on Linux. The experience of scanning on Linux is identical to what we have already launched for Desktop CLI, with scanning support for linux/amd64 (x86-64) Docker images. The CLI command is the same  docker scan,  supporting all of the same flags. These flags include the options to add Dockerfiles with images submitted for scanning and to specify the minimum severity level for the reported vulnerabilities.  

Information about the docker scan command, with all the details about the supported flags, is provided in the Vulnerability Scanning for Docker Local Images section in the Docker documentation. Vulnerability reports are also the same, listing for each vulnerability, information about severity levels, the image layers where vulnerabilities are manifested, the exploit maturity and remediation suggestions.  

The major difference with scanning on Linux is that instead of upgrading your Docker Desktop, you will need to install or upgrade your Docker Engine. Directions for installing the Engine are provided in the Install Docker Engine section of Docker documentation, including instructions for several different distros, including CentOS, Debian, Fedora and Ubuntu. And because this is  Linux, we have open sourced the scanning CLI plugin…  Go ahead, give it a try, or take a look at this page for other Docker open source projects that may help you to build, share and run your applications

If you want to learn more about application vulnerabilities, and you missed DockerCon 21, you can go here for a recording of the DockerCon LIVE panel on Security, or watch a great session called ‘My Container Image Has 500 Vulnerabilities.  Now What?’.  Or, look for any other DockerCon recording…  There were all sorts of great sessions on things that you can do to build, share and run your applications.  Or, for more information about the Docker partnership with Snyk, and plans for future partnership collaborations, please check out this blog post by Snyk’s Sarah Conway

In this blog I will show you why scanning Hub images is important, how to configure the Hub pages to trigger Snyk vulnerability scans, and how to run your scans and understand the results. I will also provide suggestions incorporating vulnerability scanning into your development workflows so that you include regular security checkpoints along each step of your application deployment.  

Software vulnerability scanners have been around for a while to detect vulnerabilities that hackers use for software exploitation. Traditionally security teams ran scanners after developers thought that their work was done, frequently sending code back to developers to fix known vulnerabilities. In today’s “shift-left” paradigm, scanning is applied earlier during the development and CI cycles but most organizations have to build their own automation to connect the scan functions to the CI instruments. Yesterday’s release changes this equation and provides built in automated scanning as an integral step within the CI cycle.  

Now you decide which repos to configure for vulnerability scanning to trigger a scan every time you push an image into that repo, and when the scan is completed you can view the scan results in your Hub account. Vulnerability data is organized in the Hub in several different layers: vulnerability severity summary, list of all vulnerabilities, and detailed information about a specific security flaw. The scanning function is available for Pro and Team users, creating a simple method of validation for each image update.

How It Works

Step 1 – Enable Repo Scanning Functions

Enabling repo scanning is a simple, single-click process, but the default setting is for disabled scanning so make sure you turn it on.

Scanning is separately configurable for each repo so you can decide how you want to start incorporating scanning into your team collaboration cycles and application build steps. You can adopt these processes on a smaller scale and over time expand them to the rest of your organization. Conversely, if you decide that the repo that you have been scanning is no longer an active part of your development, you can use the same single-click option to disable scanning.

Step 2 – Run your scans

Once you enable scanning, each time that you push a tagged image into that repo you will automatically trigger a scan.  

Step 3 – View the Results

After vulnerability scanning is completed, you can go to the repo page in the Hub to view the scan results. General Tab of the Hub Repo page includes results summary for all the repo image scans which will show the number of high, medium and low vulnerabilities identified during each scan.  

Clicking on the Vulnerabilities section of a specific tag brings you to the Vulnerability Tab for that tag, which shows the total number of vulnerabilities identified during the scan. Vulnerabilities Tab includes the scan severities summary and shows you the full list of scan vulnerabilities.  

The vulnerability list is organized so that you will see the most critical vulnerabilities first. The higher severity issues are prioritized above the lower ones, and the same severity vulnerabilities are organized in the descending order for the Common Vulnerability Scoring System (CVSS) .  CVSS scores are a published standard for assigning numerical value to the severity of software vulnerabilities. Vulnerability list also includes Common Vulnerabilities and Exposures (CVEs), which are identification numbers for publicly known cybersecurity vulnerabilities as well as name and version of a package containing this vulnerability. If available, the ‘Fixed In’ column includes a higher version of the same package that has the vulnerability resolved. This is a very important part that gives you clear guidance on how to rebuild your image without the vulnerability.  

Next to the ‘Fixed In’ column is a pop-up link to a page on the Snyk website, presenting detailed information about that specific vulnerability.

The little arrow located next to the Severity rating indicates that this vulnerability has dependencies. Clicking on this arrow expands the vulnerability box and displays these dependencies:

Learn More and Try It For Yourself

Hub scanning is already available. Please check the Docker Doc section link below for more information on how to get started and give us feedback: 

https://docs.docker.com/docker-hub/vulnerability-scanning/

To learn more from experts about getting the most from Docker Hub vulnerability scanning, please plan on joining Docker’s Peter McKee and Snyk’s Jim Armstrong for a joint webinar on Wednesday, Oct 15.  Register now!

During this time, we have also learned a lot from our users about ways Docker can help improve developer confidence in delivering apps for more complicated use cases and how we can help   larger teams improve their ability to deliver apps in a secure and repeatable manner. Over the next few weeks, you will see a number of new features delivered to Docker subscribers at the free, Pro and Team level that deliver on that vision for our customers. 

Today, I’m excited to announce the first set of features: vulnerability scanning in Docker Hub for Pro and Team subscribers. This new release enables individual and team users to automatically monitor, identify and ultimately resolve security issues in their applications. We will also preview Desktop features that will rollout over the next several months.   

We’ve heard in numerous interviews with team managers that developer velocity is critical, that automation enables this and that images going into production have to be secure. Last month we launched Docker local image scans as preview in Desktop Edge and today we are releasing vulnerability scanning in Docker Hub. Starting now each time that you push images into Docker Hub, a vulnerability scan will run automatically using the same underlying tooling as our Docker Scan CLI. Once the scan is complete, you can review the scan results in your Docker Hub dashboard. Look out for a deeper dive into the Hub image scanning in the coming days.  

Improved Collaboration and Control

We are also thrilled to start talking to you about Docker’s plans for Docker Desktop and how we are going to add unique improvements for Desktop for Pro and Team users. Starting in November Pro and Team users of Desktop will get additional features and benefits designed to meet the unique needs of teams and of complex use cases, on top of the core features in the free edition. The first feature will provide visibility of Docker Hub scan results directly within the Docker Dashboard for all of your Hub images. In the coming months we will enable users of Docker Context to store and share your contexts with your team from the Desktop via Docker Hub, allowing development teams to collaborate with the same set of contextual details for shared remoted instances. 

For enterprises who want more control over their version of Desktop and don’t want to keep dismissing updates, we will be providing the ability to ‘ignore’ updates in Desktop until you choose to install the new version. Additionally, we allow for centralized deployment and management of Docker Desktop teams at scale through revised licensing terms for Docker Teams. This will allow larger deployments of Docker Desktop to be rolled out automatically rather than relying on individuals to install it on their own.

Finally, we will also extend the Docker enhanced customer support to include Docker Desktop as well as Docker Hub. Docker Pro and Team subscribers will be assured of consistent support from Docker across all offerings in their subscriptions as they build, share and run their containerized applications. 

We will continue to add more Pro and Team features across the entire Docker platform to make developers’ and teams’ lives easier over the coming months.  And of course, we will continue to improve and enhance our core, free offerings. 

 To test Hub scanning today, sign up for a Pro Docker account.   Or,  try the experience locally and run docker scan on your Desktop CLI. If you are interested in Docker Desktop, and what the future holds, then keep an eye on our product roadmap.  If you have questions about deployment licensing or support, please reach out to us.

CTA: 

• Sign up for Docker Hub
• Register for the Webinar: Adding Container Security to Docker Hub with Snyk on October 15th at 10AM PT
•  Join our YouTube Live: Snyk Image Scanning on Oct. 8th at 10AM PT

More info on Docker Subscriptions for Pros and Teams

Integrating security checks into Docker Scan was the driver behind the partnership with Snyk, one of the leading app security scan providers in the industry. This partnership, announced in May of this year, creates a vision for a simple and streamlined approach for developers to build and deploy secure containers. And today, I’m excited to share that the latest Docker Desktop Edge release includes Snyk vulnerability scanning. This allows Docker users to trigger local Docker file and local image scans directly from the Docker Desktop CLI. With the combination of Docker Scan and Snyk, developers gain visibility into open source vulnerabilities that can have a negative impact on the security of container images. Now you can extend your workflow to include vulnerability testing as part of your inner development loop. Triggered from the Docker Desktop CLI, the Snyk vulnerability scans extend the existing, familiar process of vulnerability detection, and allow for remediation of vulnerabilities earlier in the development process. This process of simple and continuous checks leads to fewer vulnerabilities checked into Docker Hub, a shorter CI cycle, and faster and more reliable deployment into production. 

With that, let me show you how it works.

To begin, authenticated Docker users can start by running their scans by entering these Docker CLI commands –

• To find their local image

$docker pull username/imageName

• And run a scan

$docker scan username/imageName

The Docker scan CLI command supports several flags, providing options for running scans 

• --exclude-base flag excludes base image vulnerabilities from the CLI scan results, allowing user to reduce the volume of reported vulnerabilities, and focus vulnerability reporting on their own image updates
• --json flag displays scan results in JSON format
• --dependency-tree flag provides the mapping of image dependencies before listing vulnerability data
• --f, --file flag indicates the location of the Dockerfile associated with the image, extending  vulnerability scanning results using the contents of the Dockerfile to further identify potential vulnerabilities across all the image manifests

You can also add multiple flags  in a single CLI command, for additional flexibility in consuming vulnerability data. Scans return scanned image data, including:

• Vulnerability descriptions
• Vulnerability severities
• Image layer associated with the vulnerability,  including the Dockerfile command, if you’ve associated the Dockerfile with the scan
• Exploit maturity, so you can easily identify which vulnerabilities have a known functioning exploit
• Available suggestions for remediation,  rebuilding if the base image is out-of-date, slimmer alternative images that can help reduce vulnerabilities, or package upgrades that resolve a vulnerability

Invoking scanning through Docker Desktop CLI allows you to iteratively test for new vulnerabilities, while working on image updates, by:

• Making image updates
• Running a scan 
• Discovering new vulnerabilities introduced with the latest updates
• Making more updates to remove these vulnerabilities
• Confirming vulnerability removal by running another scan

You can start taking advantage of this today in the latest release of Docker Desktop Edge.

After you download the new bits, you can get more comprehensive details on the scan functionality in the Docker documentation.

Finally, we have an upcoming webinar that takes you through the inner workings of the enhanced security capabilities in this new release. You can get more information and sign up for the webinar at this link. 

And stay tuned for further updates on triggering vulnerability scans from the Docker Hub.  

Next steps:

• Download the latest version of the Desktop Edge release
• Review the Docker documentation 
• Attend the webinar on Thursday, September 24 at 10:00am PT, Find and Fix Container Image Vulnerabilities with Docker and Snyk

Sign up for a free Snyk ID and Read the Snyk blog to learn more about the integration