How to enforce consistent code scanning rules across Checkov and Bridgecrew

Bridgecrew recently released powerful new Enforcement rules settings, which allow you to granularly define the behavior for pull/merge requests and CI/CD scans in the platform. You can also use your settings—as defined in the Bridgecrew platform—in all of your local Checkov scans, which makes it easier to apply unified settings across your environment.

In this blog, we’ll give you a primer on Enforcement rules in the Bridgecrew platform and Checkov, as well as a tutorial on how to consistently apply your settings throughout your pipeline.

See Enforcement rules in action in this video, or keep reading to learn more.

Enforcement rules in Bridgecrew

First, we’ll start with a summary of these new settings in the platform. Bridgecrew and Checkov support scanning for several different types of security issues, from infrastructure as code (IaC) misconfigurations and exposed secrets to our newer open source package vulnerabilities and supply chain issues. You may wish to treat the scan results that flag these types of security issues differently in your pipelines, which you can now do with Enforcement rules.

Enforcement rules settings allow you to define rules for each of the major code scanning categories: IaC like Terraform and CloudFormation, secrets, open source package vulnerabilities, Docker image vulnerabilities, and build integrity. For each of these categories, you can define three rules that determine how the platform will handle the scan results:

  • Hard fail: If a code review scan, such as a pull request or CI/CD scan, has errors at or above this severity, then the scan will fail and the platform will block the code from being merged.
  • Soft fail: If a code review scan has errors at this severity level, but the errors are below the hard fail level, the system will display the flagged violations but will not cause the job to fail. Policies below this severity level get skipped entirely.
  • Comments bot: The PR/MR comments bot will surface identified issues and fix suggestions as comments on the VCS pull/merge requests. This setting enables you to filter out lower severity comments that may be too noisy.

One great thing about Enforcement rules is that you can set different severity levels for different types of scans. Take these settings, for example:
Enforcement rules settings in the Bridgecrew platform

These rules will cause code review scans for IaC to include policies from all severities to soft fail, but will only hard fail if there is a high or critical severity finding. The PR comments bot will also post comments for high or critical findings. However, for open source package vulnerabilities, the code review scan will soft fail for medium or higher CVEs, will never hard fail, and will only post comments for critical CVEs.

You can also create exceptions from the default rule and apply different Enforcement levels on a per-repository basis.

Enforcement rules in Checkov

What does this all mean for Checkov? Up until now, you could replicate this functionality using options like --check and --hard-fail-on (read about it here). However, this approach had some limitations:

  • You had to configure these arguments everywhere you ran Checkov.
  • The arguments could differ from the thresholds defined in the platform, leading to different results in your local run compared to the platform.
  • The settings applied to the entire run. You couldn’t differentiate IaC and open source package scans, for example.

Now, you can apply the same rules that you define in the platform in all of your Checkov runs to ensure a consistent scanning experience throughout your pipeline, all while managing those settings in one convenient place instead of in each pipeline that has Checkov.

To use Enforcement rules in your Checkov run, simply add the argument --use-enforcement-rules along with your platform API key.

Let’s see it in action.

First, here is a simple Checkov run without Enforcement rules:

A run in Checkov without Enforcement rules

It looks at one Terraform resource and has a few failures, and the run ultimately fails as a result—as you can tell by the red “X” at the bottom left. I have my API key set as an environment variable, so we also get severities and custom policies from the platform.

Now, let’s try it with Enforcement rules. Here are my IaC Enforcement levels in my environment. For Checkov, the PR/MR comments level is irrelevant, so we are only looking at the hard and soft fail levels. I have hard fail set to high+ severities and soft fail set to medium+ severities.

IaC Enforcement levels screen

This means that we should skip all low severity errors, and fail if we have a high or critical severity error. Here is what the run looks like using the new --use-enforcement-rules flag:

Checkov results when using the new --use-enforcement-rules flag

Because we omitted the low severity policy violations, they do not appear in the output. However, we still have a failed run because we have errors that meet the hard fail threshold.

Repository-based exception rules

What if we decide that we want to handle scans in this repo differently? Maybe we only want to be alerted of critical severity IaC errors but never hard fail the run regardless of the severity. To do this, we can create an exception for this repo in the Enforcement rules UI. Here, we disable the hard fail level for IaC altogether and set the soft fail threshold to critical:

Adding an exception in Enforcement rules

Now, when we repeat the same run, only the critical severity policy gets evaluated. Even though there is a failed policy, the run passes—we get a green checkmark—because we disabled hard fail. But because we set critical errors to soft fail, we can still see one misconfiguration show up in the error log:

Checkov results when adding an exception to Enforcement rules

There! We have modified the result of our pipeline without changing anything in the local configs!

Defining different rules for different code categories

The example above just uses the IaC category with a Terraform file. Let’s look at what happens when we have different settings for different code categories by adding in a sample package-lock.json file. First, here’s the output without any Enforcement rules:

package-lock.json file output without any Enforcement rules

We have the same Terraform output as in the very first run above, and we also have some CVEs—one low, one medium, and one high.

Let’s apply Enforcement rules. In the Enforcement rule exception we created for this repo earlier, we omitted low severity CVEs from the output and set hard fail to high+.

As expected, the low severity CVE was skipped. The result of the run was still a failure, because the open source hard fail level is set to high, and we have a high severity finding:

Failed Checkov run with a low severity CVE

Advanced: Overriding Enforcement rules locally

We can still use the local arguments to tweak Enforcement rules for a specific run. This will produce a different output in the local scan than the platform, since the Bridgecrew platform will still stick to the settings defined in the Enforcement rules. While we don’t generally recommend this when using Checkov with the platform, it can be useful if you want to temporarily skip certain policies, use soft fail, or fine-tune the Checkov run in other ways.

Here is the behavior if you use the following arguments alongside --use-enforcement-rules:

  • If you use --check and/or --skip-check with only check IDs and not severities, then Checkov combines those lists with the soft fail threshold from the Enforcement rule.
  • If you use --check and/or --skip-check with a severity, then the severity overrides the Enforcement rule soft fail threshold for all runners.
  • If you use --soft-fail-on and/or --hard-fail-on with only check IDs and not severities, then Checkov combines those lists with the hard fail threshold from the Enforcement rule.
  • If you use --soft-fail-on and/or --hard-fail-on with a severity, then those severities override the Enforcement rule hard fail threshold for all runners.
  • If you use --soft-fail, Checkov overrides the Enforcement rule hard fail threshold for all runners. This is the same as setting the hard fail level to Off.

Here are some examples, using the same exception Enforcement rule from earlier:

Run a specific check not included in the Enforcement rules threshold

Here, the low severity policy from the --check argument gets included:

Run a specific check not included in the Enforcement rules threshold

Hard fail on a specific check not included in the Enforcement rules threshold

Here, the failed policy in --hard-fail-on causes the run to fail even though the Enforcement hard fail level is off:

Hard fail on a specific check not included in the Enforcement rules threshold

Override the check list for all runners

Here, the --check argument with a severity will override the soft fail level in the Enforcement rule, so we run all policies. The hard fail threshold from the rule still applies, so the run passes and we get a green checkmark:

In Checkov, Override the check list for all runners

···

That’s it! To summarize:

  • You can use the --use-enforcement-rules option to apply rules defined in the Bridgecrew platform in your Checkov runs.
  • You can manage all scan types, threshold combinations, and exception rules in the platform.
  • You can still fine-tune individual runs as needed by using arguments like --check and --soft-fail in your local Checkov config.

Try Bridgecrew out for yourself by signing up for a free trial, and be sure to give Checkov a star.