Create rule S6474: Using remote artifacts without authenticity and integrity checks is security-sensitive (SONARKT-574) (#4720)

rules/S6474/docker/rule.adoc

@@ -208,12 +208,10 @@ ADD \
 RUN make install
 ----
 
-== See
 
-* CWE - https://cwe.mitre.org/data/definitions/384[CWE-345 -  Insufficient Verification of Data Authenticity]
-* https://learn.microsoft.com/en-us/windows-hardware/drivers/install/authenticode[Microsoft, Authenticode Digital Signatures]
+include::../see.adoc[]
+
 * https://www.linux.com/training-tutorials/pgp-web-trust-core-concepts-behind-trusted-communication/[Linux.com, PGP Web of Trust: Core Concepts Behind Trusted Communication]
-* STIG Viewer - https://stigviewer.com/stig/application_security_and_development/2023-06-08/finding/V-222618[Application Security and Development: V-222618] - Unsigned Category 1A mobile code must not be used in the application in accordance with DoD policy.
 
 
 ifdef::env-github,rspecator-view[]

rules/S6474/kotlin/metadata.json

@@ -0,0 +1,19 @@
+{
+  "securityStandards": {
+    "ASVS 4.0": [
+      "10.3.2"
+    ],
+    "OWASP Top 10 2021": [
+      "A8"
+    ],
+    "OWASP Mobile Top 10 2024": [
+      "M2"
+    ],
+    "STIG ASD_V5R3": [
+      "V-222618"
+    ],
+    "CWE": [
+      494
+    ]
+  }
+}

rules/S6474/kotlin/rule.adoc

@@ -0,0 +1,97 @@
+
+Software projects often rely on external code libraries, known as dependencies. Package managers, such as Gradle, allow developers to reference dependencies for their projects.
+These dependencies simplify development, but also introduce risk as they download and include external code based on a project's configuration. 
+Integrity checking is the step of verifying that the downloaded or included dependency code is exactly what the developer expects. Without this verification, the application cannot guarantee that the dependency is legitimate.
+
+Failing to verify the integrity of dependencies before using them is a significant security problem. It exposes your application, and potentially your users, to several risks. The core issue is that you are running code from an untrusted source without checking it, effectively giving an attacker a direct pathway into your application.
+
+This is often a key component of what is called a "supply chain attack." The attacker isn't directly attacking your application. Instead, they are attacking a component you use. This is an important consideration because the attack's source is less obvious. You might diligently secure your own code, but overlook the risk introduced by external dependencies.
+
+== Ask Yourself Whether
+
+* Your team or company has the security policy to enforce dependency verification.
+
+There is a risk if you answer yes to any of these questions.
+
+== Recommended Secure Coding Practices
+
+Create a `verification-metadata.xml` in the `gradle` directory of your project.
+Use `./gradlew --write-verification-metadata pgp,sha256 --export-keys` to bootstrap the file content with PGP key ids and SH256 checksums.
+The `--export-keys` option creates a keyring file containing the identities of all the dependencies publishers trust.
+
+Verify the identity of all publisher keys exported in the local keyring.
+If you cannot verify publisher identities, fallback on checksum-based integrity verification.
+
+Enabling dependency verification in Gradle will add extra friction to your development workflow.
+Make sure your team is aware about this change and has a process to maintain the `verification-metadata.xml` as well as the trusted identities.
+
+== Sensitive Code Example
+
+[source,kotlin]
+----
+dependencies {
+    implementation("com.example:a-dependency:1.0")
+}
+
+configurations { 
+    all {
+        resolutionStrategy {
+            disableDependencyVerification() // Sensitive: dependency verification is disabled
+        }
+    }
+}
+----
+
+Absence of a `verification-metadata.xml` file in the `gradle` directory of your project will also result in the Gradle build not verifying the integrity of the dependencies.
+
+== Compliant Solution
+
+[source,kotlin]
+----
+dependencies {
+    implementation("com.example:adependency:1.0")
+}
+----
+
+[source,xml]
+----
+<verification-metadata 
+    xmlns="https://schema.gradle.org/dependency-verification" 
+    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
+    xsi:schemaLocation="https://schema.gradle.org/dependency-verification https://schema.gradle.org/dependency-verification/dependency-verification-1.3.xsd">
+   <configuration>
+      <verify-metadata>true</verify-metadata>
+      <verify-signatures>true</verify-signatures>
+      <keyring-format>armored</keyring-format>
+      <trusted-keys>
+         <trusted-key id="FD8190C7D72E7DCD42582B1042677B9FC1DC2161" group="com.example" name="adependency"/>
+      </trusted-keys>
+   </configuration>
+</verification-metadata>
+----
+
+include::../see.adoc[]
+
+* Gradle - https://docs.gradle.org/current/userguide/dependency_verification.html[Verifying dependencies]
+
+ifdef::env-github,rspecator-view[]
+
+'''
+== Implementation Specification
+(visible only on this page)
+
+=== Message
+
+* Create a `verification-metadata.xml` file to verify these dependencies against a known checksum or signature
+* Remove this call to `disableDependencyVerification()` so that dependencies are verified
+
+=== Highlighting
+
+* Highlight by order of priority 
+    * The `dependencies` block if it exist
+    * The `plugins` block if it exist
+    * Raise a project-level issue is no `dependencies` or `plugins` block is found
+* Highlight `disableDependencyVerification()`
+
+endif::env-github,rspecator-view[]
+

rules/S6474/metadata.json

@@ -21,11 +21,17 @@
   "sqKey": "S6474",
   "scope": "Main",
   "securityStandards": {
+    "ASVS 4.0": [
+      "10.3.2"
+    ],
+    "OWASP Top 10 2021": [
+      "A8"
+    ],
     "STIG ASD_V5R3": [
       "V-222618"
     ],
     "CWE": [
-      345
+      494
     ]
   },
   "defaultQualityProfiles": [

rules/S6474/see.adoc

@@ -0,0 +1,6 @@
+== See
+
+* OWASP - https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/[Top 10 2021 Category A8 - Software and Data Integrity Failures]
+* OWASP - https://owasp.org/www-project-mobile-top-10/2023-risks/m2-inadequate-supply-chain-security[Mobile Top 10 2024 Category M2 - Inadequate Supply Chain Security]
+* CWE - https://cwe.mitre.org/data/definitions/494[CWE-494 - Download of Code Without Integrity Check]
+* STIG Viewer - https://stigviewer.com/stig/application_security_and_development/2023-06-08/finding/V-222618[Application Security and Development: V-222618] - Unsigned Category 1A mobile code must not be used in the application in accordance with DoD policy.