docker 镜像漏洞扫描

So you’ve crafted a Dockerfile, tested your container in your development workstation, and you’re waiting for the CI/CD to pick it up. Eventually, pre-prod is updated, integration tests passed and functional testers give the green-light. Is it now time to roll-out to prod? Not so fast.

因此，您已经制作了一个Dockerfile ，并在开发工作站中测试了您的容器，然后等待CI / CD对其进行提取。 最终， 预生产产品得到更新，集成测试通过，功能测试人员获得了批准。 现在是时候推出产品了吗？ 没那么快。

Docker图像层继承 (Docker Image Layers Inheritance)

Each batch of files added to an image end up creating a layer that is added to the image. Your Docker image is the concatenation of all these layers in the specific order in which they’ve originally been created.

添加到图像的每批文件最终都会创建一个添加到图像的图层。 您的Docker映像是按照最初创建它们的特定顺序来串联所有这些层的。

The same principle applies when you create an image inheriting a parent image using the FROM directive in your Dockerfile. Your final image will include all the layers of your parent image, augmented with the layers you’ve created yourself.

在使用Dockerfile的FROM指令创建继承父映像的映像时，将应用相同的原理。 最终图像将包括父图像的所有层，并增加您自己创建的层。

What if you use a parent image that also uses another parent image, that may also use another parent image, that finally uses a base image like Ubuntu or Alpine? I guess you see where this is going: You end up inheriting multiple layers of content (i.e. files and executables) from upstream images that you have never seen (let alone controlled) yourself.

如果您使用的父映像还使用了另一个父映像，也可能使用了另一个父映像，最后又使用了Ubuntu或Alpine这样的基础映像，该怎么办？ 我想您会看到这种情况的发生：您最终从上游图像继承了多层内容(即文件和可执行文件)，而这些图像是您自己从未见过的(更不用说控制了)。

Dive (image by author) Dive可视化Docker映像(作者提供的图像)

What if a security vulnerability is included in any of these upstream layers? We’ll look next at how to detect these. But first, what exactly is a security vulnerability?

如果这些上游层中的任何一个包含安全漏洞，该怎么办？ 接下来，我们将研究如何检测到这些。 但是首先，安全漏洞到底是什么？

安全漏洞 (Security Vulnerabilities)

As you can see on the top-left part of the above figure (openjdk:8-jre image), there are multiple layers. On the right part, you can also visualise the files included in that image, courtesy of the Dive¹ tool. Many of those files are executables and, as with all source code we write, susceptible to security issues and vulnerabilities.

如您在上图的左上部分中所见( openjdk：8-jre图像)，有多层。 在右侧，您还可以通过Dive¹工具查看该图像中包含的文件。 这些文件中的许多文件都是可执行文件，并且与我们编写的所有源代码一样，都容易受到安全问题和漏洞的影响。

If those were files in your local filesystem you’d probably run a virus scan and, by all means, do so when feasible. In a broader sense, a virus could be regarded as a security vulnerability itself. However, a computer virus is a type of computer program that, when executed, replicates itself by modifying other computer programs and inserting its own code. When this replication succeeds, the affected areas are then said to be infected with a computer virus².

如果这些文件是您本地文件系统中的文件，则可能会运行病毒扫描，并且在可行的情况下，一定要进行扫描。 从广义上讲，病毒本身可以被视为安全漏洞。 但是，计算机病毒是一种计算机程序，在执行时会通过修改其他计算机程序并插入自己的代码来自我复制。 复制成功后，可以说受影响区域感染了计算机病毒²。

Security vulnerabilities are not viruses.

安全漏洞不是病毒。

Security vulnerabilities exist in, usually, good-intended source code that has a logical or technical flaw resulting in a system weakness that can be exploited to compromise a system. Such vulnerabilities may exist undiscovered for years until someone discovers them, either while actively looking for them or by mere luck.

安全漏洞通常存在于意图良好的源代码中，这些源代码具有逻辑或技术缺陷，导致系统漏洞，可以利用这些漏洞来危害系统。 这种漏洞可能一直存在多年，直到有人在积极寻找它们时或仅仅靠运气发现它们为止，直到有人发现它们为止。

漏洞数据库 (Vulnerability databases)

The responsible thing to do when you discover a vulnerability, which could affect thousands or millions of users, is to report it. First, privately to the owner of the source code, providing enough time for a fix to be pushed out, and then publically to raise awareness for everybody else.

发现可能会影响成千上万个用户的漏洞时，负责做的事情就是报告它。 首先，私下对源代码的所有者，提供足够的时间推出修复程序，然后公开地提高其他所有人的意识。

There are currently many well-established online vulnerability databases that can be used for such public announcements, such as CVE³, NVD⁴, and VULDB⁵.

当前，有许多完善的在线漏洞数据库可用于此类公告，例如CVE³，NVD⁴和VULDB⁵。

Docker静态漏洞扫描 (Docker Static Vulnerability Scanning)

Let’s recap on what we’ve established so far:

让我们回顾一下到目前为止我们已经建立的：

A Docker image consists of layers with files and executables.

Docker映像由具有文件和可执行文件的层组成。 Security vulnerabilities of executable (or library) source code are publicly held in online databases.

可执行文件(或库)源代码的安全漏洞公开存储在在线数据库中。

What if we combine those two points? Could we try to compare the executables found in our layers against the entries of an online vulnerability database to find out if our Docker image is exposed to already-known threats?

如果我们将这两点结合起来怎么办？ 我们是否可以尝试将在层中找到的可执行文件与在线漏洞数据库的条目进行比较，以了解我们的Docker映像是否受到已知威胁的威胁？

Let’s try that next.

让我们接下来尝试。

锚固引擎 (Anchore Engine)

There are many tools available, both open-source and commercial, allowing you to scan your images for known vulnerabilities. Such tools can be run as part of your CI/CD pipeline or can be connected with your images registry and scan new images as they become available. Some of these tools include Clair, Dadga, Nexus Repository Pro, Black Duck, Qualys, Harbor, and Twistlock.

有许多可用的工具，包括开源和商业工具，可让您扫描图像中的已知漏洞。 此类工具可以作为CI / CD管道的一部分运行，也可以与映像注册表连接并在可用时扫描新映像。 其中一些工具包括Clair ， Dadga ， Nexus Repository Pro ， Black Duck ， Qualys ， Harbor和Twistlock 。

For the hands-on part of this post, I’m going to show you how to use Anchore⁶. Anchore consists of a commercial edition (Anchore Enterprise) and an open-source edition (Anchor Engine).

对于这篇文章的动手部分，我将向您展示如何使用Anchore⁶。 Anchore由一个商业版本(Anchore Enterprise)和一个开源版本(Anchor Engine)组成。

Anchore Engine (image by Anchore, Inc.) 锚定引擎(Anchore，Inc.图片)

Anchor has an impressive clientele comprising of companies like Cisco, eBay, Atlassian, Nvidia, and RedHat. The commercial edition provides you with an extra UI, RBAC, and support among others — however, it still uses the underlying, open-source edition, Anchor Engine we’re about to use here.

Anchor具有令人印象深刻的客户群，其中包括Cisco，eBay，Atlassian，Nvidia和RedHat等公司。 商业版为您提供了额外的UI，RBAC和其他支持-但是，它仍然使用底层的开源版本Anchor Engine，我们将在此处使用它。

安装 (Installation)

Anchore Engine is provided as a set of Docker images that can be run standalone or within an orchestration platform such as Kubernetes, Docker Swarm, Rancher, Amazon ECS, and other container orchestration platforms. You can quickly boot up your local version of Anchore Engine using Docker Compose and the following one-liner:

Anchore Engine是作为一组Docker映像提供的，这些映像可以独立运行，也可以在业务流程平台(例如Kubernetes，Docker Swarm，Rancher，Amazon ECS和其他容器业务流程平台)内运行。 您可以使用Docker Compose和以下一种方法快速启动本地版本的Anchore Engine：

curl https://raw.githubusercontent.com/anchore/anchore-engine/master/docker-compose.yaml | docker-compose -p anchore -f - up

The above docker-compose.yaml will create five containers and then try to fetch online vulnerability databases, so it may take a few minutes to complete.

上面docker-compose.yaml将创建五个容器，然后尝试获取在线漏洞数据库，因此可能需要几分钟才能完成。

运行客户端 (Running the client)

Anchor Engine is accessed via a command-line client. You can conveniently run the CLI client via another Docker image:

可通过命令行客户端访问锚引擎。 您可以通过另一个Docker镜像方便地运行CLI客户端：

docker run --rm -e ANCHORE_CLI_URL=http://anchore_engine-api_1:8228/v1/ --network anchore_default -it anchore/engine-cli

You now have a shell to the Anchore CLI client where, for now, you can execute a test command, like anchore-cli --version:

现在，您具有Anchore CLI客户端的外壳程序，在这里，您现在可以执行测试命令，例如anchore-cli --version ：

CLI client working (image by author) CLI客户端工作(作者提供的图像)

签入Docker映像 (Checking-in a Docker image)

Anchore Engine provides with you a vulnerabilities assessment report in two steps. You first need to add an image to be scanned and then you can request the vulnerability report for that image, allowing enough time between those two commands for the image to be downloaded and scanned.

Anchore Engine分两步为您提供了漏洞评估报告。 您首先需要添加要扫描的图像，然后可以请求该图像的漏洞报告，从而在这两个命令之间留出足够的时间来下载和扫描该图像。

In the following example, we will be using an old Wordpress image known to have vulnerabilities.

在下面的示例中，我们将使用已知有漏洞的旧Wordpress图像。

⚠ If you intend to use Wordpress with Docker, make sure you use a recent image instead. ⚠

⚠ 如果打算将Wordpress与Docker一起使用，请确保使用最近的映像。 ⚠

So, time to add our first Docker image with the CLI client:

因此，是时候使用CLI客户端添加我们的第一个Docker映像了：

anchore-cli image add wordpress:4.6.0 && anchore-cli image wait wordpress:4.6.0

With the above command, we add a new image to be analysed and wait until Anchore reports that the analysis is completed.

使用上面的命令，我们添加了要分析的新图像，并等到Anchore报告分析完成。

Image analysis completed (image by author) 图片分析完成(作者提供图片)

查看漏洞 (Viewing vulnerabilities)

To see the discovered security vulnerabilities you can execute the following command:

要查看发现的安全漏洞，可以执行以下命令：

anchore-cli image vuln wordpress:4.6.0 all

In an old image like the one we used above, we can get many, many vulnerabilities. In fact, Anchore reported 1420 known vulnerabilities for our Wordpress testing-image back from 2016:

在像我们上面使用的那样的旧图像中，我们可以获得很多很多漏洞。 实际上，Anchore自2016年以来就报告了1420个有关Wordpress测试图像的已知漏洞：

Anchore: Vulnerabilities report (extract) (image by author) 锚定：漏洞报告(摘录)(作者提供的图片)

As you can see, instantiating a Docker container with the above image is an action bearing high risk. If this was an image you have created to distribute your own application with, you should probably block this release until a vulnerability assessment takes place first.

如您所见，使用上面的图像实例化Docker容器是高风险的操作。 如果这是您用来分发自己的应用程序而创建的映像，则可能应该阻止此发行版，直到首先进行漏洞评估为止。

结论 (Conclusion)

Software is (still) written by humans and humans make mistakes. Don’t let such mistakes haunt your Docker images. Use a Docker image security vulnerability scanner and, at least, be protected from already-discovered security issues. Integrate vulnerability scanning as part of your CI/CD pipeline and establish rules to conditionally block release roll-out when vulnerabilities are discovered.

(仍然)由人编写软件，并且人犯错误。 不要让此类错误困扰您的Docker映像。 使用Docker图像安全漏洞扫描程序，至少要保护它免受已经发现的安全问题的影响。 将漏洞扫描集成为CI / CD管道的一部分，并建立规则以在发现漏洞时有条件地阻止发布发布。

翻译自: https://medium.com/better-programming/scan-your-docker-images-for-vulnerabilities-81d37ae32cb3

docker 镜像漏洞扫描

相关资源：Docker镜像与容器