SONARJAVA-6127 Update rule metadata

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

@@ -1,50 +1,39 @@
-<p>Because it is easy to extract strings from an application source code or binary, passwords should not be hard-coded. This is particularly true for
-applications that are distributed or that are open-source.</p>
+<h2>Why is this an issue?</h2>
+<p>Hard-coding credentials in source code or binaries makes it easy for attackers to extract sensitive information, especially in distributed or
+open-source applications. This practice exposes your application to significant security risks.</p>
+<p>This rule flags instances of hard-coded credentials used in database and LDAP connections. It looks for hard-coded credentials in connection
+strings, and for variable names that match any of the patterns from the provided list.</p>
 <p>In the past, it has led to the following vulnerabilities:</p>
 <ul>
   <li> <a href="https://www.cve.org/CVERecord?id=CVE-2019-13466">CVE-2019-13466</a> </li>
   <li> <a href="https://www.cve.org/CVERecord?id=CVE-2018-15389">CVE-2018-15389</a> </li>
 </ul>
-<p>Passwords should be stored outside of the code in a configuration file, a database, or a password management service.</p>
-<p>This rule flags instances of hard-coded passwords used in database and LDAP connections. It looks for hard-coded passwords in connection strings,
-and for variable names that match any of the patterns from the provided list.</p>
-<h2>Ask Yourself Whether</h2>
-<ul>
-  <li> The password allows access to a sensitive component like a database, a file storage, an API, or a service. </li>
-  <li> The password is used in production environments. </li>
-  <li> Application re-distribution is required before updating the password. </li>
-</ul>
-<p>There would be a risk if you answered yes to any of those questions.</p>
-<h2>Recommended Secure Coding Practices</h2>
-<ul>
-  <li> Store the credentials in a configuration file that is not pushed to the code repository. </li>
-  <li> Store the credentials in a database. </li>
-  <li> Use your cloud provider’s service for managing secrets. </li>
-  <li> If a password has been disclosed through the source code: change it. </li>
-</ul>
-<h2>Sensitive Code Example</h2>
-<pre>
+<h2>How to fix it</h2>
+<p>Credentials should be stored in a configuration file that is not committed to the code repository, in a database, or managed by your cloud
+provider’s secrets management service. If a password is exposed in the source code, it must be changed immediately.</p>
+<h3>Code Examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 String username = "steve";
 String password = "blue";
 Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
-                  "user=" + username + "&amp;password=" + password); // Sensitive
+                  "user=" + username + "&amp;password=" + password); // Noncompliant
 </pre>
-<h2>Compliant Solution</h2>
-<pre>
+<h4>Compliant solution</h4>
+<pre data-diff-id="1" data-diff-type="compliant">
 String username = getEncryptedUser();
 String password = getEncryptedPassword();
 Connection conn = DriverManager.getConnection("jdbc:mysql://localhost/test?" +
                   "user=" + username + "&amp;password=" + password);
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> OWASP - <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">Top 10 2021 Category A7 - Identification and
   Authentication Failures</a> </li>
   <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">Top 10 2017 Category A2 - Broken Authentication</a>
   </li>
   <li> CWE - <a href="https://cwe.mitre.org/data/definitions/798">CWE-798 - Use of Hard-coded Credentials</a> </li>
   <li> CWE - <a href="https://cwe.mitre.org/data/definitions/259">CWE-259 - Use of Hard-coded Password</a> </li>
-  <li> <a href="https://wiki.sei.cmu.edu/confluence/x/OjdGBQ">CERT, MSC03-J.</a> - Never hard code sensitive information </li>
   <li> Derived from FindSecBugs rule <a href="https://h3xstream.github.io/find-sec-bugs/bugs.htm#HARD_CODE_PASSWORD">Hard Coded Password</a> </li>
 </ul>
 

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

@@ -1,6 +1,6 @@
 {
-  "title": "Hard-coded passwords are security-sensitive",
-  "type": "SECURITY_HOTSPOT",
+  "title": "Credentials should not be hard-coded",
+  "type": "VULNERABILITY",
   "code": {
     "impacts": {
       "SECURITY": "BLOCKER"
@@ -12,6 +12,7 @@
     "func": "Constant\/Issue",
     "constantCost": "30min"
   },
+  "quickfix": "infeasible",
   "tags": [
     "cwe",
     "cert"
@@ -45,6 +46,5 @@
       "3.5.2",
       "6.4.1"
     ]
-  },
-  "quickfix": "unknown"
+  }
 }

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

@@ -1,38 +1,24 @@
-<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="https://www.cve.org/CVERecord?id=CVE-2022-25510">CVE-2022-25510</a> </li>
-  <li> <a href="https://www.cve.org/CVERecord?id=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>
+<h2>Why is this an issue?</h2>
+<p>Hard-coding secrets in source code or binaries makes it easy for attackers to extract sensitive information, especially in distributed or
+open-source applications. This practice exposes credentials and tokens, increasing the risk of unauthorized access and data breaches.</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>
-<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>
-<pre>
+<h2>How to fix it</h2>
+<p>Secrets should be stored in a configuration file that is not committed to the code repository, in a database, or managed by your cloud provider’s
+secrets management service. If a secret is exposed in the source code, it must be rotated immediately.</p>
+<h3>Code Examples</h3>
+<h4>Noncompliant code example</h4>
+<pre data-diff-id="1" data-diff-type="noncompliant">
 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/secrets-manager">AWS Secrets Manager</a>:</p>
-<pre>
+<pre data-diff-id="1" data-diff-type="compliant">
 import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueRequest;
 import software.amazon.awssdk.services.secretsmanager.model.GetSecretValueResponse;
 
@@ -80,15 +66,15 @@ <h2>Compliant Solution</h2>
   MyClass.callMyService(secret);
 }
 </pre>
-<h2>See</h2>
+<h2>Resources</h2>
 <ul>
   <li> OWASP - <a href="https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/">Top 10 2021 Category A7 - Identification and
   Authentication Failures</a> </li>
   <li> OWASP - <a href="https://owasp.org/www-project-top-ten/2017/A2_2017-Broken_Authentication">Top 10 2017 Category A2 - Broken Authentication</a>
   </li>
   <li> CWE - <a href="https://cwe.mitre.org/data/definitions/798">CWE-798 - Use of Hard-coded Credentials</a> </li>
+  <li> MSC - <a href="https://wiki.sei.cmu.edu/confluence/x/OjdGBQ">MSC03-J - Never hard code sensitive information</a> </li>
   <li> OWASP - <a href="https://owasp.org/www-project-mobile-top-10/2023-risks/m1-improper-credential-usage.html">Mobile Top 10 2024 Category M1 -
   Improper Credential Usage</a> </li>
-  <li> MSC - <a href="https://wiki.sei.cmu.edu/confluence/x/OjdGBQ">MSC03-J - Never hard code sensitive information</a> </li>
 </ul>
 

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

@@ -1,6 +1,6 @@
 {
-  "title": "Hard-coded secrets are security-sensitive",
-  "type": "SECURITY_HOTSPOT",
+  "title": "Secrets should not be hard-coded",
+  "type": "VULNERABILITY",
   "code": {
     "impacts": {
       "SECURITY": "BLOCKER"
@@ -12,6 +12,7 @@
     "func": "Constant\/Issue",
     "constantCost": "30min"
   },
+  "quickfix": "infeasible",
   "tags": [
     "cwe",
     "cert"
@@ -47,6 +48,5 @@
       "3.5.2",
       "6.4.1"
     ]
-  },
-  "quickfix": "unknown"
+  }
 }

sonarpedia.json

@@ -3,9 +3,9 @@
   "languages": [
     "JAVA"
   ],
-  "latest-update": "2026-02-10T09:09:57.194517400Z",
+  "latest-update": "2026-02-13T15:26:51.447713Z",
   "options": {
     "no-language-in-filenames": true,
     "preserve-filenames": false
   }
-}
+}