Update rule metadata (#672)

iac-extensions/cloudformation/sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "CLOUD_FORMATION"
   ],
-  "latest-update": "2023-04-03T19:16:23.688661Z",
+  "latest-update": "2023-05-08T07:13:45.831563776Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": true

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S1135.html

@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p><code>TODO</code> tags are commonly used to mark places where some more code is required, but which the developer wants to implement later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 # TODO
 AWSTemplateFormatVersion: 2010-09-09
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
 </ul>

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S2260.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the CloudFormation parser fails, it is possible to record the failure as a violation on the file. This way, not only it is possible to track
 the number of files that do not parse but also to easily find out why they do not parse.</p>
 

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S4423.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>This rule raises an issue when an insecure TLS protocol version (i.e. a protocol different from "TLSv1.2", "TLSv1.3", "DTLSv1.2", or "DTLSv1.3") is
 used or allowed.</p>
 <p>It is recommended to enforce TLS 1.2 as the minimum protocol version and to disallow older versions like TLS 1.0. Failure to do so could open the
@@ -6,7 +7,7 @@
 <p>In most cases, using the default system configuration is not compliant. Indeed, an application might get deployed on a wide range of systems with
 different configurations. While using a system’s default value might be safe on modern up-to-date systems, this might not be the case on older
 systems. It is therefore recommended to explicitly set a safe configuration in every case.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>For <a href="https://docs.aws.amazon.com/opensearch-service/index.html">Amazon OpenSearch domains</a>:</p>
 <pre>
 AWSTemplateFormatVersion: 2010-09-09
@@ -34,7 +35,7 @@ <h2>Noncompliant Code Example</h2>
   CustomApi: # Noncompliant
     Type: AWS::ApiGatewayV2::DomainName
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>For <a href="https://docs.aws.amazon.com/opensearch-service/index.html">Amazon OpenSearch domains</a>:</p>
 <pre>
 AWSTemplateFormatVersion: 2010-09-09
@@ -65,7 +66,7 @@ <h2>Compliant Solution</h2>
       DomainNameConfigurations:
         - SecurityPolicy: "TLS_1_2"
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A02_2021-Cryptographic_Failures/">OWASP Top 10 2021 Category A2</a> - Cryptographic Failures </li>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6273.html

@@ -1,5 +1,6 @@
+<h2>Why is this an issue?</h2>
 <p>Shared conventions allow teams to collaborate effectively. This rule allows to check that all tag keys match a provided regular expression.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>With default provided regular expression ^([A-Z]<strong>:)</strong>([A-Z][A-Za-z]*)$:</p>
 <pre>
 AWSTemplateFormatVersion: 2010-09-09
@@ -15,7 +16,7 @@ <h2>Noncompliant Code Example</h2>
           Value: "PROD"
 </pre>
 <p>&nbsp;</p>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>&nbsp;</p>
 <pre>
 AWSTemplateFormatVersion: 2010-09-09
@@ -30,7 +31,7 @@ <h2>Compliant Solution</h2>
         - Key: "Anycompany:EnvironmentType"
           Value: "PROD"
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/adopt-a-standardized-approach-for-tag-names.html">AWS
   Documentation</a>: Adopt a Standardized Approach for Tag Names </li>

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6294.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>Some AWS services create <code>Log Groups</code> implicitly and don’t let the developer choose the <code>Log Group</code> name. This means that
 CloudFormation does not require the developer to declare the <code>Log Group</code> that the resource will write to.</p>
 <p>If a <code>Log Group</code> is not declared within CloudFormation, then this <code>Log Group</code> will be automatically created at run time and
@@ -17,7 +18,7 @@
   <li> AWS::ApiGatewayV2::Api </li>
   <li> AWS::CodeBuild::Project </li>
 </ul>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   # There is no "Log Group" declared corresponding to "MyLambdaFunction": logs will not be managed by CloudFormation
   MyLambdaFunction:
@@ -26,7 +27,7 @@ <h2>Noncompliant Code Example</h2>
       Runtime: nodejs12.x
       Description: Example of Lambda Function
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Example with Ref</p>
 <pre>
   MyLambdaFunction:

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6295.html

@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Log streams created on AWS will stay forever unless the <code>AWS::Logs::LogGroup</code> to which they belong to was configured with a retention
 policy. <code>Log Groups</code> should have their “RetentionInDays” property set with a valid value to be sure the log events are kept only for the
 expected duration.</p>
 <p>When the property is not set, the log events will be kept for ever or will be deleted only when the Log Group is removed.</p>
 <p>Keeping the logs for ever doesn’t come for free: AWS will charge for keeping these logs. Also from a security point of view, keeping the data for
 ever may be not compliant with company policy or regulatory rules.</p>
 <p>Note: this rule doesn’t check if the value provided to "RetentionInDays" is valid because AWS CloudFormation Linter (cfn-lint) do it already</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
   MyLambdaFunction:
     Type: AWS::Lambda::Function
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
       LogGroupName: !Join ['/', ['/aws/lambda', !Ref MyLambdaFunction]]
       # Noncompliant: "RetentionInDays" property is not set: logs are kept for ever
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <pre>
   MyLambdaFunction:
     Type: AWS::Lambda::Function

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6302.html

@@ -13,7 +13,7 @@ <h2>Recommended Secure Coding Practices</h2>
 <p>It’s recommended to apply the least privilege principle, i.e. by only granting the necessary permissions to identities. A good practice is to start
 with the very minimum set of permissions and to refine the policy over time. In order to fix overly permissive policies already deployed in
 production, a strategy could be to review the monitored activity in order to reduce the set of permissions to those most used.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Sensitive Code Example</h2>
 <p>A customer-managed policy that grants all permissions by using the wildcard (*) in the <code>Action</code> property:</p>
 <pre>
 MyPolicy:

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6304.html

@@ -10,7 +10,7 @@ <h2>Recommended Secure Coding Practices</h2>
 to organize or <a
 href="https://aws.amazon.com/blogs/security/simplify-granting-access-to-your-aws-resources-by-using-tags-on-aws-iam-users-and-roles/">tag</a>
 resources depending on the sensitivity level of data they store or process. Therefore, managing a secure access control is less prone to errors.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Sensitive Code Example</h2>
 <p>Update permission is granted for all policies using the wildcard (*) in the <code>Resource</code> property:</p>
 <pre>
 MyPolicy:

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6317.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>AWS Identity and Access Management (IAM) is the service that defines access to AWS resources. One of the core components of IAM is the policy
 which, when attached to an identity or a resource, defines its permissions. Policies granting permission to an Identity (a User, a Group or Role) are
 called identity-based policies. They add the ability to an identity to perform a predefined set of actions on a list of resources.</p>
@@ -151,7 +152,7 @@
 <p>The general recommendation to protect against privilege escalation is to restrict the resources to which sensitive permissions are granted. The
 first example above is a good demonstration of sensitive permissions being used with a narrow scope of resources and where no privilege escalation is
 possible.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>This policy allows to update the code of any lambda function. Updating the code of a lambda executing with high privileges will lead to privilege
 escalation.</p>
 <pre>
@@ -172,7 +173,7 @@ <h2>Noncompliant Code Example</h2>
               - lambda:UpdateFunctionCode
             Resource: "*"
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Narrow the policy to only allow to update the code of certain lambda functions.</p>
 <pre>
 AWSTemplateFormatVersion: 2010-09-09
@@ -191,7 +192,7 @@ <h2>Compliant Solution</h2>
               - lambda:UpdateFunctionCode
             Resource: "arn:aws:lambda:us-east-2:123456789012:function:my-function:1"
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://owasp.org/Top10/A01_2021-Broken_Access_Control/">OWASP Top 10 2021 Category A1</a> - Broken Access Control </li>
   <li> <a href="https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/">Rhino Security Labs</a> - AWS IAM Privilege Escalation

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6321.html

@@ -1,11 +1,12 @@
+<h2>Why is this an issue?</h2>
 <p>Cloud platforms such as AWS, Azure, or GCP support virtual firewalls that can be used to restrict access to services by controlling inbound and
 outbound traffic.<br> Any firewall rule allowing traffic from all IP addresses to standard network ports on which administration services
 traditionally listen, such as 22 for SSH, can expose these services to exploits and unauthorized access.</p>
 <h2>Recommended Secure Coding Practices</h2>
 <p>It’s recommended to restrict access to remote administration services to only trusted IP addresses. In practice, trusted IP addresses are those
 held by system administrators or those of <a href="https://aws.amazon.com/quickstart/architecture/linux-bastion/?nc1=h_ls">bastion-like</a>
 servers.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>An ingress rule allowing all inbound SSH traffic:</p>
 <pre>
 MySecurityGroup:
@@ -19,7 +20,7 @@ <h2>Noncompliant Code Example</h2>
           ToPort: 22 # SSH traffic
           CidrIp: "0.0.0.0/0" # from all IP addresses is authorized
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>An ingress rule allowing inbound SSH traffic from specific IP addresses:</p>
 <pre>
 MySecurityGroup:
@@ -33,7 +34,7 @@ <h2>Compliant Solution</h2>
           ToPort: 22
           CidrIp: "1.2.3.0/24"
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/284">MITRE, CWE-284</a> - Improper Access Control </li>
   <li> <a href="https://owasp.org/www-project-top-ten/2017/A5_2017-Broken_Access_Control">OWASP Top 10 2017 Category A5</a> - Broken Access Control

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6329.html

@@ -27,7 +27,7 @@ <h2>Recommended Secure Coding Practices</h2>
 components.</p>
 <p>The goal is to prevent the component from intercepting traffic coming in via the public IP address. If the cloud resource does not support the
 absence of a public IP address, assign a public IP address to it, but do not create listeners for the public IP address.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Sensitive Code Example</h2>
 <p>DMS and EC2 instances have a public IP address assigned to them:</p>
 <pre>
 DMSInstance:

iac-extensions/cloudformation/src/main/resources/org/sonar/l10n/cloudformation/rules/cloudformation/S6333.html

@@ -9,7 +9,7 @@ <h2>Ask Yourself Whether</h2>
 <p>There is a risk if you answered yes to any of those questions.</p>
 <h2>Recommended Secure Coding Practices</h2>
 <p>It’s recommended to restrict API access to authorized entities, unless the API offers a non-sensitive service designed to be public.</p>
-<h2>Noncompliant Code Example</h2>
+<h2>Sensitive Code Example</h2>
 <p>A public API that doesn’t have access control implemented:</p>
 <pre>
 NoncompliantApiGatewayMethod:

iac-extensions/docker/sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "DOCKER"
   ],
-  "latest-update": "2023-04-03T19:15:35.689516Z",
+  "latest-update": "2023-05-08T07:12:57.424818500Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": true

iac-extensions/docker/src/main/java/org/sonar/iac/docker/checks/MountWorldPermissionCheck.java

@@ -23,18 +23,18 @@
 import java.util.regex.Matcher;
 import java.util.regex.Pattern;
 import javax.annotation.CheckForNull;
-import org.sonar.iac.common.api.tree.impl.TextPointer;
-import org.sonar.iac.common.api.tree.impl.TextRange;
 import org.sonar.check.Rule;
 import org.sonar.iac.common.api.checks.CheckContext;
 import org.sonar.iac.common.api.checks.IacCheck;
 import org.sonar.iac.common.api.checks.InitContext;
+import org.sonar.iac.common.api.tree.impl.TextPointer;
+import org.sonar.iac.common.api.tree.impl.TextRange;
 import org.sonar.iac.common.api.tree.impl.TextRanges;
+import org.sonar.iac.docker.checks.utils.CheckUtils;
 import org.sonar.iac.docker.symbols.ArgumentResolution;
 import org.sonar.iac.docker.tree.api.Argument;
 import org.sonar.iac.docker.tree.api.Flag;
 import org.sonar.iac.docker.tree.api.RunInstruction;
-import org.sonar.iac.docker.utils.CheckUtils;
 
 @Rule(key = "S6469")
 public class MountWorldPermissionCheck implements IacCheck {

iac-extensions/docker/src/main/java/org/sonar/iac/docker/checks/utils/CheckUtils.java

@@ -20,8 +20,10 @@
 package org.sonar.iac.docker.checks.utils;
 
 import java.util.List;
+import java.util.Optional;
 import java.util.stream.Collectors;
 import org.sonar.iac.docker.symbols.ArgumentResolution;
+import org.sonar.iac.docker.tree.api.Flag;
 import org.sonar.iac.docker.tree.api.HasArguments;
 
 public class CheckUtils {
@@ -42,4 +44,8 @@ public static String getFileExtension(String name) {
     }
     return name.substring(lastIndexOf + 1);
   }
+
+  public static Optional<Flag> getParamByName(List<Flag> params, String name) {
+    return params.stream().filter(param -> name.equals(param.name())).findFirst();
+  }
 }

iac-extensions/docker/src/main/resources/org/sonar/l10n/docker/rules/docker/S1135.html

@@ -1,12 +1,13 @@
+<h2>Why is this an issue?</h2>
 <p><code>TODO</code> tags are commonly used to mark places where some more code is required, but which the developer wants to implement later.</p>
 <p>Sometimes the developer will not have the time or will simply forget to get back to that tag.</p>
 <p>This rule is meant to track those tags and to ensure that they do not go unnoticed.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <pre>
 # TODO
 FROM ubuntu
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/546">MITRE, CWE-546</a> - Suspicious Comment </li>
 </ul>

iac-extensions/docker/src/main/resources/org/sonar/l10n/docker/rules/docker/S2260.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>When the Dockerfile parser fails, it is possible to record the failure as a violation on the file. This way, not only is it possible to track the
 number of files that do not parse but also to easily find out why they do not parse.</p>
 

iac-extensions/docker/src/main/resources/org/sonar/l10n/docker/rules/docker/S4423.html

@@ -1,3 +1,4 @@
+<h2>Why is this an issue?</h2>
 <p>This rule raises an issue when an insecure TLS protocol version (i.e. a protocol different from "TLSv1.2", "TLSv1.3", "DTLSv1.2", or "DTLSv1.3") is
 used or allowed.</p>
 <p>It is recommended to enforce TLS 1.2 as the minimum protocol version and to disallow older versions like TLS 1.0. Failure to do so could open the
@@ -6,7 +7,7 @@
 <p>In most cases, using the default system configuration is not compliant. Indeed, an application might get deployed on a wide range of systems with
 different configurations. While using a system’s default value might be safe on modern up-to-date systems, this might not be the case on older
 systems. It is therefore recommended to explicitly set a safe configuration in every case.</p>
-<h2>Noncompliant Code Example</h2>
+<h3>Noncompliant code example</h3>
 <p>HTTP request tools such as <code>curl</code>, <code>wget</code> and <code>Invoke-WebRequest</code> offer the option to choose the version of
 SSL/TLS that will be used for requests. The following example successfully requests data from a server with an insecure version of TLS. Thus, it is
 possible that the response was intercepted or tampered with by a third party.</p>
@@ -16,15 +17,15 @@ <h2>Noncompliant Code Example</h2>
 # Noncompliant
 RUN curl --tlsv1.0 -O https://tlsv1-0.example.com/downloads/install.sh
 </pre>
-<h2>Compliant Solution</h2>
+<h3>Compliant solution</h3>
 <p>Choosing a recent, secure version of TLS ensures that the created TLS session is secure and cannot be intercepted. In this example, the minimal
 version of TLS is set to TLSv1.2, guaranteeing that requests can only be sent over TLSv1.2 or TLSv1.3.</p>
 <pre>
 FROM ubuntu:22.04
 
 RUN curl --tlsv1.2 -O https://tlsv1-3.example.com/downloads/install.sh
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> <a href="https://cwe.mitre.org/data/definitions/326">MITRE, CWE-327</a> - Inadequate Encryption Strength </li>
   <li> <a href="https://cwe.mitre.org/data/definitions/327">MITRE, CWE-326</a> - Use of a Broken or Risky Cryptographic Algorithm </li>