Guideline: How to start with IaC SAST
In this text, we introduce helpful tools for scanning IaC artifacts and provide examples on how to integrate them into your CI/CD pipeline.
Infrastructure as Code (IaC) is a software engineering practice that allows us to manage and provision infrastructure using code. SAST plays a critical role in ensuring the security of IaC artifacts. In this text, we introduce helpful tools for scanning IaC artifacts and provide examples on how to integrate them into your CI/CD pipeline.
General
We recommend using the build-in templates for SAST IaC from gitlab, it's the best way to get started and an ideal baseline, for more advanced use follow this guide. Example of a gitlab pipeline with SAST IaC:
--- include: - template: Security/SAST.gitlab-ci.yml - template: Security/Dependency-Scanning.gitlab-ci.yml - template: Security/Secret-Detection.gitlab-ci.yml - template: Security/SAST-IaC.gitlab-ci.yml stages: - test
All languages mentioned in this cheatsheet are supported by GitLab's SAST IaC templates.
Pipeline is using kick tool under the hood, which is a universal SAST tool that supports multiple languages, while sacrifising some precision for the sake of variety. That is why using more specialized tools for specific languages is preferable.
Note: IaC scanning supports a variety of IaC configuration files. When any supported configuration files are detected in a project, they are scanned by using KICS. Projects with a mix of IaC configuration files are supported.
Docker
When we were analyzing the tools, we found that the tools found bugs that, despite the label critical or high, did not have such an impact to deserve such a rating. So we recommend choosing the tool based on the type of project you are working on.
Recommended tools:
- Grype - Most verbose and detailed findings, more dependency scanning than vulnerability scanning
- Hadolint - Linter for Dockerfiles, checks for best practices and common mistakes, useful even in pipelines
- Clair - Similar to grype, but more focused on vulnerabilities, hard to set up
- Trivy - Also dependency scanning, but not as verbose as other tools
I would recommend using grype and hadolint in combination, as they complement each other well.
Kubernetes
Kubernetes, or k8s, can have various forms of configuration, typically k8s manifest or helmcharts.
Recommended tools:
- Checkov - most helpful overall
- Trivy - More problematic for setup. It needs to be connected to the running k8s cluster.
- Terrascan - SAST, simple and short findings, suitable for pipelines
- KICS - Should be integrated in the GitLab build-in templates
Ansible
A few tools specifically target this language. This is because Ansible is mainly used to set up and configure machines rather than being directly vulnerable itself. The focus is usually on checking what a script deploys or if any sensitive information, like tokens, is accidentally left in the script.
Other tools address these concerns, so our recommendation is to combine tools based on what you need to check. For example, if you need to check for sensitive information, use GitLeaks or TruffleHog.
Recommended tools:
- KICS - Should be integrated in the GitLab build-in templates
- Checkov - also supports Ansible
- Ansible-lint - Linter from creators of Ansible, checks for best practices and common mistakes
CI/CD Pipelines
For examples, visit Our cheatsheet for CI/CD pipelines