#How to Security Scan Docker Images With Anchore – CloudSavvy IT

Anchore Engine is an open-source scanning tool that assesses the security of your Docker images. An Anchore report gives you insights into outdated package versions and lurking vulnerabilities in dependencies.

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:

curl -s https://ci-tools.anchore.io/inline_scan-latest -o anchore.sh
chmod +x anchore.sh

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

./anchore.sh -r alpine:latest

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:

docker save my-image:latest -o docker-images/my-image
./anchore -v docker-images

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.

./anchore.sh my-image:latest -d /dockerfiles/my-image

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:

./anchore.sh -b policy-bundle.json

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.

{
    "action": "WARN",
    "comment": "No Dockerfile given!",
    "gate": "dockerfile",
    "params": [],
    "trigger": "no_dockerfile_provided"
}

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.