Security Hotspots, Vulnerabilities, Taint Analysis, and Review Workflow: Guided Hands-On Workflow

1. Disposable workflow contract

2. Preflight: prove versions, project identity, and available security rules

export SONAR_HOST_URL="http://localhost:9000"
export SONAR_PROJECT_KEY="sq-ch15-security-lab"

git --version
python --version
sonar-scanner --version
curl -fsS "$SONAR_HOST_URL/api/system/status"

# In the UI, create the disposable project first, then create a project-analysis token.
# Export the token only in the current shell:
read -rsp "Disposable Sonar token: " SONAR_TOKEN; echo
export SONAR_TOKEN

# Record current security-capable Python rules before writing the fixture.
curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/rules/search?languages=py&ps=100" \
  > rules-python.json

Open Rules in the UI and filter the Python profile by Security impact/type. Pick one rule whose noncompliant example can be reproduced using inert local code. Separately identify a rule described as security-sensitive/hotspot-style or a rule carrying migration metadata such as former-hotspot, if your 26.9 instance exposes one.

3. Create a tiny synthetic repository

The fixture below is intentionally insecure-looking but has no listener, no database, no external network call, and no real secret. Analyzer rule availability changes, so treat these as candidate patterns; if your active rule set does not flag one, use the noncompliant example from the exact active rule you recorded in preflight.

mkdir -p sq-ch15-security-lab/src
cd sq-ch15-security-lab
git init
git config user.email "learner@example.invalid"
git config user.name "SonarQube Learner"

cat > sonar-project.properties <<'EOF'
sonar.projectKey=sq-ch15-security-lab
sonar.projectName=SQ Chapter 15 Security Lab
sonar.sources=src
sonar.sourceEncoding=UTF-8
EOF

cat > src/security_demo.py <<'PY'
import hashlib

DEMO_PASSWORD = "not-a-real-secret"

def legacy_digest(value: str) -> str:
    # Candidate security rule: weak/risky cryptographic algorithm.
    return hashlib.md5(value.encode("utf-8")).hexdigest()

def cookie_header(session_id: str) -> str:
    # Candidate hotspot-style concern: security-sensitive cookie configuration.
    return f"Set-Cookie: session={session_id}"
PY

cat > .gitignore <<'EOF'
.scannerwork/
evidence/
EOF

git add .
git commit -m "baseline insecure local fixture"
git rev-parse HEAD | tee baseline-revision.txt

4. Baseline analysis: preserve the first evidence chain

mkdir -p evidence/baseline
sonar-scanner -X 2>&1 | tee evidence/baseline/scanner.log
cp .scannerwork/report-task.txt evidence/baseline/report-task.txt

CE_TASK_ID="$(sed -n 's/^ceTaskId=//p' .scannerwork/report-task.txt)"
echo "$CE_TASK_ID" | tee evidence/baseline/ce-task-id.txt

curl -fsS -H "Authorization: Bearer $SONAR_TOKEN" \
  "$SONAR_HOST_URL/api/ce/task?id=$CE_TASK_ID" \
  | tee evidence/baseline/ce-task.json

Wait until the Compute Engine task is terminal before interpreting findings. Then record the project Issues view, security-related rule key(s), exact file/line, current issue/hotspot representation, security measures, and Quality Gate. Do not change any status yet.

5. Classify by current object, not by course vocabulary

6. Fix one vulnerability/security issue in source

Suppose the weak-digest candidate is actually raised by your current profile. Replace it with a stronger algorithm only for the teaching fixture. The important evidence is not the specific hash choice; it is that the exact finding disappears because the source revision changed while the profile and scope remain constant.

python - <<'PY'
from pathlib import Path
p = Path("src/security_demo.py")
text = p.read_text()
text = text.replace("hashlib.md5(value.encode(\"utf-8\")).hexdigest()",
                    "hashlib.sha256(value.encode(\"utf-8\")).hexdigest()")
p.write_text(text)
PY

git add src/security_demo.py
git commit -m "remediate security finding"
git rev-parse HEAD | tee evidence/fixed-revision.txt

mkdir -p evidence/fixed
sonar-scanner -X 2>&1 | tee evidence/fixed/scanner.log
cp .scannerwork/report-task.txt evidence/fixed/report-task.txt

Follow the new ceTaskId to completion and compare the same rule/finding. If the issue persists, preserve that fact. Do not suppress or deactivate the rule to manufacture a “fix.”

7. Review one hotspot-style pattern without gaming the result

If the instance still exposes a classic Security Hotspot for the cookie-style pattern, open it, read the rule’s risk description, identify whether the local fixture has compensating controls, and record a fake teaching-only review. Because this fixture is intentionally incomplete, the most defensible result may be Fix rather than Safe.

If the rule has already migrated to a normal issue, do not search for a nonexistent Hotspots tab. Create an evidence note instead:

finding: <issue key>
rule: <rule key>
representation: migrated security issue / former-hotspot (if exposed)
revision: <git sha>
review question: what security-sensitive behavior does the rule highlight?
context: synthetic local fixture; no production traffic or secrets
decision: fix / accepted temporarily / other current workflow state
rationale: ...
reviewer: learner@example.invalid
revisit trigger: rule/profile/product migration or code-context change

8. Optional commercial path: observe a taint flow, do not emulate licensing

If you have an authorized Developer/Enterprise/Data Center test instance with a currently supported taint-analysis language, use a tiny source-to-sink fixture and capture the flow locations. Otherwise, keep the mandatory local path: draw the expected source → propagation → sink chain manually and compare it with the product description of advanced injection-vulnerability detection.

9. Challenge: choose the correct layer

After a source fix, Scanner CLI exits 0, but the security issue still appears. Which evidence do you inspect first?

1. Confirm the Git SHA that was scanned.
2. Confirm the file was indexed and the same rule/profile remained active.
3. Inspect report-task.txt and Compute Engine task success.
4. Confirm the displayed issue belongs to the new analysis/revision.
5. Only then decide whether the remediation is technically incomplete.

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.