Infrastructure as Code (IaC) and Policy as Code Scanning for Vulnerabilities

In a prior post, we explored automated and manual code testing with DevSecOps. That article briefly touched on the importance of IaC scanning and policy as code. In this article, we’re going to take a much closer look with practical examples of running scans that check for Infrastructure as Code misconfigurations or policy violations.

What is IaC Scanning?

Infrastructure as Code (IaC) is the practice of defining and managing infrastructure resources, like servers, networks, and storage, using code-based templates or configuration files. By defining infrastructure through code, it becomes much easier for organizations to automate, scale, and achieve deployment and management consistency for their infrastructure.

IaC scanning is the process of analyzing and evaluating the security and compliance of infrastructure code. It focuses on examining the code and configurations that define the infrastructure to identify potential security vulnerabilities, misconfigurations, and compliance violations. It helps organizations validate that their infrastructure deployments follow security best practices, industry standards, and regulatory requirements.

The scanning process works just like other types of static application security testing (SAST) tools, but with a focus on IaC. The results of these scans provide actionable insights and recommendations to address issues, which gives engineers the chance to remediate potential risks before the infrastructure gets deployed.

Why do you need IaC scanning?

Just like SAST is an important part of verifying application code security, IaC scanning is an important part of verifying infrastructure code security and quality.

By integrating IaC scanning into the development and deployment pipelines, organizations can identify and address security issues very early in the process, reducing the chances of vulnerabilities being deployed to production environments and getting one step closer to achieving shift-left security.

Infrastructure as Code (IaC) scanning tools

Terraform, Pulumi, AWS CloudFormation, Helm, and Ansible are all examples of modern Infrastructure as Code tools that many organizations use and that Spacelift supports. They provide a fantastic way of controlling environments and infrastructure that lives in AWS, Azure, GCP, etc.

Because this infrastructure gets provisioned and managed through code instead of through manual processes, infrastructure specifications live in configuration files. This is wonderful because it makes it much easier to create, edit, and distribute those specifications. With that said, we can make mistakes as we are writing those specifications, and we may not realize it until the infrastructure has already been provisioned in production.

To significantly reduce the odds of a major mistake making it to production (think leaking secrets, opening up permissions, etc.), we can use static code analysis tools specifically created for Infrastructure as Code.

Examples of Iac scanning tools include:

• Checkov – a static analysis tool specifically designed for IaC environments, particularly for cloud-native technologies. It helps identify and prevent misconfigurations, security risks, and compliance violations by scanning IaC files (ie: Terraform configurations), and providing detailed reports on potential issues.
• tfsec – also a security scanning tool that focuses on Terraform configurations to identify potential security risks and misconfigurations. It analyzes the Terraform configuration files and provides actionable recommendations based on industry best practices and common security issues. Read more in our What is tfsec? article.
• TFLint – a powerful linter for Terraform configurations. It analyzes Terraform config files to enforce best practices and coding standards and to find potential errors for the major cloud providers (AWS, Azure, and GCP). For example, it can help enforce consistent formatting and naming conventions and warn about unused declarations.

For this article, we’ll be using and demonstrating the tool Checkov, but the concepts apply across the board.

Check out other most useful Terraform tools.

Policy as Code scanning

Another aspect of detecting issues with infrastructure is to use Policy as Code. Policy as Code expresses rules using code. This extends the IaC approach by also covering rules governing that infrastructure and the platform that manages it.

You can think of it as creating guardrails for your infrastructure and platforms.

As an example of creating guardrails for platforms, with Spacelift, you can use policies to decide who can approve or reject a run, and how a run can be approved.

As an example for infrastructure guardrails, we could create a policy that prevents creating a public Access Control List (ACL) for Amazon S3 buckets, which would help prevent accidentally making buckets that contain sensitive information public. We’ll demonstrate how to do this in just a moment.

Using both IaC and Policy as Code scanning can help you catch issues before they even get committed to your repositories and before they reach production. So let’s take a look at how this works.