Update rule metadata and parent POM version (#4755)

Author: kaufco

its/autoscan/src/test/resources/autoscan/diffs/diff_S2647.json

@@ -5,7 +5,7 @@
   <parent>
     <groupId>org.sonarsource.parent</groupId>
     <artifactId>parent</artifactId>
-    <version>71.0.0.1292</version>
+    <version>71.0.0.1314</version>
   </parent>
 
   <groupId>org.sonarsource.java</groupId>

pom.xml

@@ -19,5 +19,5 @@
   "ruleSpecification": "RSPEC-1153",
   "sqKey": "S1153",
   "scope": "All",
-  "quickfix": "targeted"
+  "quickfix": "covered"
 }

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S1153.json

@@ -1,3 +1,4 @@
+<p>This rule is deprecated, and will eventually be removed.</p>
 <p>Basic authentication is a vulnerable method of user authentication that should be avoided. It functions by transmitting a Base64 encoded username
 and password. As Base64 is easy to recognize and reverse, sensitive data may be leaked this way.</p>
 <h2>Why is this an issue?</h2>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2647.html

@@ -7,14 +7,12 @@
     },
     "attribute": "TRUSTWORTHY"
   },
-  "status": "ready",
+  "status": "deprecated",
   "remediation": {
     "func": "Constant\/Issue",
     "constantCost": "2h"
   },
-  "tags": [
-    "cwe"
-  ],
+  "tags": [],
   "defaultSeverity": "Critical",
   "ruleSpecification": "RSPEC-2647",
   "sqKey": "S2647",

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S2647.json

@@ -1,19 +1,19 @@
-<p>When using <code>SecureRandom</code>, it is important not to use predictable seeds. This class is used to generate cryptographically strong random
-numbers. Using a predictable seed will make its output predictable as well, which counteracts the use case of <code>SecureRandom</code>.</p>
+<p>Cryptographic operations often rely on unpredictable random numbers to enhance security. These random numbers are created by cryptographically
+secure pseudo-random number generators (CSPRNG). It is important not to use a predictable seed with these random number generators otherwise the
+random numbers will also become predictable.</p>
 <h2>Why is this an issue?</h2>
-<p><code>java.security.SecureRandom</code> is often used to generate random values for cryptographic algorithms. When a random number generator is
-used for cryptographic purposes, the generated numbers must be as random and unpredictable as possible. When <code>SecureRandom</code> is improperly
-seeded with a constant or a predictable value, its output will also be predictable.</p>
+<p>Random number generators are often used to generate random values for cryptographic algorithms. When a random number generator is used for
+cryptographic purposes, the generated numbers must be as random and unpredictable as possible. When the random number generator is improperly seeded
+with a constant or a predictable value, its output will also be predictable.</p>
 <p>This can have severe security implications for cryptographic operations that rely on the randomness of the generated numbers. By using a
 predictable seed, an attacker can potentially guess or deduce the generated numbers, compromising the security of whatever cryptographic algorithm
-relies on <code>SecureRandom</code>.</p>
+relies on the random number generator.</p>
 <h3>What is the potential impact?</h3>
 <p>It is crucial to understand that the strength of cryptographic algorithms heavily relies on the quality of the random numbers used. By improperly
-seeding the <code>SecureRandom</code> class, we introduce a significant weakness that can be exploited by attackers.</p>
+seeding a CSPRNG, we introduce a significant weakness that can be exploited by attackers.</p>
 <h4>Insecure cryptographic keys</h4>
-<p>One of the primary use cases for the <code>SecureRandom</code> class is generating cryptographic keys. If an attacker can predict the seed used to
-initialize the SecureRandom instance, they may be able to derive the same keys. Depending on the use case, this can lead to multiple severe outcomes,
-such as:</p>
+<p>One of the primary use cases for CSPRNGs is generating cryptographic keys. If an attacker can predict the seed used to initialize the random number
+generator, they may be able to derive the same keys. Depending on the use case, this can lead to multiple severe outcomes, such as:</p>
 <ul>
   <li> Being able to decrypt sensitive documents, leading to privacy breaches or identity theft. </li>
   <li> Gaining access to a private key used for signing, allowing an attacker to forge digital signatures and impersonate legitimate entities. </li>

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4347.html

@@ -1,5 +1,5 @@
 {
-  "title": "\"SecureRandom\" seeds should not be predictable",
+  "title": "Secure random number generators should not output predictable values",
   "type": "VULNERABILITY",
   "code": {
     "impacts": {

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S4347.json

@@ -1,7 +1,7 @@
 <h2>Why is this an issue?</h2>
 <p>Many existing switch statements are essentially simulations of switch expressions, where each arm either assigns to a common target variable or
 returns a value. Expressing this as a statement is roundabout, repetitive, and error-prone.</p>
-<p>Java 12 added support for switch expressions, which provide more succinct and less error-prone version of switch.</p>
+<p>Java 14 added support for switch expressions, which provide more succinct and less error-prone version of switch.</p>
 <h3>Noncompliant code example</h3>
 <pre>
 void day_of_week(DoW day) {

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S5194.html

@@ -1,5 +1,5 @@
 {
-  "title": "Use Java 12 \"switch\" expression",
+  "title": "Use Java 14 \"switch\" expression",
   "type": "CODE_SMELL",
   "code": {
     "impacts": {
@@ -13,7 +13,7 @@
     "constantCost": "5min"
   },
   "tags": [
-    "java12"
+    "java14"
   ],
   "defaultSeverity": "Minor",
   "ruleSpecification": "RSPEC-5194",

sonar-java-plugin/src/main/resources/org/sonar/l10n/java/rules/java/S5194.json

@@ -3,7 +3,7 @@
 <h2>Why is this an issue?</h2>
 <p>The <code>@Value</code> annotation does not guarantee that the property is defined. Particularly if a field or parameter is annotated as nullable,
 it indicates that the developer assumes that the property may be undefined.</p>
-<p>An undefined property may lead to a runtime exceptions when the Spring framework tries to inject the autowired dependency during bean creation.</p>
+<p>An undefined property may lead to runtime exceptions when the Spring framework tries to inject the autowired dependency during bean creation.</p>
 <p>This rule raises an issue when a nullable field or parameter is annotated with <code>@Value</code> and no default value is provided.</p>
 <h2>How to fix it</h2>
 <p>Add a default value to the <code>@Value</code> annotation. A default value can be supplied by using the colon (<code>:</code>) operator. As the