Checkpoint Lab — Secrets, Dependency/Supply-Chain Signals, and Advanced Security Boundaries

1. Checkpoint scenario

Operate the disposable project sq-ch16-security-boundary as a small layered-security exercise. The repository contains only synthetic data. Your deliverable is not “a green dashboard”; it is an evidence packet that answers:

1. Which fake credential patterns were natively detected by the current Community Build rules?
2. Which dependency signal came from the synthetic external SARIF producer?
3. Which system owns source cleanup, real-secret rotation, dependency inventory, dependency remediation, and SBOM evidence?
4. Which features would require Enterprise/custom-secret or Advanced Security capability?
5. What risks remain outside this static-analysis checkpoint?

2. Exact assumptions and preflight

export SONAR_HOST_URL="http://localhost:9000"
export SONAR_PROJECT_KEY="sq-ch16-security-boundary"
git rev-parse HEAD
sonar-scanner --version
curl -fsS "$SONAR_HOST_URL/api/system/status"

3. Predictions before execution

Write at least these predictions in evidence/predictions.md before scanning:

• P1: the configured fake-secret file will be processed by the intended secret/text scope; whether a rule matches depends on the active current rule inventory.
• P2: adding a valid SARIF report at the same Git SHA will add an external issue without creating native Community Build dependency inventory or SBOM state.
• P3: removing the fake hard-coded credential pattern will change native secret evidence only after a new source revision and completed Compute Engine task.
• P4: the disposable Sonar analysis token can be revoked independently of all source/dependency findings.

4. Execute the layered two-signal experiment

mkdir -p evidence/native evidence/imported evidence/remediated

# RUN A — native analysis only
git rev-parse HEAD | tee evidence/native/revision.txt
sonar-scanner -X 2>&1 | tee evidence/native/scanner.log
cp .scannerwork/report-task.txt evidence/native/report-task.txt
TASK_A="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$TASK_A" \
  | tee evidence/native/ce-task.json

# Validate/generate the synthetic dependency SARIF described in Lesson 2.
python -m json.tool reports/dependency-demo.sarif > /dev/null
sha256sum reports/dependency-demo.sarif | tee evidence/dependency-sarif.sha256

# RUN B — same source revision + external report
git rev-parse HEAD | tee evidence/imported/revision.txt
sonar-scanner -X \
  -Dsonar.sarifReportPaths=reports/dependency-demo.sarif \
  2>&1 | tee evidence/imported/scanner.log
cp .scannerwork/report-task.txt evidence/imported/report-task.txt
TASK_B="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$TASK_B" \
  | tee evidence/imported/ce-task.json

curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/issues/search?componentKeys=$SONAR_PROJECT_KEY&ps=100" \
  | tee evidence/imported/issues.json

Wait for each task to finish before interpreting issues. Preserve the external producer name/rule and a native secret rule separately.

5. Remediate source without pretending to rotate a real credential

Replace fake hard-coded values with environment references, commit the change, and run the scanner again with the same SARIF feed. The dependency issue should remain because its producer evidence did not change; a native secret finding may change because the source revision did.

cat > config/demo.env <<'ENV'
AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
ENV

git add config/demo.env
git commit -m "chapter16 use runtime secret injection contract"
git rev-parse HEAD | tee evidence/remediated/revision.txt

sonar-scanner -X \
  -Dsonar.sarifReportPaths=reports/dependency-demo.sarif \
  2>&1 | tee evidence/remediated/scanner.log
cp .scannerwork/report-task.txt evidence/remediated/report-task.txt

6. Independent verification checklist

• ☐ Server/edition, scanner/runtime, Git SHAs, and effective report parameters are recorded.
• ☐ Native secret/text scope is proven from settings/logs; no real secret was used.
• ☐ Run A and Run B use the same source revision.
• ☐ The SARIF report is valid UTF-8 JSON/SARIF 2.1.0 and its SHA-256 is retained.
• ☐ Imported issue provenance names the external producer and external rule.
• ☐ No claim is made that the imported issue created native SCA, a transitive dependency graph, or an SBOM.
• ☐ Source remediation is tied to a new revision and a later Compute Engine task.
• ☐ The dependency signal remains tied to its unchanged external producer report unless that report changes.
• ☐ Real-secret response is documented as rotate/revoke + source cleanup, even though this lab used fake values.
• ☐ Commercial custom-secret/Advanced Security capabilities are explicitly labeled optional.

7. Required evidence packet

8. Layered boundary statement

This checkpoint proves that the recorded Community Build release analyzed the recorded source revisions under the recorded secret/text scope; that the exact SARIF file was imported as external issue evidence; and that source remediation and external dependency evidence remained independently attributable. It does not prove credential rotation, full repository/history secret coverage, complete dependency inventory, CVE completeness, license compliance, malicious-package detection, or SBOM completeness. Those controls require their owning systems or the specifically licensed SonarQube Advanced Security capabilities.

9. Guarded cleanup

• Revoke the disposable project-analysis token and verify an authenticated read/scan with that token fails.
• Delete the disposable SonarQube project only after exporting the checkpoint evidence and only if you created it solely for this lab.
• Delete only the local sq-ch16-security-boundary fixture after confirming the evidence location.
• Do not prune unrelated containers/volumes, delete shared databases, edit global secret rules/profiles, or remove external security records.

10. What Chapter 16 adds—and where Chapter 17 goes next

Chapter 16 completes the first security-boundary layer: every secret/dependency signal has an explicit producer, edition, source revision, remediation owner, credential/SBOM boundary, and verification record. The platform can now distinguish native Sonar findings from imported evidence and from controls that remain outside SonarQube.

Chapter 17 moves this governed analysis model into Branches, Pull Requests, Merge Requests, and Edition-Aware Analysis, where branch identity, provider metadata, edition capabilities, and merge-policy evidence become part of the analysis contract.

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.