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

Notifications You must be signed in to change notification settings

SonarSource/sonar-iac

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

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:
    • AWS 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 registration point of the plugin to the API is in sonar-iac-plugin. The analyses of the different languages are separated into "extensions", which get loaded by the main plugin class and are structured similarly 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 a 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 the 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)
  • Alternatively, Docker should be installed to perform the build of the Go part inside 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 standard 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 languages, 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 ("ITS") 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, while the actual ones are saved in its/ruling/build/reports/lits/actual. To run the ruling ITS:

  • Make sure the project is built with the latest changes
  • Load/update the analyzed files:
  git submodule update --init
  • Run:
./gradlew :its:ruling:integrationTest

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

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

The SonarQube URL can be found in the logs of the test execution, and the instance can be stopped at any time by pressing "Ctrl+C".

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 all properties get registered. To run them:

./gradlew :its:plugin:integrationTest

About

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

Resources

License

Security policy

Stars

Watchers

Forks