Secrets, Dependency/Supply-Chain Signals, and Advanced Security Boundaries: Core Concepts and Mental Model

1. The practical problem: security signals cross ownership boundaries

Chapter 15 separated vulnerabilities, hotspot-style review, and taint-analysis capability. Chapter 16 adds a different boundary: some security facts are discovered in source, some are created by dependency tools, and some live outside SonarQube entirely.

A hard-coded credential can be detected by SonarQube, but detection does not revoke or rotate that credential. A dependency risk can be imported as an external issue, but importing one result does not create a complete dependency inventory or Software Bill of Materials. SonarQube Advanced Security can provide native SCA and SBOM capabilities in supported commercial deployments, but Community Build does not become an SCA engine merely because it can display a SARIF finding.

2. Mental model: detection, inventory, remediation, and credential control are different jobs

flowchart TD
  A[Source + config + manifests] --> B[Community secret rules]
  A --> C[External SCA / secret tool]
  A --> D[Optional SonarQube Advanced Security SCA]
  B --> E[Native Sonar issue]
  C --> F[SARIF / generic external report]
  F --> G[External Sonar issue]
  D --> H[Native dependency inventory / risks / SBOM]
  E --> I[Code/config remediation]
  G --> J[Producer-owned remediation]
  H --> K[Dependency upgrade / license / supply-chain action]
  I --> L[Credential manager: rotate/revoke if real]

The arrows show causality and ownership. SonarQube can be the place where evidence is analyzed and governed, but the system that owns a credential, package version, artifact repository, or SBOM release record may be different.

3. State ledger before changing anything

4. Community Build secret detection: useful, bounded source evidence

Current Community Build includes basic secret detection. The secrets analyzer examines files processed by language analyzers and can also scan language-agnostic text files brought into scope through sonar.text.inclusions. Current default text-inclusion patterns include common shell/config/key file shapes such as *.sh, *.ps1, *.properties, *.conf, *.pem, .env, and *.key.

This is a source-analysis control. It does not know whether a detected credential is currently valid, whether it has already been revoked, whether the same credential leaked through logs or tickets, or whether rotation completed in the provider. If a real credential is exposed, remediation normally requires both source cleanup and credential revocation/rotation in the owning system.

5. Basic, enhanced, and custom secret rules

6. Dependency and supply-chain analysis: do not infer SCA from manifest visibility

A repository may contain requirements.txt, pom.xml, package-lock.json, or another manifest. Seeing that file in source analysis does not automatically mean the current edition has built a complete dependency graph.

Current SonarQube Advanced Security provides Software Composition Analysis as a SonarQube Server add-on starting in Enterprise edition. When licensed and enabled, it can analyze dependencies, surface dependency risks, and expose dependency inventory/SBOM capabilities. That is a different product state from Community Build.

7. External issue import is aggregation, not ownership transfer

Community Build can import third-party findings through built-in analyzer integrations, Sonar generic issue format, or SARIF 2.1.0. SARIF is configured on the scanner side with sonar.sarifReportPaths.

The imported issue participates in the SonarQube analysis result, but its external rule is not managed on SonarQube’s Rules page and is not part of a Sonar quality profile. If you mark an imported issue false positive inside SonarQube, that change does not update the external producer. This is why the evidence packet must identify both systems.

8. Ownership matrix

9. Read-only inspection first

git rev-parse HEAD
sonar-scanner --version
curl -fsS "$SONAR_HOST_URL/api/system/status"

# Inspect current secrets configuration in the UI:
# Administration / Project Settings → General Settings → Languages → Secrets
# Record sonar.text.inclusions and whether secret analysis is active.

# Preserve scanner-created task identity after an analysis:
cat .scannerwork/report-task.txt

# Read-only issue evidence:
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/issues/search?componentKeys=$SONAR_PROJECT_KEY&ps=100"

Do not begin by deactivating a noisy secret rule or by importing another tool’s result. First prove the current native rule scope, current edition features, current project findings, and whether a dependency/SBOM view is actually licensed and populated.

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.