Products
In-IDE
IDE extension that lets you fix coding issues before they exist!
Discover SonarLint
SaaS
Setup is effortless and analysis is automatic for most languages
Discover SonarCloud
Self-Hosted
Fast, accurate analysis; enterprise scalability
Discover SonarQube

Secrets
ABAP
Ansible
Apex
AzureResourceManager
C
C#
C++
CloudFormation
COBOL
CSS
Dart
Docker
Flex
Go
HTML
Java
JavaScript
JCL
Kotlin
Kubernetes
Objective C
PHP
PL/I
PL/SQL
Python
RPG
Ruby
Scala
Swift
Terraform
Text
TypeScript
T-SQL
VB.NET
VB6
XML

AzureResourceManager static code analysis

Unique rules to find Vulnerabilities, Security Hotspots, and Code Smells in your AZURERESOURCEMANAGER code

Tags

Impact

Clean code attribute

Credentials should not be hard-coded
Vulnerability
Allowing public network access to cloud resources is security-sensitive
Security Hotspot
Template evaluation should not expose secure values
Vulnerability
Secure strings and objects should not have default values
Vulnerability
Weak SSL/TLS protocols should not be used
Vulnerability
Using clear-text protocols is security-sensitive
Security Hotspot
String literals should not be duplicated
Code Smell
Azure custom roles should not grant subscription Owner capabilities
Vulnerability
Defining a short log retention duration is security-sensitive
Security Hotspot
Using unencrypted cloud storages is security-sensitive
Security Hotspot
Azure role assignments that grant access to all resources of a subscription are security-sensitive
Security Hotspot
Disabling Role-Based Access Control on Azure resources is security-sensitive
Security Hotspot
Disabling certificate-based authentication is security-sensitive
Security Hotspot
Assigning high privileges Azure Resource Manager built-in roles is security-sensitive
Security Hotspot
Authorizing anonymous access to Azure resources is security-sensitive
Security Hotspot
Enabling Azure resource-specific admin accounts is security-sensitive
Security Hotspot
Disabling Managed Identities for Azure resources is security-sensitive
Security Hotspot
Defining a short backup retention duration is security-sensitive
Security Hotspot
The resource elements should appear in the recommended order
Code Smell
Elements should not be empty or null
Code Smell
Don't use "allowedValues" for a location parameter
Code Smell
Redundant explicit dependencies between resources should be removed
Code Smell
Don't hardcode resource locations
Code Smell
Use a hard-coded value for the apiVersion
Code Smell
Administration services access should be restricted to specific IP addresses
Vulnerability
Delivering code in production with debug features activated is security-sensitive
Security Hotspot
The properties should appear in the recommended order
Code Smell
Unused parameters should be removed
Code Smell
Unused local variables should be removed
Code Smell
Parameter and variable names should comply with a naming convention
Code Smell
Track uses of "TODO" tags
Code Smell
AzureResourceManager parsing failure
Code Smell

The resource elements should appear in the recommended order

consistency - conventional

maintainability

Code Smell

MajorSonarSource default severity
click to learn more

Why is this an issue?

How can I fix it?

More Info

According to the best practices defined by Azure, a consistent order of elements in a templates is recommended. This makes it easier to read and understand the template.

Not following this convention has no technical impact, but will reduce the template’s readability because most developers are used to the standard order.

Available In:

Catch issues on the fly,
in your IDE

Detect issues in your GitHub, Azure DevOps Services, Bitbucket Cloud, GitLab repositories

Analyze code in your
on-premise CI

© 2008-2024 SonarSource SA. All rights reserved. SONAR, SONARSOURCE, SONARQUBE, and CLEAN AS YOU CODE are trademarks of SonarSource SA.

Sonar helps developers write Clean Code.
Privacy Policy | Cookie Policy

In-IDE

SaaS

Self-Hosted