Helping You Better Identify Vulnerabilities in Partnership with Snyk

We are really excited that Docker and Snyk are now partnering together to engineer container security scanning deeply into Docker Desktop and Docker Hub. Image vulnerability scanning has been one of your most requested items on our public roadmap.

Modern software uses a lot of third party open source libraries, indeed this is one of the things that has really raised productivity in coding, as we can reuse work to support new features in our products and to save time in writing implementations of APIs, protocols and algorithms. But this comes with the downside of working out whether there are security vulnerabilities in the code that you are using. You have all told us that scanning is one of the most important roadmap issues for you.

Recall a famously huge data breach from the use of an unpatched version of the Apache Struts library, due to CVE 2017-5638. The CVE was issued in March 2017, and according to the official statement, while the patch should have been applied within 48 hours, it was not, and during May 2017 the websites were hacked, with the attackers having access until late July. This is everyone’s nightmare now. How can we help with this?

Do you know if there are security issues? The joint solution with Snyk and Docker will integrate scanning both on Docker Desktop and in Docker Hub so that developers can quickly check for security issues while they are developing code, in the inner loop, and adding new dependencies, and also the whole team can see vulnerabilities once images are pushed to Docker Hub, the outer loop.

The Snyk scanning will generally provide remediation information for updates that will fix vulnerabilities that are found. You do not have to try to fix all the vulnerabilities all the time, as that is a losing game. There is an ongoing flow of vulnerabilities, and you are always likely to see new ones being added.

The target for your team should be to triage the highest risk issues to see if they apply to you and fix issues with high priority. The Apache Struts vulnerability is an example here, as it provided remote code execution from any server using this framework. These types of vulnerabilities tend to have exploits written quite soon and scripts become available to try to attack them. Other vulnerabilities might not be so critical, as your code may not be configured in a way that makes it vulnerable. If you are unsure better to update sooner though.

For less-critical vulnerabilities, the aim is to make sure that you get fixes updated in your build pipeline and vulnerabilities don’t hang around forever in dependencies that do not get updated. They may not be directly exploitable, but as they accumulate they may allow escalation from another vulnerability or combinations of vulnerable components that may create a larger vulnerability.

As we launch the joint Docker and Snyk scanning features we look forward to helping your team to ship software better, faster and more securely. For more information, check out this blog post by Snyk or read today’s press release.