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.
- 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
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...).
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.
- Java 17
- Go 1.21 and the following dependencies:
- musl on Linux (
musl-gcc
should be present onPATH
) - protoc 25.0
- protoc-gen-go 1.34.1
- musl on Linux (
- Alternatively, Docker should be installed to perform the build of the Go part inside of a container
./gradlew build
./gradlew build -x test
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 all rule descriptions.
./gradlew ruleApiUpdate
Update all rule descriptions for a specific language.
./gradlew ruleApiUpdateArm
./gradlew ruleApiUpdateCloudformation
./gradlew ruleApiUpdateDocker
./gradlew ruleApiUpdateKubernetes
./gradlew ruleApiUpdateTerraform
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
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
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