SONARJAVA-4468 Update rule metadata (#4368)

java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2326.json

@@ -7,17 +7,11 @@
     "constantCost": "5min"
   },
   "tags": [
-    "cert",
     "unused"
   ],
   "defaultSeverity": "Major",
   "ruleSpecification": "RSPEC-2326",
   "sqKey": "S2326",
   "scope": "All",
-  "quickfix": "unknown",
-  "securityStandards": {
-    "CERT": [
-      "MSC12-CPP."
-    ]
-  }
+  "quickfix": "unknown"
 }

java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S2589.json

@@ -8,7 +8,6 @@
   },
   "tags": [
     "cwe",
-    "cert",
     "suspicious",
     "redundant"
   ],
@@ -17,9 +16,6 @@
   "sqKey": "S2589",
   "scope": "All",
   "securityStandards": {
-    "CERT": [
-      "MSC12-C."
-    ],
     "CWE": [
       489,
       571,

java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5659.json

@@ -8,8 +8,7 @@
   },
   "tags": [
     "cwe",
-    "privacy",
-    "cert"
+    "privacy"
   ],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-5659",

java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S5693.json

@@ -7,8 +7,7 @@
     "constantCost": "5min"
   },
   "tags": [
-    "cwe",
-    "cert"
+    "cwe"
   ],
   "defaultSeverity": "Major",
   "ruleSpecification": "RSPEC-5693",

java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S6418.html

@@ -1,36 +1,38 @@
+<p>Secrets should not be hard-coded in source code, instead be stored outside of the source code in a configuration file or a management service for
+secrets.</p>
+<p>There would be a risk, if any of the following apply to you:</p>
+<ul>
+  <li> The secret allows access to a sensitive component like a database, a file storage, an API, or a service. </li>
+  <li> The secret is used in a production environment. </li>
+  <li> Application re-distribution is required before updating the secret. </li>
+</ul>
+<h2>Why is this an issue?</h2>
 <p>Because it is easy to extract strings from an application source code or binary, secrets should not be hard-coded. This is particularly true for
 applications that are distributed or that are open-source.</p>
 <p>In the past, it has led to the following vulnerabilities:</p>
 <ul>
   <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-25510">CVE-2022-25510</a> </li>
   <li> <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-42635">CVE-2021-42635</a> </li>
 </ul>
-<p>Secrets should be stored outside of the source code in a configuration file or a management service for secrets.</p>
 <p>This rule detects variables/fields having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a
 pseudorandom hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The
 randomness sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.</p>
-<h2>Ask Yourself Whether</h2>
-<ul>
-  <li> The secret allows access to a sensitive component like a database, a file storage, an API, or a service. </li>
-  <li> The secret is used in a production environment. </li>
-  <li> Application re-distribution is required before updating the secret. </li>
-</ul>
-<p>There would be a risk if you answered yes to any of those questions.</p>
-<h2>Recommended Secure Coding Practices</h2>
+<h2>How to fix it</h2>
 <ul>
   <li> Store the secret in a configuration file that is not pushed to the code repository. </li>
   <li> Use your cloud provider’s service for managing secrets. </li>
   <li> If a secret has been disclosed through the source code: revoke it and create a new one. </li>
 </ul>
-<h2>Sensitive Code Example</h2>
+<h3>Code examples</h3>
+<h4>Noncompliant code example</h4>
 <pre>
 private static final String MY_SECRET = "47828a8dd77ee1eb9dde2d5e93cb221ce8c32b37";
 
 public static void main(String[] args) {
   MyClass.callMyService(MY_SECRET);
 }
 </pre>
-<h2>Compliant Solution</h2>
+<h4>Compliant solution</h4>
 <p>Using <a href="https://github.com/awsdocs/aws-doc-sdk-examples/tree/main/javav2/example_code/secretsmanager">AWS Secrets Manager</a>:</p>
 <pre>
 import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueRequest;
@@ -80,7 +82,12 @@ <h2>Compliant Solution</h2>
   MyClass.callMyService(secret);
 }
 </pre>
-<h2>See</h2>
+<h3>How does this work?</h3>
+<p>This rule detects variables/fields having a name matching a list of words (secret, token, credential, auth, api[_.-]?key) being assigned a
+pseudorandom hard-coded value. The pseudorandomness of the hard-coded value is based on its entropy and the probability to be human-readable. The
+randomness sensibility can be adjusted if needed. Lower values will detect less random values, raising potentially more false positives.</p>
+<h2>Resources</h2>
+<h3>Documentation</h3>
 <ul>
   <li> <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">OWASP Top 10 2021 Category A7</a> - Identification and
   Authentication Failures </li>

java-checks/src/main/resources/org/sonar/l10n/java/rules/java/S923.html

@@ -10,4 +10,9 @@ <h2>Noncompliant Code Example</h2>
   // ...
 }
 </pre>
+<h2>See</h2>
+<ul>
+  <li> <a href="https://wiki.sei.cmu.edu/confluence/display/java/DCL57-J.+Avoid+ambiguous+overloading+of+variable+arity+methods">CERT, DCL57J</a> -
+  Avoid ambiguous overloading of variable arity methods </li>
+</ul>
 

sonarpedia.json

@@ -3,7 +3,7 @@
   "languages": [
     "JAVA"
   ],
-  "latest-update": "2023-04-14T08:47:34.859660Z",
+  "latest-update": "2023-05-01T09:54:08.085850Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": false