Reporting a vulnerability
- Go to the repository’s Security tab → Report a vulnerability (GitHub private vulnerability reporting).
- Describe the issue, the affected component, and reproduction steps.
Automated controls
These run in CI on every PR tomain, plus a weekly schedule.
¹ Dependency audits are non-blocking (
continue-on-error: true) so the existing advisory backlog can be triaged without wedging PRs. Flip those steps to blocking once the backlog is clean see the comment at the top of security-scan.yml.
Required GitHub settings
These controls live in repo settings, not in code, and must be enabled by an admin (Settings → Code security).- Secret scanning on (catches secrets server-side, including in history).
- Push protection on (blocks secrets before they’re committed; gitleaks CI is the backstop, not the first line).
- Dependabot alerts + Dependabot security updates on.
- Private vulnerability reporting on (enables the disclosure flow above).
-
CodeQL: switch “Default setup” → “Advanced” required, otherwise the committed
codeql.ymlconflicts with default setup and errors. -
Branch protection on
mainrequire these status checks before merge:
Scope
In scope: this repository’s code, CI/CD, and published artefacts (the app bundle, the GCS CDN data and models). Out of scope: the upstream FastF1 / Jolpica data sources, and the analytics/model correctness that is covered by the dbt identity oracle and ML leakage guards, not by this policy.Performance & E2E
App E2E and App Performance status checks that branch protection requires.
Deployment
Workload Identity Federation setup that keeps GCP credentials out of CI.