Anchore is a new security scanning tool that can help secure your Docker images. By scanning the images for vulnerabilities, Anchore can help you avoid potential security breaches. To use Anchore to scan your Docker images, first install the tool on your computer. Then, open a command prompt and navigate to the directory where you want to scan your images. To start scanning, type anchore scan . Anchore will analyze the images and report any vulnerabilities it finds. You can then take action to fix the issues, if necessary. For example, you could update the image’s software or patch its security holes. By using Anchore to scan your Docker images, you can ensure that they are safe and secure from attack. ..


You’ll need to build your Docker image and push it to a registry before you can scan it. Anchore uses Dockerfiles when available to identify possible configuration issues but relies on scanning built images when compiling vulnerability lists.

Anchore’s Architecture

Setting up Anchore historically required a dedicated installation of Anchore Engine that operated independently of your image build environment. A separate CLI let you interact with the Engine.

This model requires use of a sequence of CLI commands to register an image with Anchore, start a scan, and access the results. The steps progress Anchore through pulling your image from your registry, generating a report, and making it available for consumption.

Anchore now offers inline scans too. These give you a single command to scan an image and get the results in your terminal. We’ll focus on this capability within this article.

Running the Inline Script

Inline scans are provided by a Bash script hosted on Anchore’s server. Download the script to your machine and make it executable:

Now you can use the inline script to start a scan of a container image:

The first scan may take a while. The script will pull the Anchore Engine Docker image, start a new Anchore instance, and configure PostgreSQL and a Docker registry instance. It’ll then wait for Anchore Engine to start.

 

Once the engine’s running, the target Docker image will be pulled and analyzed. You’ll then see the security report displayed in your terminal. The script will finish by cleaning up the environment and stopping the Anchore Engine Docker container.

Scan Results

Scan results include metadata about the image followed by a table of found issues. Anchore analyzes the image against its configured policies. The default set looks for known vulnerabilities in software packages and potential problems with the Dockerfile used to build the image.

The overall scan result is shown in the Status line above the vulnerabilities table. If you see pass, Anchore is satisfied your image is secure and ready for production use. A fail means you should review the faults and remedy them where possible.

Each found vulnerability includes a rating of its severity from LOW to CRITICAL. Issues with a CVE ID include a link to view the details on the MITRE website.

Generating Report Files

While the default output table works well for human consumption, Anchore can also produce JSON report files which you can archive or feed into other tools. Add the -r flag when you run the scan script to enable this feature.

Anchore will write reports into anchore-reports within your working directory. Each scan produces a set of JSON files pertaining to different sections of the report, such as vulnerabilities, OS packages, and policy requirements.

Inspecting the files gives you detailed information about each finding, providing much more data than the terminal output offers. This extends to CVSS scores, precise package versions, and the vendor’s indication of whether a fix will be produced.

Scanning Saved Image Archives

Anchore can scan directories of saved Docker image archives as well as actual images residing in registries. Export a set of Docker images using docker save, place them in a directory, then use the -v argument to make the Anchore script scan those archives:

Supplying The Image’s Dockerfile

The inline script accepts a -d argument which lets you provide the path to a local Dockerfile. Anchore will check the built image and the Dockerfile, enabling identification of build time issues which could affect the image’s security posture.

Using Custom Policies

Anchore is extensible through the use of custom policy sets. Policies are created from a combination of “gates,” “triggers,” and “actions.” These let you build rules that audit container images against your precise security requirements.

Each policy’s gate produces one of three actions: “go,” a pass that lets the scan proceed, “warn,” allowing the run to continue but with a warning, and “stop,” indicating the image should not be further processed.

Policies are packaged as “bundles” which map sets of rules to registries and images they apply to. You can add a policy bundle to your scan by pass the -b flag when running the script:

This will include your custom policies, giving you confidence the image meets your own security standards.

Here’s a simplistic policy bundle which emits a warning if you don’t provide a Dockerfile to Anchore using the-d flag described above. Supplying the Dockerfile used to build the image gives Anchore the broadest possible coverage so it makes sense to warn when none is given.

This policy applies to the dockerfile gate where Anchore checks whether your Dockerfile meets best practice standard. Anchore executes the no_dockerfile_provided trigger when a scan is initiated in the absence of the image’s Dockerfile.

Conclusion

Anchore lets you generate security reports for Docker images by scanning for outdated software packages, known vulnerabilities, Dockerfile configuration issues, and other possible problem sources. You can write your own policy sets to customize what gets checked and align Anchore with your security standards.

Although Anchore uses a client-server architecture, the project’s “inline” script abstracts away the installation complexity so you can quickly scan local images and get the report straight in your terminal. If you’ll be using Anchore regularly, or scanning images in your CI/CD pipelines, it’s still best to deploy a dedicated Anchore Engine instance, then use the CLI to produce reports. This does require a multi-stage process for each scan but also gives you more flexibility when accessing report sections and syncing vulnerability data feeds.