feat: SAST — continuous dashboard and trend analysis (runtime/ops)

[ms280690]

Context

Stage: Runtime / Ops
Tool: sonarqube (same instance as #20)
Scope: Continuous analysis across all application repositories
Parent: (see SAST parent issue)

What this context means

The Runtime/Ops context for SAST is not a GitHub Actions workflow — it is the always-on SonarQube server instance deployed in #20, continuously aggregating scan results from every repo's deployment branch runs.

This issue tracks the operational configuration and GitHub Actions scheduling work needed to make SonarQube useful as an ongoing security posture dashboard rather than just a per-PR gate.

Scheduled deep scan — sast-scheduled.yml

codeql (#19) runs on PRs. SonarQube (#20) runs on deployment branch merges. Neither runs a full scheduled scan that catches new CVEs against existing code.

Add a scheduled workflow that re-scans the main branch weekly. This catches security findings introduced by upstream dependency updates, new CVE disclosures, and updated rule sets without requiring a new commit.

name: SAST Scheduled
on:
  workflow_call:
    inputs:
      project-key:
        required: true
        type: string
    secrets:
      SONAR_TOKEN:
        required: true
      SONAR_HOST_URL:
        required: true

Consuming repo usage

# .github/workflows/sast-scheduled.yml
name: SAST Scheduled
on:
  schedule:
    - cron: '0 2 * * 1'    # Weekly Monday 02:00 UTC
  workflow_dispatch:
jobs:
  sonarqube:
    uses: sparkgeo/github-actions/.github/workflows/sast-scheduled.yml@main
    with:
      project-key: prescient-platform-api
    secrets:
      SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
      SONAR_HOST_URL: ${{ vars.SONAR_HOST_URL }}

SonarQube operational configuration

These are one-time setup tasks in the SonarQube admin UI, not GitHub Actions workflows. Document here for the team deploying #20:

Portfolio view (requires Developer Edition — optional)

If upgraded from Community, SonarQube Portfolio aggregates security ratings across all Sparkgeo projects into a single view. At Community Edition, use the Projects dashboard as the org-level view.

Alerting on quality gate failures

Configure SonarQube webhooks to post quality gate results back to GitHub (status checks) and to Slack/email:

Administration → Configuration → Webhooks
URL: https://api.github.com/repos/{org}/{repo}/statuses/{commit_sha}
Secret: ${{ secrets.SONAR_WEBHOOK_SECRET }}

Metrics to track (§3 Success Metrics alignment)

SonarQube metric	Target	Review cadence
Security Rating (all projects)	A	Weekly
New security hotspots unreviewed	0	Per deployment
Open vulnerabilities (Critical/High)	0	Weekly
Technical debt ratio	< 5%	Monthly
Coverage (new code)	≥ 80%	Per PR

Wazuh integration (cross-ref Step 9)

SonarQube webhook failures (quality gate RED) can be forwarded to Wazuh via a custom webhook processor. This means a production deployment that bypasses the quality gate generates a SIEM alert — aligning with the §5.5 deployment gate behaviour.

Relationship to the full SAST stack

Developer commit
     │
     ▼
semgrep pre-commit hook (#18) ──── fast pattern scan, instant feedback
     │
     ▼ (PR opened)
codeql deep scan (#19) ──────────── taint/data-flow analysis, SARIF to Security tab
     │
     ▼ (merge to main)
sonarqube gate (#20) ────────────── quality gate pass/fail, PR decoration
     │
     ▼ (continuous)
sonarqube dashboard (#21) ──────── trend analysis, weekly re-scan, SIEM alerting