Skip to content

Static Code Analyser for Infrastructure-as-Code languages such as CloudFormation and Terraform as well as DevOps like Docker and Kubernetes

License

SonarSource/sonar-iac

Repository files navigation

Code Quality and Security for Infrastructure-as-Code

Build Status

This SonarSource project is a static code analyzer for Infrastructure-as-Code (IaC) languages such as CloudFormation, Kubernetes, and Terraform. It is a component of the SonarQube platform and it runs the IaC features on SonarCloud.

It allows you to produce stable and easily supported Clean Code by helping you find and correct vulnerabilities and code smells in your projects.

Features

  • 100+ rules
  • Supports Azure Resource Manager JSON
  • Supports CloudFormation JSON/YAML
  • Supports Kubernetes YAML
  • Supports Dockerfiles
  • Supports Terraform for AWS
    • HCL native syntax for files named with a .tf suffix (JSON format not supported)
    • Terraform for Azure and GCP: coming soon
  • Domains Covered:
    • ASW S3 Buckets
    • Permissions
    • Encryption at Rest
    • Encryption at Transit (coming soon)
    • Traceability (coming soon)
  • Metrics (number of lines, comments, etc.)
  • Import of cfn-lint results

Useful links

Structure

This project is one analyzer/plugin that scans and raises issues on files associated with multiple languages. Currently, these languages are CloudFormation, Kubernetes, and Terraform.

The main point of registration of the plugin to the API is in sonar-iac-plugin. The analyses of the different languages is separated into "extensions" which get loaded by the main plugin class, and which are structured in a way similar to other analyzers (i.e., parser, visitors, checks, rule resources, etc...).

Using sonar-rule-api:

When using the sonar-rule-api to generate or update metadata of rules it has to be done in the different extension folders: to update/generate rule for AzureResourceManager, run sonar-rule-api in iac-extensions/arm, for CloudFormation, run sonar-rule-api in iac-extensions/cloudformation, for Docker, in iac-extensions/docker, for Kubernetes in iac-extensions/kubernetes and for Terraform in iac-extensions/terraform.

Alternatively, execute Gradle task ruleApiUpdate to update rule metadata for all extensions.

Build & Test

Requirements

  • Java 17
  • Go 1.21 and the following dependencies:
    • musl on Linux (musl-gcc should be present on PATH)
    • protoc 25.0
    • protoc-gen-go 1.34.1
  • Alternatively, Docker should be installed to perform the build of the Go part inside of a container

Build and run unit tests:

./gradlew build

Build without running unit tests:

./gradlew build -x test

Fix code formatting issues

During the Gradle build a spotless formatting check is executed. This check can also be triggered manually with ./gradlew spotlessCheck. It checks if the code is correctly formatted using common Sonar rules. If your build failed, you can fix the formatting just by running:

./gradlew spotlessApply

Update rule description

Update all rule descriptions.

./gradlew ruleApiUpdate

Update all rule descriptions for a specific language.

./gradlew ruleApiUpdateArm
./gradlew ruleApiUpdateCloudformation
./gradlew ruleApiUpdateDocker
./gradlew ruleApiUpdateKubernetes
./gradlew ruleApiUpdateTerraform

Generate new rule description

To fetch static files for a rule SXXXX from RSPEC for one of the language, execute the following command:

./gradlew ruleApiUpdateRuleArm -Prule=SXXXX
./gradlew ruleApiUpdateRuleCloudformation -Prule=SXXXX
./gradlew ruleApiUpdateRuleDocker -Prule=SXXXX
./gradlew ruleApiUpdateRuleKubernetes -Prule=SXXXX
./gradlew ruleApiUpdateRuleTerraform -Prule=SXXXX

Ruling integration tests

These integration tests verify that, given a set of files, when the analyzer is run on them, all the expected issues get raised in a prepared SonarQube instance. The expected findings are saved in its/ruling/src/integrationTest/resources/expected. To run the ruling ITS:

  • Make sure the project is built with the latest changes

  • Load/update the analyzed files: git submodule update --init

  • In its/ruling run:

    ./gradlew :its:ruling:integrationTest

It is possible to keep the prepared SonarQube instance running to better inspect actual-vs-expected differences (if there are any) in the SQ UI. For this use:

./gradlew :its:ruling:integrationTest -DkeepSonarqubeRunning=true

Plugin integration tests

These integration tests verify that the analyzer registers at and interacts with the SonarQube API correctly. For example: if file metrics get sent, and if all properties get registered. To run them, in ìts/plugin run:

./gradlew :its:plugin:integrationTest