New in Checkov: Support multiple development and production environments with new config file

Getting feature requests from the community has been one of our favorite parts of open-sourcing and maintaining Checkov. Among those, one of the most frequently requested was adding a configuration file to store and duplicate command-line interface (CLI) flags, especially long --skip-check lists and --check lists, and standardized settings such as repo-id and soft fail.

In the Bridgecrew platform, this is possible using Code Repository Settings, but we wanted to add more configuration control when using Checkov. We’re excited to announce that with Checkov version 2.0.182, we’ve added the ability to apply configuration options using a config file!


If you run checkov -h, you’ll notice three additions to the configuration options:

  • --config-file to apply configurations from a file
  • --create-config that generates a configuration file from the flags you have set in that command
  • --show-config to view current settings and where they came from

If --config-file is not set, Checkov will search the specified directory, working directory, or home directory for .checkov.yaml.

Checkov version 2.0.182 config file-1

Version-controlled, repeatable configurations

If you’ve ever written long  --skip-check or --check lists, you know how tedious it can be to copy and paste those every time you run Checkov. By adding settings into a separate YAML file, you can automatically and repeatedly reference that list. You can also store that configuration file in a version control system (VCS) for history tracking and collaboration.

Checkov version 2.0.182 config file-2

If you have a central continuous integration (CI) platform with multiple pipelines running Checkov, you can also store multiple configuration files for different use cases. Each pipeline can have a separate config file with its own settings, such as unique skip checks and whether or not to use a hard or soft fail for a CI build.

For example, suppose you have a pipeline to deploy to dev and another to production. In that case, you can have different configurations for each stored in separate config files, which you would then pass in using the --config-file flag. 

Checkov version 2.0.182 config file-3

The inverse is also possible. You can have multiple pipelines with a single config file for more scalability.

Getting started

The easiest way to get started is to run --create-config with some flags you want to set. For example:

checkov --compact --directory test-dir --docker-image sample-image --dockerfile-path Dockerfile --download-external-modules True --external-checks-dir sample-dir --no-guide --quiet --repo-id bridgecrew/sample-repo --skip-check CKV_DOCKER_3,CKV_DOCKER_2 --skip-fixes --skip-framework dockerfile --skip-suppressions --soft-fail --branch develop --check CKV_DOCKER_1 --create-config ./config.yml

That’s pretty overwhelming and would be hard to repeat if you close your terminal without copying it down. Even if it’s programmed into your CI/CD pipeline, it’s not a very easy to digest format to see how Checkov is configured. The result is a file called config.yaml that looks like this:

branch: develop
compact: true
  - test-dir
docker-image: sample-image
dockerfile-path: Dockerfile
download-external-modules: true
evaluate-variables: true
  - sample-dir
external-modules-download-path: .external_modules
framework: all
no-guide: true
output: cli
quiet: true
repo-id: bridgecrew/sample-repo
skip-fixes: true
skip-framework: dockerfile
skip-suppressions: true
soft-fail: true

The next time you run a check on the directory with your Dockerfile, you’ll just have to run:

checkov --config-file ./config.yml

Simplifying policy-as-code to improve workflows

We’re continuing to look for ways to improve the usability and capabilities of Checkov. Help us improve the tool by contributing issues, feature requests, or code commits. Join the discussion on our CodifiedSecurity Slack and start improving your IaC posture with Checkov today!