Secrets, Dependency/Supply-Chain Signals, and Advanced Security Boundaries: Diagnostics, Failure Modes, and Production Practices

1. Evidence-first diagnostic sequence

1. Preserve source revision, scanner logs, external report bytes/checksum, report-task.txt, issue/risk screenshots or JSON, and CI artifacts.
2. Confirm SonarQube edition/version, scanner/runtime, external analyzer/SCA version, and any relevant plugin/integration version.
3. Confirm source scope, sonar.text.inclusions, manifest/lockfile availability, report path, and effective parameters.
4. Confirm scanner upload and Compute Engine task completion.
5. Classify the result as native Sonar issue, imported external issue, Advanced Security dependency risk, or external-only evidence.
6. Inspect rule/advisory ownership, issue status, gate, and any external producer state.
7. For real secrets, inspect issuer/rotation state separately; for dependency risks, inspect inventory/SBOM/package provenance separately.
8. Apply the least destructive correction and rerun the smallest equivalent scenario.

2. Failure: using real secrets in a training fixture

This is an incident, not a better test case. Stop using the credential, preserve only the minimum incident evidence allowed by policy, revoke/rotate it at the issuer, remove it from source and downstream copies, and investigate exposure. Do not paste the secret into tickets, screenshots, chat, or course evidence.

3. Failure: claiming secret detection is a vault or rotation system

SonarQube can say “a string matched a secret rule.” It cannot prove that all legitimate consumers have moved to a replacement secret, that the old key is disabled, or that the credential is absent from logs, build caches, issue trackers, artifacts, and remote history. Production closure therefore requires both static-analysis evidence and issuer/secret-manager evidence.

4. Failure: claiming Community Build is a complete SCA/SBOM replacement

Manifests visible to the scanner and imported SARIF findings are not equivalent to a dependency graph. A complete SCA claim requires evidence such as direct/transitive inventory, ecosystem/package-manager coverage, vulnerability/advisory matching, license policy where required, and release-linked SBOM output. Current Sonar-native SCA is an Advanced Security add-on starting in Enterprise edition.

5. Failure: double-counting native and imported findings

A team may run two secret scanners and import one scanner’s SARIF into SonarQube. If both detect the same location, the project can show two issues with different rule engines. That may be intentional, but it must not be mistaken for two independent vulnerabilities.

Correlate by revision, file/line, secret class, producer/rule, and message. Choose the authoritative workflow for remediation and remove redundant ingestion if it adds no independent value.

6. Failure: disabling a noisy rule before root-cause review

A noisy secret rule may indicate a real fixture convention, generated test data, or broad text scope. Preserve examples first. Determine whether the pattern is a genuine false positive, whether scope should exclude a clearly non-source artifact, or whether the rule belongs in a different profile. A global disablement can silently remove useful coverage from unrelated projects.

7. Failure: report exists on host but not where the scanner runs

# Host says the file exists:
ls -l "$PWD/reports/dependency-demo.sarif"

# But a scanner container may see /workspace instead of the host path.
# Inspect from inside the actual analysis environment before changing SonarQube:
pwd
ls -l reports/dependency-demo.sarif

# Keep the parameter relative to sonar.projectBaseDir when practical:
sonar-scanner -Dsonar.sarifReportPaths=reports/dependency-demo.sarif

Do not fix this by copying files into random server directories. The report belongs in the scanner workspace that produces the analysis.

8. Intentionally broken example: manufacture a duplicate secret signal

Assume Community Build already raises a native secret issue on config/demo.env:2. Create a second synthetic SARIF issue at the same location:

cat > reports/duplicate-secret.sarif <<'JSON'
{
  "version":"2.1.0",
  "runs":[{
    "tool":{"driver":{"name":"SyntheticSecretScanner","rules":[{"id":"DEMO-SECRET-001","defaultConfiguration":{"level":"error"}}]}},
    "results":[{
      "ruleId":"DEMO-SECRET-001",
      "message":{"text":"Synthetic duplicate signal for the same local fake-secret line."},
      "locations":[{"physicalLocation":{"artifactLocation":{"uri":"config/demo.env"},"region":{"startLine":2}}}]
    }]
  }]
}
JSON

sonar-scanner -X \
  -Dsonar.sarifReportPaths=reports/duplicate-secret.sarif \
  2>&1 | tee evidence/duplicate-import.log

Interpretation: if two issues now reference the same source location, preserve both rule engines and messages. The repair is to remove the redundant external feed (or document why both are needed), not to mass-mark one whole class false positive merely to clean the dashboard.

9. Causal failure map

10. Production shortcuts to reject

• Do not use a real credential to make secret detection easier to demonstrate.
• Do not disable TLS verification to reach SonarQube or an SCA service.
• Do not use administrator tokens for routine scans or imports.
• Do not delete logs or scanner caches before preserving first-failure evidence.
• Do not directly edit SonarQube database/search indexes to remove findings.
• Do not mass-suppress security findings or lower policy thresholds to make a gate green.
• Do not replace a project key to erase history.
• Do not present a single imported dependency advisory as a complete SBOM or SCA program.

Knowledge check

Official references and version notes

• SonarQube downloads / feature comparison — current Community Build 26.9.0.129388; basic secret detection in Community Build; broader commercial secret/security features.
• Community Build — Secrets — secret scope, text inclusions, file processing, and Community limitation on custom patterns.
• SonarQube Server — Secrets — current server secret configuration and custom secret-pattern behavior; custom patterns start in Enterprise edition.
• About external issues — imported-rule ownership and the fact that Sonar issue workflow changes do not update the external producer.
• SARIF reports — SARIF 2.1.0 requirements and sonar.sarifReportPaths.
• SonarQube Advanced Security — Enterprise-edition-and-above add-on boundary.
• Analyzing projects for dependencies (SCA) — native dependency-risk analysis prerequisites, build-environment implications, and licensing.
• Viewing dependencies / SBOM — native dependency inventory and SBOM evidence when Advanced Security is licensed.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used by the local path.