Scanning with KICS for issues in Terraform#
During a recent OWASP Netherlands meetup security scanners were discussed to prevent mistakes and also Checkmarx presented their tool KICS for scanning for security vulnerabilities and configuration errors in Infrastructure-as-Code. Development of KICS goes fast since late 2020 and can catch some common mistakes with known Infrastructure-as-Code definitions like Terraform, Cloudformation, and Ansible for example.
KICS can be used as a standalone scanner as it is written in Go and with GitHub Actions. For now, let’s test it with a Terraform configuration in a GitHub Workflow to see how it works and how useful it is. Maybe in the future, we will test it with Ansible and Docker as well.
Run KICS with GitHub CI#
For this post, we have a repository and create a workflow file called
.github/workflows/ci-kics.yml and we fill it with the example below. It will scan every pull_request against the master, and on a schedule once a month to validate the setup is still correct. The basic steps for the workflow are pretty straightforward with creating a directory to store the output and running the action. On lines 46 and 48 both the platform type, Terraform in this example, and the path where the files are stored. Also, the output formats are specified to other tools like Grype to use later.
1 --- 2 name: CI - KICS 3 4 on: 5 pull_request: 6 branches: 7 - master 8 schedule: 9 - cron: "22 8 * * 5" 10 11 jobs: 12 13 kics: 14 name: KICS scan 15 runs-on: ubuntu-latest 16 17 steps: 18 - name: Checkout Code 19 uses: actions/[email protected] 20 21 - name: Create directory build 22 run: mkdir -p build 23 24 - name: Run KICS Scan with SARIF result 25 uses: checkmarx/[email protected] 26 with: 27 path: 'terraform' 28 output_path: build 29 platform_type: terraform 30 output_formats: 'json,sarif'
When the workflow runs it works as KICS generates a failure due to generated warning as it has found issues. Both
ignore_on_exit: resuls or
fail_on: high,medium can be used to tweak KICS to generally ignore all findings and stop the workflow completely or to only stop the workflow with a certain severity of findings. For now, KICS fails because it expects that names are in Snake Case format, and instead of rewriting the configuration we’re going to exclude check 1e434b25-8763-4b00-a5ca-ca03b7abbb66 as in the example below.
1 ... 2 - name: Run KICS Scan with SARIF result 3 uses: checkmarx/[email protected] 4 with: 5 path: 'terraform' 6 output_path: build 7 platform_type: terraform 8 output_formats: 'json,sarif' 9 exclude_queries: 1e434b25-8763-4b00-a5ca-ca03b7abbb66
Now that the workflow finishes the output isn’t shown in GitHub and for that, we have two options. The first one works for every GitHub subscription and that is to have KICS create or update an overview comment in the matching pull request with the option
1 ... 2 - name: Run KICS Scan with SARIF result 3 uses: checkmarx/[email protected] 4 with: 5 path: 'terraform' 6 output_path: build 7 platform_type: terraform 8 output_formats: 'json,sarif' 9 exclude_queries: 1e434b25-8763-4b00-a5ca-ca03b7abbb66 10 enable_comments: true
Integrate KICS with CodeQL#
In the previous section, we got the scanner working and posted an overview as a comment as part of the pull request. But KICS can also generate a report in Static Analysis Results Interchange Format (SARIF) to be later processed by GitHub. As we already generate the reports in directory
build by setting the
output_format (line 28) and
output_path (line 27), the SARIF report can be uploaded with codeql-action/upload-sarif as is shown in lines 31-34 in the example below.
1 --- 2 name: CI - KICS 3 4 on: 5 pull_request: 6 schedule: 7 - cron: "22 8 * * 5" 8 9 jobs: 10 11 kics: 12 name: KICS scan 13 runs-on: ubuntu-latest 14 15 steps: 16 - name: Checkout Code 17 uses: actions/[email protected] 18 19 - name: Create directory build 20 run: mkdir -p build 21 22 - name: Run KICS Scan with SARIF result 23 uses: checkmarx/[email protected] 24 with: 25 path: 'terraform' 26 platform_type: terraform 27 output_path: build 28 output_formats: 'json,sarif' 29 exclude_queries: 1e434b25-8763-4b00-a5ca-ca03b7abbb66 30 31 - name: Upload SARIF file 32 uses: github/codeql-action/[email protected] 33 with: 34 sarif_file: build/results.sarif
The example above only works for GitHub public repositories or organizations with CodeQL as part of their GitHub subscription.
Set fail levels for KICS#
Excluding checks sounds good, but may result in unwanted behavior as you may never see those results again. Setting a minimum failure level to
high,medium will allow you to still see informational and low after a scan, but won’t stop your pipeline. And in the future, if the check is raised from informational to medium, then the pipeline will automatically stop.
21 ... 22 - name: Run KICS Scan with SARIF result 23 uses: checkmarx/[email protected] 24 with: 25 path: 'terraform' 26 output_path: build 27 platform_type: terraform 28 output_formats: 'json,sarif' 29 fail_on: high,medium
Another way is to set
ignore_on_exit to ignore any errors or results, but this is only useful when KICS is being incorporated into an existing project and all findings have to be resolved first.
21 ... 22 - name: Run KICS Scan with SARIF result 23 uses: checkmarx/[email protected] 24 with: 25 path: 'terraform' 26 output_path: build 27 platform_type: terraform 28 output_formats: 'json,sarif' 29 ignore_on_exit: resuls
Checking your application code makes sense and the same is valid for Infrastructure-as-Code to catch common mistakes. For my limited tests with KICS for Terraform and Cloudflare the results are limited, but the speed of KICS is fast enough to not slow down the pipelines too much. But here also comes the main issue with automating everything as you may end up with a dozen tools and some contradicting others.
Checkmarx itself is known for pretty decent tooling and when enterprises start using KICS as part of their scanning requirements is still the question. For now, we have to see how KICS evolves and more tests with Docker, Kubernetes, Ansible, and OpenAPI for example are needed to see how useful it is and for which use cases. But also investigate more the Bill of Materials support in KICS.