I have recently used Checkov to analyze a quite large code base - an 8-year old monorepo with 28000 lines of HCL code. Many separate Terraform workflows in directories, each with its own state file. All managed by Atlantis.

It took around 1 hour to process the whole repository, minus external modules. I have run a variation of the following command:

$ checkov --quiet \
--download-external-modules=true \
--skip-path ".external_modules" \
-o cli -o json \
--output-file-path console,results.json \
--directory terraform/

Initially, I have got many error messages related to the fact that Checkov didn’t support pulling modules whose definitions used a partial commit hash instead of a full length one. For example, definition like this:

module "example_module" {
source        = "git@github.com:example/example-modules.git//tier0/some-dir?ref=d6b27e95"
...
}

Would produce errors similar to this one:

2025-12-08 10:45:03,925 [MainThread  ] [WARNI]  failed to get git::ssh://git@github.com/example/example-modules?ref=d6b27e95 in git loader because of Cmd('git') failed due to: exit code(1)
cmdline: git checkout d6b27e95
stderr: 'error: pathspec 'd6b27e95' did not match any file(s) known to git'

The repository is too big to change all module definitions, so I modified the Checkov python code in my virtual environment to support the shortened hash versions.

I submitted this fix upstream and it was merged into Checkov release 3.2.490. This means if you’re using Checkov 3.2.490 or later, shortened git hashes should work out of the box. You can view the pull request here: PR #7278

Scan results

Around 200 different Checkov policies were violated. Many of them multiple times. All in all, the scan produced a few thousand alerts.

The main downside of the Checkov open source version is the lack of severity mappings. With thousands of alerts, you get an alert fatigue and it’s impossible to prioritize what to investigate first. To overcome this blocker, I have collected initial severities from the Prisma Cloud hlxsites/prisma-cloud-docs repository. While those severities can be useful it’s up to you to investigate if the risk actually applies given the environment specifics. For example, the cloud resource can lack optional access control settings, which are only necessary if the cloud resource lives on a public network.

As an example, the severity classifications between Wiz and Checkov (using Prisma Cloud severity mappings) show significant differences:

As you can see, 44% of Wiz’s HIGH severity findings were classified as LOW in Prisma Cloud mappings, suggesting the Wiz has either way more context by mapping the attack path across different cloud resources (most likely) or just have a way less tolerance for misconfigurations. But at this point we are just comparing severities produced by two distinct companies and one can argue we should just stick to anything we have available and do the actual work.

Recommendation

There is no silver bullet solution for having lots of findings, but once the stuff is categorized, prioritized, and either fixed or ignored, I recommend running Checkov as a pipeline check within the pull request. That way, you will avoid a large number of alerts, and you will see potential issues gradually as immediate feedback on your code changes. Those alerts are visible to the pull request creators and the triage and fixes are then basically distributed to the code committers instead of the security team.

Finally, you can consider running Checkov locally before the code changes are pushed. I have no experience with the IDE plugins for Checkov, but maybe there are some available.