Announcing Checkov: Prevent cloud misconfigurations during build-time

Checkov by Bridgecrew

Today we are introducing Checkov, a new open-source project for cloud infrastructure security.

Why? Because we’re all infrastructure developers

In one of my previous roles, as a data scientist at Fortscale Security, I had the privilege of rebuilding our too-complex data processing framework. I was tasked with performing research and architecting a secure and failsafe method to execute machine-learning algorithms at scale. As our company matured, utilizing more and more data sources, I also took on the responsibility of ensuring data wasn’t only routed to the right processing task, but also that it remained secure from potential compromises.

Although we were never officially in the platform team or named security architects, by writing code that defined resources and resource utilization, my fellow data-scientists and I were de-facto provisioning infrastructure as part of our application logic.

In retrospect, I realize this was the part of a larger trend — every single developer on my team today at Bridgecrew is an infrastructure developer, as well as a solution architect or backend developer.

Building secure development workspaces

Most cloud providers have adopted an API-first approach to support the rapid expansion and growth of our growing cloud footprints. As a result ,it’s now much easier to build visibility and enforce security best practices into our cloud-native architecture. AWS API already enables the simple creation and invocation of corrective remediations and preventive guardrails.

But wait, what about Terraform?

Often, we turn to automation to help streamline the implementation of those best practices and the response to detected security events. Most of our existing customers use Terraform to programmatically plan and update their cloud infrastructure. Unfortunately, this automation doesn’t always make our lives easier.

If you’ve ever tried to actually use AWS API and put together a plan to reduce the number of misconfigurations and security risks in your AWS account, you’ve probably found that it’s not as easy as it should be (or we would like it to be). You have to implement a benchmark framework, using commercial, AWS-only, or open-source tools, and then find and fix individual misconfigurations, using AWS Console/APIs/Lambda. By this point, your team’s Jira backlog has probably doubled in size. Once you’ve done these steps, it’s inevitable you’ve woken up the next morning to find some of your remediations have been overridden by a Terraform CI/CD nightly run, or worse yet, that unvetted changes committed by developers now cause confusing mismatches between your provisioned infrastructure on AWS and their latest state in Terraform code.

Any of this sound familiar? That’s why we built Checkov.

Checkov — a new open source project that can help

We built Checkov to help developers write more secure infrastructure-as-code, by finding and flagging known security and compliance misconfigurations in Terraform code files (coming soon for CloudFormation — stay tuned). We started with 50 built-in policies that cover encryption, network, backup, and IAM compliance and security configurations for AWS, GCP, and Azure cloud providers. We strongly encourage fellow developers to contribute their checks using a fast-lane PR confirmation protocol.

Checkov is 100% open source under the Apache-2.0 license. You’ll quickly see we chose to write Checkov in Python (woohoo!). The main reason is we found Python is still the most commonly known language between our customers and it was easy enough to write security policies-as-code in it.

Checkov can run locally as a CLI and print a color-coded report. It also enables you to author custom policies (contributed by Jerome, Thanks!) and suppress accepted risk.

The optimal flow to run Checkov is at the pre-commit (Contributed by Dmitriy, Thanks!). This way the Terraform code that has a potential risk will not be committed into the git repo.

An additional deployment flow that I personally like is to use Checkov as part of a CI/CD pipeline.

In this flow, each infrastructure change is scanned by Checkov as part of a pull request that is triggered by a CI system (like Jenkins or CircleCI).

We’ve integrated Checkov with Jenkins and enabled a full test results reporting, using JunitXml output format.

Enough said—let’s get started!

Start by deploying Checkov locally and scanning a few standalone Terraform folders and files.


pip install checkov

Configure an input folder

checkov -d /user/tf

or a specific file

checkov -f /user/tf/

View result

Passed checks: 2, Failed checks: 1, Skipped checks: 1

Check: "Ensure all data stored in the S3 bucket is securely encrypted at rest"
PASSED for resource:
File: /

Check: "Ensure the S3 bucket has access logging enabled"
PASSED for resource:
File: /

Check: "S3 Bucket has an ACL defined which allows public access."
SKIPPED for resource:
Suppress comment: The bucket is a public static content host
File: /

Check: "S3 Bucket has an ACL defined which allows public access."
FAILED for resource:
File: /

1 | resource "aws_s3_bucket" "foo-bucket" {
2 |   region        = var.region
3 |   bucket        = local.bucket_name
4 |   force_destroy = true
5 |
6 |   tags = {
7 |     Name = "foo-${data.aws_caller_identity.current.account_id}"
8 |   }
9 |   versioning {
10 |     enabled = true
11 |   }
12 |   logging {
13 |     target_bucket = "${}"
14 |     target_prefix = "log/"
15 |   }
16 |   server_side_encryption_configuration {
17 |     rule {
18 |       apply_server_side_encryption_by_default {
19 |         kms_master_key_id = "${aws_kms_key.mykey.arn}"
20 |         sse_algorithm     = "aws:kms"
21 |       }
22 |     }
23 |   }
24 |   acl           = "public-read"
25 | }

We’ve made it extremely easy to test drive Checkov while taking a tutorial that highlights key capabilities. Check out the getting started section of the Checkov documentation to check your infrastructure against common best practices in just a few minutes.