Create rule S8324: File paths should not be hardcoded

rules/S8324/groovy/metadata.json

@@ -0,0 +1,28 @@
+{
+  "title": "File paths should not be hardcoded",
+  "type": "CODE_SMELL",
+  "status": "ready",
+  "remediation": {
+    "func": "Constant/Issue",
+    "constantCost": "10 min"
+  },
+  "tags": [
+    "configuration",
+    "portability"
+  ],
+  "defaultSeverity": "Blocker",
+  "ruleSpecification": "RSPEC-8324",
+  "sqKey": "S8324",
+  "scope": "Main",
+  "defaultQualityProfiles": [
+    "Sonar way"
+  ],
+  "quickfix": "unknown",
+  "code": {
+    "impacts": {
+      "RELIABILITY": "BLOCKER",
+      "MAINTAINABILITY": "BLOCKER"
+    },
+    "attribute": "CONVENTIONAL"
+  }
+}

rules/S8324/groovy/rule.adoc

@@ -0,0 +1,56 @@
+This rule raises an issue when file paths are hardcoded as string literals in the source code.
+
+== Why is this an issue?
+
+Hardcoding file paths directly in source code creates several significant problems that affect code quality and application reliability.
+
+The most immediate issue is *portability*. Different operating systems use different path conventions - Windows uses backslashes (`\`) and drive letters (`C:`), while Unix-like systems (Linux, macOS) use forward slashes (`/`) and have no drive letters. A path like `"E:\\data\\file.csv"` will only work on Windows systems and will fail on Linux or macOS.
+
+Hardcoded paths also create *maintainability problems*. When file locations need to change - which happens frequently during deployment to different environments (development, testing, production) - developers must modify and recompile the source code. This violates the principle of separating configuration from code.
+
+From a *security perspective*, hardcoded paths can expose sensitive information about the system's directory structure. They may also make applications vulnerable to path traversal attacks if the paths are constructed unsafely.
+
+Finally, hardcoded paths make *testing difficult*. Unit tests cannot easily redirect file operations to temporary directories, making tests dependent on specific file system states.
+
+=== What is the potential impact?
+
+Applications with hardcoded file paths will fail when deployed to different operating systems or environments. This leads to deployment failures, runtime exceptions, and increased maintenance overhead. The code becomes tightly coupled to specific system configurations, making it difficult to test and deploy reliably.
+
+== How to fix it
+
+Use system properties to make file paths configurable. This allows the path to be specified at runtime without changing the code.
+
+=== Code examples
+
+==== Noncompliant code example
+
+[source,groovy,diff-id=1,diff-type=noncompliant]
+----
+FileWriter fw = new FileWriter("E:\\RAF02Nov\\skp.csv") // Noncompliant
+----
+
+==== Compliant solution
+
+[source,groovy,diff-id=1,diff-type=compliant]
+----
+String filePath = System.getProperty("output.file.path", "./output.csv")
+FileWriter fw = new FileWriter(filePath)
+----
+
+== Resources
+
+=== Documentation
+
+ * Groovy File I/O Documentation - https://groovy-lang.org/working-with-io.html[Official Groovy documentation on file handling and I/O operations]
+
+ * Java System Properties - https://docs.oracle.com/javase/tutorial/essential/environment/sysprop.html[Oracle documentation on using system properties for configuration]
+
+ * Cross-platform Path Handling - https://docs.oracle.com/javase/8/docs/api/java/nio/file/Paths.html[Java NIO documentation for platform-independent path handling]
+
+=== Standards
+
+ * CWE-426: Untrusted Search Path - https://cwe.mitre.org/data/definitions/426.html[Weakness related to using untrusted search paths that can be exploited]
+
+=== Related rules
+
+ * RSPEC-1075 - https://rules.sonarsource.com/java/RSPEC-1075/[URIs should not be hardcoded - related rule for Java]

rules/S8324/metadata.json

@@ -0,0 +1,2 @@
+{
+}