Announcing Checkov — Prevent cloud misconfigurations during build time
Today we are introducing Checkov, a new open-source project for cloud infrastructure security.
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 report, using JunitXml output format.
Enough said!
Start by deploying Checkov locally and scanning a few standalone Terraform folders and files.
Installation
pip install checkovConfigure an input folder
checkov -d /user/tfor a specific file
checkov -f /user/tf/example.tfView 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: aws_s3_bucket.foo-bucket
File: /example.tf:1-25
Check: "Ensure the S3 bucket has access logging enabled"
PASSED for resource: aws_s3_bucket.foo-bucket
File: /example.tf:1-25
Check: "S3 Bucket has an ACL defined which allows public access."
SKIPPED for resource: aws_s3_bucket.foo-bucket
Suppress comment: The bucket is a public static content host
File: /example.tf:1-25
Check: "S3 Bucket has an ACL defined which allows public access."
FAILED for resource: aws_s3_bucket.foo-bucket
File: /example.tf:1-25 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 = "${aws_s3_bucket.log_bucket.id}"
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.
