If you’re like most people, you probably use Docker to deploy applications and services. But what if you want to secure your Docker images? Anchore is a great tool for doing just that. Anchore is a security platform that helps you securely scan Docker images for vulnerabilities. It’s easy to use and can help you detect potential issues with your applications and services before they cause problems. To use Anchore, you first need to install it on your computer. Then, you need to create an Anchore account. Once you have an account, you can create a new image or update an existing image with Anchore support. Once the image has been scanned with Anchore, it will be ready for use. You can then use it to deploy your applications and services without any worries of security issues.
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.
