Diagnosing False‑Positive Hardcoded Secret Warnings in Codeac for Java Test Code

Recognizable Condition

Codeac static analysis raises a "Hardcoded secret" warning on a string literal that is actually a configuration placeholder used only in unit tests (e.g., a JDBC URL or API key placeholder). The warning appears despite the string never being shipped in production code.

Cause / Diagnostic Table

Cause	Diagnostic Indicator
The placeholder string matches Codeac’s secret‑pattern regex (e.g., resembles a password, token, or URL with credentials)	Check whether the file resides under src/test/java or is annotated with a test framework annotation such as @Test, @BeforeEach, or @SpringBootTest
The rule is triggered because the analysis does not distinguish test from production sources	Verify that the string is not referenced from any class in src/main/java via a call‑graph inspection

Ordered Checks

1. Verify file location – Ensure the warning originates from a file under src/test/java (or the configured test source set). Required permission: read access to the source tree.
2. Look for test annotations – Open the file and search for JUnit/TestNG annotations (@Test, @Before, etc.). If present, the code is test‑only.
3. Confirm absence in production code – Run a simple grep across src/main/java for the exact string literal. No matches indicate the string is not used in production.
4. Check for externalization – Determine whether the string should be externalized via a properties file or a configuration utility (e.g., Config.getProperty("db.url")). If it is already externalized, the warning is a false positive.

Fixes Tied to Findings

• If the string is a test‑only placeholder – Add a suppression comment directly above the line:

  // Codeac:ignore HardcodedSecret
  String dbUrl = "jdbc:postgresql://localhost:5432/mydb";
  

  Alternatively, adjust the rule severity in codeac-rules.xml for the test source set only.
• If the placeholder should be externalized – Replace the literal with a call to your configuration mechanism, e.g.,

  String dbUrl = Config.getProperty("jdbc.url");
  

  Then re‑run the analysis to confirm the warning disappears.

Escalation Criteria

• The warning appears in a file under src/main/java (production code).
• The string matches a real secret pattern (e.g., contains an actual API key or password) and is not a placeholder.
• A suppression comment is added without a documented justification (e.g., no comment explaining why the string is safe).

Verification Steps

1. Run Codeac on a clean checkout:

   codeac-cli analyze --project . --format json
   
   This command requires read access to the project directory and write access to the location where the JSON report will be stored (default: current directory).

2. Inspect the generated report for the warning ID associated with the hardcoded‑secret rule. Note the file path and line number.
3. To reproduce, add the placeholder string to a test class (if not already present) and re‑run the analysis; the warning should appear.
4. Apply the suppression comment or externalize the string as described above, then re‑run the analysis. Verify that the warning ID no longer appears for that line.
5. Check the rule configuration: open codeac-rules.xml and locate the HardcodedSecret rule. Record its version attribute and compare it with the version listed in the Codeac release notes to ensure you are using the intended rule set.

Limitations and Practical Checks

• The secret‑pattern regex may evolve between Codeac releases; a placeholder that is ignored in one version could trigger in another. Always verify the active rule set before applying suppressions.
• Over‑suppressing warnings can hide genuine secrets. Keep a centralized document (e.g., SECURITY_SUPPRESSIONS.md) that lists each // Codeac:ignore comment with a brief justification and the date it was added.
• If your build system aggregates multiple modules, ensure the analysis is run on a clean checkout of each module to avoid stale caches that could mask warnings.