In April of last year, we announced Checkov 2.0 with the addition of a graph-based backend and context-aware policies. And now, over a year and one thousand contributions later, we’ve reached the next milestone—Checkov 2.1! This release was a culmination of additional capabilities across workload scanning, secrets detection, and supply chain security, as well as new integrations, hundreds of new policies, and more, all capped off with new progress bars for the relevant scans being performed.
In our latest office hours, we walked through and demoed some of these exciting new additions. Watch the 60-minute webinar below, or keep reading for a quick recap of some of the key updates that were a part of the releases leading up to Checkov 2.1.
TL;DR, here are a few of the minor releases that launched before we bumped that tag to 2.1:
- Added workload scanning with image, open source package, and OpenAPI scanning
- Integrated secrets detection into our IaC scanners
- Built in software supply chain coverage with VCS and CI/CD configuration scanning
- Increased IaC coverage with Bicep and Kustomize scanning, OCI, AliCloud, Yandex, OpenStack, and AWS v4 support for Terraform
- Supplemented filtering and outputs with metadata from the Bridgecrew platform, such as severities, CycloneDX software bill of materials (SBOM) output, baselining, and config file support
Shift left workload scanning
The biggest addition with Checkov 2.1 by far is its new integration leveraging twistcli from Prisma Cloud. With this integration, you can use Checkov with an API key to scan both container images and package manager files against a combination of open source and proprietary vulnerability databases. Checkov will also scan Dockerfiles for misconfigurations like exposing port 22, even without an API key. This helps you leverage Checkov to scan for a majority of the security issues in your stack—from infrastructure to images to package dependencies.
And we’ve taken this integration one step further. When you add one simple (experimental) flag, CHECKOV_EXPERIMENTAL_IMAGE_REFERENCING, Checkov will scan images referenced in CI/CD configuration files like GitHub Actions. This is just the start of the full-stack security we’re building into Checkov, so stay tuned!
One other important addition to our workload security was our ability to scan OpenAPI spec files. Now you can identify potential weaknesses in your APIs that could be used for exploits based on the Swagger/OpenAPI specs.
Find those secrets before the bad guys do
We didn’t stop at workloads. Thanks to our friends at Yelp, we expanded into another category with secrets scanning for Checkov. When secrets—like API keys—are added to a public repository, bad actors can find and exploit them within minutes. Waiting for detection post-push is too late. With Checkov, you can now detect secrets in your IaC files before they are checked in.
Supply chain security is not a given
Even if you’ve got secure IaC code and container images, you can’t stop there. Have you taken steps to secure the software supply chain that integrates and deploys your code? With Checkov, you can now scan the configuration of your VCS provider—such as GitHub, GitLab or Bitbucket—to identify weak VCS organization configurations or branch protection violations that will expose your repos to supply chain attacks.
Checkov also now scans the configuration files for many popular CI/CD providers such as GitHub Actions, GitLab CI, and Argo, with more to come. With this new feature, Checkov can identify misconfigurations that may lead to attacks like pipeline secrets exfiltration and code injection, where bad actors can use a pull request to send secrets stored in a vault to a URL they own or where bad actors arbitrarily execute code they added with no checks.
Bicep and Kustomize template scanning
We’ve also expanded to natively support two other IaC frameworks. Before Checkov 2.1, you could always render Bicep files into ARM templates and scan those. Similarly, you could render Kustomize into Kubernetes YAML and scan those files. However, that was a tedious process.
We’ve since added the ability to directly scan both of those template types, and now the results will take you to the source of the issue rather than the rendered output. This way, you’ll spend less time chasing down the root cause of an Azure or Kubernetes misconfiguration.
What’s more, we’ve added two new goats to our herd—KustomizeGoat and BicepGoat—and a new Kubernetes workshop that includes Kustomize walkthroughs so you can easily try the Kubernetes and Kustomize scanning capabilities of Checkov and the Bridgecrew platform for yourself.
New and updated cloud support
In addition to the different runners, we’ve had some major updates to our Terraform checks. Thanks to the community and our own team here at Bridgecrew, we’ve added policies for OCI, OpenStack, AliCloud, and Yandex.
When AWS updated their Terraform provider to v4, it included a few breaking changes for S3 that separated configurations into separate resource blocks. Thanks to our graph backend, Checkov natively supports findings in S3 buckets even if the configurations are in separate resource blocks.
Finally, by integrating Cloudsplaining with Checkov, we’ve added a lot more IAM checks that will flag overly permissive IAM policies in your code. Fixing these violations will reduce the attack surface of a compromised user or service account.
Other platform integrations
After receiving requests from the community, we’ve added support for enriching findings with platform metadata such as severities. If you use your API key with Checkov, you will also get custom policies, suppressions, and severity data from the platform. This adds consistency across integrations and makes filtering through our hundreds of policies much easier.
CycloneDX IBOM output
During our Hackathon we received an exciting contribution to export IBOMs using Checkov. Now Checkov can export findings in the standardized SBOM format known as CycloneDX. These files can be leveraged by vendors to supply customers with a bill of materials for their products that includes the components’ posture. As SBOMs become more of a requirement for operating in regulated industries, you’ll see us expand on this functionality and add more options to our BOM outputs and usage.
Baselining and config file support for repeatable filtering
The list of findings from a first-time scan with Checkov can be overwhelming. To make it easier to handle, we’ve added two new additions for filtering findings. Baselining allows users to start fresh and only flag new files. With the baseline feature, you suppress all findings from the first run of Checkov. From that point on, future scans with Checkov and the baseline flag will only flag new findings, not any findings from the first scan. Viewing all your findings at once can be daunting, so we recommend starting with new findings and working through your backlog once your new violations rate stabilizes.
Config file support allows users to add all their advanced findings to a file that can be version controlled and stored. With config file support, adding advanced findings to your files is much more manageable because you’ll no longer need to add dozens of flags to a CLI command locally or in your CI/CD pipeline.
···
A lot (over 1K!) of releases and community contributions went into this major release. Believe it or not, this wasn’t even the full list. We are so grateful to the community for making this project so successful. We can’t wait to see what we’ll build together next!
If you have any ideas for new features, please contribute to Checkov or any of our other open source projects.
