Checkov 2.0: Context-Aware Security Scanning for Infrastructure as Code
In 2019, the creators of Checkov (who I’m lucky to call my colleagues) set out on a mission to create a developer-friendly way to secure infrastructure-as-code (IaC) templates. When over 20% of Terraform templates and over 40% of CloudFormation templates are misconfigured, that’s a big task. Misconfigurations in templates can lead to real risks in production, such as SSH ports open to the world and unencrypted databases. That’s why the Bridgecrew team (now part of Palo Alto Networks’ Prisma Cloud) got to thinking how game-changing it would be to identify problems before IaC templates get provisioned — either during development or in the build phase.
Nearly 3,400 commits and 1.4 million downloads later, Checkov continues to evolve and iterate — in true open source fashion. Recently, the project celebrated its biggest update when it reached version 2.0.
Let’s see how we got here and learn more about why Checkov 2.0 is better than ever with its expanded coverage — featuring 250 new policies and an all-new graph-based backend framework to support more complex use cases.
A Brief History of Checkov
Checkov began as an open source static code analyzer for Terraform templates. It contained only 50 policies that were created 100% in-house. At the time, there were other static analyzers for Terraform templates, but they had a steep learning curve and complex custom policy syntax. Checkov was built to be a developer-friendly alternative that is extensible and community-driven. Since then, we’ve seen a lot of innovation:
- Added support for AWS CloudFormation and Azure Resource Manager (ARM), including AWS CDK-generated templates.
- Expanded coverage to identify and fix Kubernetes manifest and Helm chart misconfigurations.
- Moved up the stack to support Serverless Frameworks configurations.
- Most recently, added Dockerfile scanning to identify misconfigurations in the commands to create container images.
- Added out-of-the-box policies at a regular cadence from frameworks and community suggestions. We’re now up 800 policies!
Even polyglot repositories, such as ones with Kubernetes manifests for orchestration and Dockerfiles to create container images, will be automatically identified and scanned separately.
Limitations of Traditional Static Analysis
Traditional static analysis of files is powerful for finding issues in code line-by-line. The problem is, in declarative IaC templates, resource dependencies aren’t laid out linearly. A virtual machine could be listed in the file first but need to be configured after the firewall rule that appears second in the file.
To simplify things for developers, declarative IaC tools can interpret and deploy infrastructure no matter what order it is in in the template. This is great for developers but difficult for scanners.
Standard static analysis can’t pick up on complex interdependencies of resources, such as which VPC includes a specific security group. That adds more noise and false negatives as it’s challenging to know the actual risk of a misconfigured resource unless you know the resources it’s attached to. For example, an unencrypted database is less of a concern if it is in a dev or test VPC that isn’t internet accessible.
That complex relationship is why we launched Checkov 2.0, the first open source graph-based IaC security tool. Graphs can interpret relationships in code better than traditional backends. Things like variables and attached resources create a relationship tree that can be easily and quickly queried for information. (In fact, in testing, we found the graph-based backend was 3x faster!)
Two Real-World Use Cases only Graphs Can Solve
Let’s explore a few examples that show how graph-based scans are better.
Static analysis of a Terraform template can determine that all AWS elastic block storage (EBS) resources have encryption turned on. However, if an unencrypted EBS volume isn’t attached to an EC2 instance, that’s a lot lower priority than an unencrypted EBS volume attached to a production EC2 instance. It takes a graph to interpret that connection.
Developers can also add their own custom policies using Python or with Checkov 2.0 using YAML. Let’s break down an example of a graph-based policy that can check for the first use case above.
If you want to ensure your Azure PostgreSQL cannot be accessed directly and is tagged, there isn’t a single check. You need to ensure that either no firewall rule is attached to the database, defaulting to block all external access, or that any attached firewall rule does not have 0.0.0.0 for the IP address.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
metadata: name: "Ensure that only encrypted EBS volumes are attached to EC2 instances" category: "ENCRYPTION" id: "CKV2_AWS_2" definition: and: - or: - cond_type: "connection" resource_types: - "aws_volume_attachment" connected_resource_types: - "aws_ebs_volume" operator: "not_exists" - and: - cond_type: "attribute" resource_types: - "aws_ebs_volume" attribute: "encrypted" operator: "equals" value: true - cond_type: "connection" resource_types: - "aws_volume_attachment" connected_resource_types: - "aws_ebs_volume" operator: "exists" - cond_type: "filter" attribute: "resource_type" value: - "aws_ebs_volume" operator: "within" |
This policy checks that no provisioned volume is attached to another resource or that all EBS volumes that are attached to another resource are encrypted.
We could customize this policy to also ensure that all EBS volumes are encrypted and tagged by adding the following to an and block in the YAML file.
|
1 2 3 4 |
cond_type: "attribute" resource_types: "all" attribute: "tags.env" operator: "exists" |
This customized policy or any others you build can be added to Checkov for every scan by adding it to the appropriate folder in /checkov/{provider}/checks/. You can also add them to a local folder or repository and add them to a scan by using the –external-checks-dir or –external-checks-git flags.
Expect Big Things to Come
We’ve seen a lot of changes as Checkov has moved from its initial launch to 2.0. We’ve extended the types of templates, moved to a new backend architecture and dramatically expanded the number of policies.
As a part of Palo Alto Networks’ acquisition of Bridgecrew, we have committed to continue expanding Checkov’s policy library and investing in further Checkov development based on its team of threat researchers. Expect to see even more improvements as Palo Alto Networks invests heavily in Checkov and other open source projects.