SAST Testing of IaC using Checkov (DevOps the Hard Way series)
Throughout this series, infrastructure as code (IaC) has been used extensively:
- while containerizing software,
- while creating new infrastructure on AWS including an EKS cluster and an ECR, and
- while deploying containerized software to that new AWS infrastructure.
One major benefit of infrastructure as code is precisely that it can be treated as code.
For example, it can be stored to a version control system for granular change control. Also, as we will see in this post, it is possible to run security scans against IaC. One tool available for this type of scan is a Static Application Security Testing (SAST) tool called Checkov. When run, Checkov searches through lines of infrastructure as code for known security issues and/or policy compliance issues.
Installing checkov
Checkov can be installed using the pip package manager for Python.
1
$ pip install checkov
The package takes some time to download and install.
Once installed, the checkov CLI command can be run at any time to evaluate infrastructure as code.
Running checkov
The command to scan IaC using checkov is straightforward; simply tell the program which directory to search for IaC to scan.
1
2
3
4
5
6
7
8
9
$ checkov -d */path/to/IaC_files* # -d to specify IaC root directory
_ _
___| |__ ___ ___| | _______ __
/ __| '_ \ / _ \/ __| |/ / _ \ \ / /
| (__| | | | __/ (__| < (_) \ V /
\___|_| |_|\___|\___|_|\_\___/ \_/
By Prisma Cloud | version: 3.2.91
Checkov supports a number of IaC types, so the directory passed to the command above can contain Terraform, AWS CloudFormation, or Microsoft Azure IaC, among other types.
Once started, checkov runs through a sequence of individual code checks against any supported IaC files it finds. Each check is marked as either PASSED or FAILED:
PASSED check example
1
2
3
4
Check: CKV_AWS_41: "Ensure no hard coded AWS access key and secret key exists in provider"
PASSED for resource: aws.default
File: /ecr/main.tf:15-18
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/secrets-policies/bc-aws-secrets-5
Notice how Checkov outputs the relevant filename and lines being scanned, along with a Guide link providing more information about what exactly was being scanned for in those lines.
In the example above, Checkov scanned for exposed secrets in the aws provider block of the ECR Terraform module. If found, such AWS secrets could have presented a serious security issue, were this particular code to either become compromised or made public.
Since no secrets were found, Checkov marked the check as PASSED.
FAILED check example
The output from a FAILED check is similar to the output from a PASSED check, but it also includes the contents of the lines of code that failed the check:
1
2
3
4
5
6
7
8
9
10
11
12
13
Check: CKV_AWS_51: "Ensure ECR Image Tags are immutable"
FAILED for resource: aws_ecr_repository.devopsthehardway-ecr-repo
File: /ecr/main.tf:20-27
Guide: https://docs.prismacloud.io/en/enterprise-edition/policy-reference/aws-policies/aws-general-policies/bc-aws-general-24
20 | resource "aws_ecr_repository" "devopsthehardway-ecr-repo" {
21 | name = var.repo_name
22 | image_tag_mutability = "MUTABLE"
23 |
24 | image_scanning_configuration {
25 | scan_on_push = true
26 | }
27 | }
In the example above, we can see that the value of image_tag_mutability in the Terraform block above is "MUTABLE". As explained on the corresponding Guide link:
Tag immutability enables users to rely on the descriptive tags of an image as a mechanism to track and uniquely identify images.
Severity: LOW
With this information, we can decide whether or not any code remediation is necessary for this finding.
Scan results
After completing all of the checks, Checkov outputs a summary of the overall scan results.
1
2
3
terraform scan results:
Passed checks: 31, Failed checks: 12, Skipped checks: 0
Regularly testing IaC with SAST tools like Checkov makes it easier to catch cloud security and policy issues even before they are implemented in real-world environments.
In the next (and final) part of the DevOps the Hard Way series, we will create a DevOps CI/CD pipeline. This pipeline will automatically generate an Amazon EKS cluster when infrastructure-as-code is pushed to GitHub.