Checkpoint Lab — Security Hotspots, Vulnerabilities, Taint Analysis, and Review Workflow

1. Checkpoint scenario

You are the owner of a disposable Python project called sq-ch15-security-lab. The initial revision contains two intentionally security-sensitive patterns. Your task is to:

1. analyze the baseline;
2. identify one actual vulnerability/security issue from the current active rule set;
3. identify one hotspot-style finding or its current migrated representation;
4. fix the vulnerability in source and prove the new analysis state;
5. perform/document the contextual review;
6. state clearly what Community Build did not prove, including advanced taint boundaries;
7. revoke credentials and remove only the lab resources.

2. Exact assumptions and preflight

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

3. Predictions before action

Write predictions before the baseline and before the fix. At minimum:

• Prediction A: the first analysis will index the intended local source file and create a terminal Compute Engine task.
• Prediction B: fixing the selected security rule in source while keeping profile/scope constant will remove or change that exact finding in the next analysis.
• Prediction C: the hotspot-style object may be a classic hotspot or a migrated ordinary security issue on the current 26.9 release; the review packet must work in either case.
• Prediction D: no result will justify the statement “the application is secure.”

4. Execute baseline → fix → review → reanalysis

mkdir -p evidence/baseline evidence/fixed

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

# Preserve current issue representation after CE completion:
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/issues/search?componentKeys=$SONAR_PROJECT_KEY&ps=100" \
  > evidence/baseline/issues.json

# If still supported/populated on your release, preserve classic hotspots too:
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/hotspots/search?projectKey=$SONAR_PROJECT_KEY&ps=100" \
  > evidence/baseline/hotspots.json || true

# FIX one actual security issue selected from the baseline.
# Make the smallest source change recommended by the exact rule.
git add src
git commit -m "chapter15 remediate selected security issue"

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

Use the UI/API only after each task completes. Record the exact rule/finding chosen, the source diff, and whether the hotspot-style finding is still represented as a classic hotspot or has migrated into the issue model.

5. Hotspot-style review record

review_id: ch15-hotspot-style-001
finding_key:
rule_key:
representation: classic-hotspot | migrated-security-issue
revision:
security-sensitive behavior:
threat considered:
surrounding controls:
decision:
why this is not merely metric cleanup:
reviewer:
review_date:
revisit_trigger:
post-analysis evidence:

If the current object supports a classic hotspot review action, perform it only with the minimum required project permission. If the object has migrated, retain the review record as governance evidence and use the current issue workflow; do not force an obsolete endpoint.

6. Verification checklist

• ☐ Exact baseline and fixed Git SHAs are recorded.
• ☐ Scanner version/runtime and server version/mode are recorded.
• ☐ Both report-task.txt files and Compute Engine task IDs/statuses are preserved.
• ☐ The selected vulnerability/security issue is tied to an exact rule and source location.
• ☐ The source remediation is visible in Git and the post-analysis state is verified independently.
• ☐ The hotspot-style finding’s current representation is recorded instead of assumed.
• ☐ Review rationale contains threat/context evidence, not merely “mark safe.”
• ☐ Security rating/gate are recorded as outcomes, not proof of total security.
• ☐ Advanced taint analysis is labeled optional/commercial and not claimed as Community Build coverage.
• ☐ No real secrets or proprietary source were used.

7. Required evidence packet

8. Residual-risk statement

This checkpoint proves that the specified SonarQube release analyzed the recorded source revisions under the recorded profile/scope; that one selected security finding was remediated or changed as shown by the later analysis; and that one hotspot-style concern received a documented review. It does not prove the application has no exploitable vulnerabilities, does not substitute for runtime or dependency security controls, and does not claim commercial taint-analysis coverage on Community Build.

9. Guarded cleanup and rollback

• Revoke the disposable project-analysis token in SonarQube and prove it can no longer authenticate.
• Delete the disposable project only after exporting the evidence packet, and only if you created it for this lab.
• Remove the local fixture directory only after verifying the evidence packet is stored where intended.
• Do not prune unrelated Docker volumes, delete shared databases, or alter global profiles/gates.
• If you changed a classic hotspot/issue workflow state only for the experiment, preserve the Activity/history evidence before reverting if the current UI permits.

10. What this adds to a governed production model

Chapter 15 adds a security-specific control plane to the operating model: security findings are classified by meaning and analyzer capability; source fixes are distinguished from review metadata; edition/language limits are explicit; product-taxonomy migrations are recorded; and every decision is tied back to revision and asynchronous analysis evidence.

Chapter 16 continues from here into Secrets, Dependency/Supply-Chain Signals, and Advanced Security Boundaries, broadening the model beyond first-party source findings.

Knowledge check

Official references and version notes

• SonarQube downloads and edition matrix — Community Build 26.9.0.129388; Server 2026 Release 4.1; current LTA; Community Build basic vulnerabilities/hotspot review; Developer+ injection/taint analysis for selected languages.
• Managing Security Hotspots — conceptual difference between security issues/vulnerabilities and review-oriented security-sensitive findings.
• Security-related rules — security-rule categories and standards mapping.
• Moving Security Hotspots to Security Issues — 2026 migration plan, gate/metric implications, API deprecation, and status/history migration context.
• Current hotspot API source/changelog — api/hotspots/search is deprecated since 2026.4 in favor of security issues/vulnerabilities.
• Managing issues — current issue lifecycle, assignment, acceptance/false-positive semantics.
• Web API — bearer authentication and current API guidance.
• SonarScanner CLI 8.1.0.6389 — scanner baseline used in the mandatory local workflow.