Shout out to Corcoran Smith, Solution Architect at Slalom and long-time contributor to Checkov, for his support on this feature and post! đź’ś
At Bridgecrew, we’re incredibly proud of our open-source projects and contributions back to the infrastructure development and security community. When we first launched our IaC static analysis tool, Checkov, in December 2019, it had just a handful of checks for AWS. Within a couple of months, that number exploded to over 500 checks covering resources in AWS, Azure, and GCP frameworks.
To make sure Checkov continues to be valuable for both individual contributors and big, distributed teams, we’re committed to supporting new features and use cases for everyone. Recently, we wrote about support for custom Terraform providers. And today, we’re talking about a feature especially useful for bigger, more enterprise teams—the ability to share, version, and enforce custom checks across teams and repositories.
Why is sharing policy-as-code important?
Custom policies are great for large engineering teams creating a “paved road” of best practices mapping to the organization’s unique needs or desired outcomes. For example, you may want to put a resource tagging policy in place that helps govern security, cost, and ownership. Or, you might have a set of preferred cloud services you would like your teams to use. Those examples might be relevant for a specific organization, but they may not be for 99% of other Checkov users.
That’s where custom Checkov policies or checks come in. But as you create more and more custom policies-as-code, it can be unruly to manage and share them across teams and repositories.
Being able to point Checkov to shared policies has several benefits:
- It reduces the time and effort required to recreate the same policies as a module many times over. You can quickly share your custom policy library for all other teams without teams having to recreate the same policies themselves.
- Policy sharing reduces the risk of not applying the exact logic your organization intends to enforce and govern.
- Because custom policies are loaded from git repositories, you can treat them like any other code. You can apply version control and review changes all in one place.
- You can also control who has access to your custom policy libraries and implement requirements for PR reviews by delegated security administrators, ensuring teams stay in compliance with the defined checks.
- Because teams only need to add a single additional repository to their Checkov test phase, it also makes it easier to keep CI/CD pipelines compliant.
Creating your own
Let’s go through an example.
As a DevOps engineer, I want to make sure that S3 buckets are assigned to environments with an expected value. That way we can differentiate and govern workloads separately across the development lifecycle.
To do that, we would create a custom policy that ensures each S3 bucket has an environment tag with one of the values representing either “Development,” “Staging,” or “Production” environment.
Having the policy in a shared GitHub repository (and not locally on my workstation) allows my whole team to use, review, and version control it. Simply let Checkov know there are extra checks stored in an external GitHub repository with the following command:
checkov --external-checks-git https://github.com/schosterbarak/example-shared-checkov-policies.git
That’s it! Checkov will then use the shared, version-controlled policies stored in the GitHub repository schosterbarak/example-shared-checkov-policies.
· · ·
As you’re building and sharing custom policies, ask yourself if they might serve the entire Checkov community. If you think your policies will help others secure their cloud infrastructure, contribute it as a pull request! For help contributing to Checkov, sharing policies, or any other Checkov-related questions, join our CodifiedSecurity Workspace.
