Secrets, Dependency/Supply-Chain Signals, and Advanced Security Boundaries: Configuration, Design Patterns, and Trade-Offs

1. Design principle: one dashboard does not mean one source of truth

SonarQube can consolidate first-party code findings and external issues, but a consolidated view does not erase provenance. Every security signal needs an explicit producer, owning policy, remediation system, and verification system. Otherwise teams eventually mark an issue fixed in one interface while the source tool, credential provider, or package inventory still says otherwise.

2. Basic versus expanded versus custom secret detection

3. Sonar-native SCA versus external SCA/SBOM

Current SonarQube Advanced Security SCA is a Server add-on starting in Enterprise edition. It can provide native dependency inventory/risk workflows and SBOM-related capabilities. An external SCA tool may provide equivalent or different capabilities and can export issues into SonarQube. Neither choice is automatically “better”; the deciding factors are evidence requirements.

4. Source finding versus credential lifecycle

flowchart TD
  A[Secret finding] --> B[Preserve location/revision]
  B --> C[Revoke / rotate at issuer]
  C --> D[Update legitimate consumers]
  D --> E[Remove secret from source/history as appropriate]
  E --> F[Reanalyze]
  F --> G[Incident/audit closure]

Static-analysis “Fixed” is only one link in this chain. A production runbook should prioritize revocation/rotation when the secret was real and exposed, because removing the string from the next commit does not invalidate a credential already copied elsewhere.

5. Native versus imported finding semantics

Imported external issues can be managed in SonarQube, including status/assignment actions, but those actions do not modify the external tool. This creates an important design choice:

• Single-owner workflow: triage in the external tool and use SonarQube primarily for visibility/gating.
• Dual-view workflow: allow Sonar annotations, but define which system is authoritative and how reconciliation happens.
• Do not pretend synchronization: “False positive in SonarQube” is not automatically “False positive in Bandit/SCA/vendor system.”

6. False-positive handling by provenance

7. Local versus CI/container report paths

sonar.sarifReportPaths is evaluated where the scanner runs. A path valid on the host is useless inside a scanner container unless the report is mounted at the path visible inside that container. The same principle applies to manifests and lockfiles used by SCA engines: evidence must exist inside the analysis workspace that owns the scan.

8. Worked decision table

9. Governance record template

signal_id:
producer: sonar-native | external-sarif | advanced-security-sca | secret-manager
producer_version:
server_edition_version:
source_revision:
manifest_or_file:
rule_or_advisory_id:
classification:
authoritative_system:
remediation_owner:
credential_rotation_required: yes | no | not-applicable
sbom_or_inventory_artifact:
exception_status_and_expiry:
post-remediation_evidence:
limitations:

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.