Adding Container Security Scanning to Your CircleCI Pipeline with Anchore

Docker gives developers the ability to streamline packaging, storage, and deployment of applications at great scale. With increased use of container technologies across software development teams, securing these images can become challenging. Due to container images becoming a regular part of the development lifecycle, security checks for these artifacts need to be woven into an automated pipeline and become a standardized best practice for testing.

Securing container images with Anchore

Continuous integration plays a critical role when we move to building container images. Container images, by nature, are immutable. Meaning, once we build an image, it is unchanged. If we want to make any changes to the application that runs inside the container, we will build another image with the code changes, and then deploy the new, updated container. This decreases development and testing time, and fits in nicely with CI.

One of the core pieces of CI is running tests automatically. When we build container images in a CI pipeline, we should employ a tool that is able to conduct the appropriate level of analysis on the build artifact. Anchore is a service that conducts static analysis on container images, and applies user-defined acceptable policies to allow automated container image validation and certification. This means that not only can Anchore users gain a deep insight into the OS and non-OS packages contained within an image, but they have the ability to create governance around the artifact and its contents, too.

Integrating Anchore scanning in a CircleCI build

In the following examples, we will walk through how to integrate Anchore scanning into a CircleCI build.

Note: these examples leverage the anchore/anchore-engine@1.0.0 orb. Additionally, they require a circleci directory and config.yml file.

Adding Anchore scanning of a public image scan job to a CircleCI workflow

If you need to scan a public image, here is an example where we use the orb to scan the anchore-engine:latest public image.

version: 2.1
orbs:
  anchore-engine: anchore/anchore-engine@1.0.0
workflows:
  scan_image:
    jobs:
      - anchore/image_scan:
          image_name: anchore/anchore-engine:latest
          timeout: '300'

Adding Anchore scanning of a private image scan job to a CircleCI workflow

If you need to scan a private image, here is an example where we use the orb to scan the anchore-engine:latest image in a private Docker registry.

version: 2.1
orbs:
  anchore-engine: anchore/anchore-engine@1.0.0
workflows:
  scan_image:
    jobs:
      - anchore/image_scan:
          image_name: anchore/anchore-engine:latest
          timeout: '300'
          private_registry: True
          registry_name: docker.io
          registry_user: "${DOCKER_USER}"
          registry_pass: "${DOCKER_PASS}"

Adding Anchore image scanning to your container build pipeline job

Here we are building a Docker image from the connected repository, and scanning the image after. As part of the scan, we’ve added analysis_fail: True to the configuration. When this is set to true, the analyzed image will also be evaluated against the default policy bundle that ships with anchore-engine. Should the result of the policy evaluation fail, the pipeline will fail at this step.

version: 2.1
orbs:
  anchore: anchore/anchore-engine@1.0.0
jobs:
  local_image_scan:
    executor: anchore/anchore_engine
    steps:
      - checkout
      - run:
          name: build container
          command: docker build -t ${CIRCLE_PROJECT_REPONAME}:ci .
      - anchore/analyze_local_image:
          image_name: ${CIRCLE_PROJECT_REPONAME}:ci
          timeout: '500'
          analysis_fail: True

Conclusion

Looking at the above examples we can see how seamlessly these scans can be added to our CircleCI configuration in order to gain the benefits of static analysis on container images.

A small tip to keep in mind: we definitely recommend using Anchore policy checks to gain more control over which images you or may not want to allow to progress to the next step in your pipeline. The use case here is oftentimes organizations will want the ability to create governance around the images being built, and only allowed compliant ones to be promoted and pushed to a trusted registry.