When performing application security audits, there are two largely recognized methods of application testing:

  • SAST – Static Application Security Testing
  • DAST – Dynamic Application Security Testing

A static test considers the application code alone, where dynamic testing is performed outside of that environment in the full scope of the application. On the infrastructure side, Cloudrail employs two similar strategies: static and dynamic testing. Dynamic testing with cloudrail is performed on infrastructure within a live cloud environment, while static testing is performed directly on terraform code.

The History

Cloudrail static analysis was originally developed as a tool to run on terraform plan files. For those not familiar, a plan file is a file generated by terraform which resolves all dependencies, compares the proposed changes to the actual state, and outlines the exact changes terraform will be making to an environment, be it modifications, creations, or deletions.

The advantage of performing a static assessment on a plan file is that it gives the most clear representation of what will actually happen, and how the environment will look after the plan has been executed. Of course, a plan file doesn’t account for resources defined outside of terraform, but for infrastructure defined in the repository, it gives the best picture.

The Problem

Unfortunately, not all infrastructure developers have the environment to be able to generate a plan file. To do so requires access to the terraform state and the remote cloud environment. In companies implementing more developed infrastructure strategies, state and cloud access are managed by deployment pipelines, and individual access to cloud environments are restricted on the principle of least privilege. For this reason, Cloudrail recently introduced changes to our static assessments, performing them instead by default not on plan files, but on terraform files directly.

When performing assessments on terraform files directly, two strategies can be considered:

  • Building or using a HCL parser to parse .tf files directly
  • Use terraform’s existing tools with a few modifications

Our Solution

We chose to go with the latter approach. Instead of building a custom parser, Cloudrail employs a forked version of terraform. When performing a static assessment, we generate a mock plan behind the scenes using our forked terraform, adding a few extra steps.

When normally running the terraform plan command, terraform will download the required providers, and then evaluate each resource using providers’ logic, exporting outputs from the resource. Our packaged terraform instead assumes the input of each resource to be the output of the resource, often resulting in a better representation of the actual resource while in an environment where things cannot be resolved.

We then filter the generated terraform plan to remove all sensitive or unnecessary information before sending that plan file to our servers for analysis, and returning the results to you.

Looking to get started with Cloudrail? It’s simple to set up and get running on your local machine!