Description: .github/workflows/ci.yml's secrets-scan job (Gitleaks) only catches committed secrets, and vulnerability-scan only catches known-vulnerable dependency versions — neither performs static application security testing (SAST) against the project's own TypeScript/NestJS source for common vulnerability patterns (injection, unsafe deserialization, insecure randomness, etc.). Add a SAST job (e.g. GitHub CodeQL, configured for JavaScript/TypeScript) to the CI pipeline.
Problem Statement & Context: This backlog's Security & Auditing category (issues #18–#26, #82–#97) demonstrates the codebase already has a track record of exactly the kind of logic-level vulnerability class SAST tooling is designed to catch early (auth gaps, injection-adjacent patterns, unsafe input handling) — currently, every one of those was found by manual/human audit rather than tooling, meaning the next one of the same class won't be caught automatically either.
Scope & Acceptance Criteria:
- Add a CodeQL (or equivalent) SAST workflow scanning the TypeScript source under
src/ on every PR and on a schedule for main.
- Triage the initial findings from the first full scan: fix genuine issues or explicitly document/suppress verified false positives with rationale — do not merge with unreviewed open findings.
- Out of scope: fixing every historical code-quality nit the scanner surfaces — prioritize security-relevant findings; track lower-priority ones as follow-up issues rather than blocking this PR indefinitely.
Implementation Guidelines:
- Key files:
.github/workflows/ci.yml (add as a new, separate workflow file, following the existing job-isolation pattern of secrets-scan/vulnerability-scan), src/ (scan target).
- Use GitHub's built-in CodeQL default setup where possible to minimize maintenance burden, falling back to an explicit configuration only if the default query suite proves too noisy or misses relevant coverage.
- Configure severity thresholds so the job fails the PR only on high/critical findings (mirroring the
--audit-level=high pattern already used by vulnerability-scan), with lower-severity findings surfaced as non-blocking annotations.
- Testing/validation: run the scan against current
main, document the full triage of findings (fixed / suppressed-with-rationale / follow-up-filed) in the PR — an empty, unexplained "0 findings" claim without evidence of an actual full-codebase run is not acceptable.
Definition of Done:
- CodeQL (or equivalent) SAST workflow added and running on PRs/schedule.
- Initial findings triaged with documented rationale.
- PR passes CI, includes scan output/triage summary.
- Reviewed and approved.
Resources: .github/workflows/ci.yml, src/
Complexity: High (200 points)
Description:
.github/workflows/ci.yml'ssecrets-scanjob (Gitleaks) only catches committed secrets, andvulnerability-scanonly catches known-vulnerable dependency versions — neither performs static application security testing (SAST) against the project's own TypeScript/NestJS source for common vulnerability patterns (injection, unsafe deserialization, insecure randomness, etc.). Add a SAST job (e.g. GitHub CodeQL, configured for JavaScript/TypeScript) to the CI pipeline.Problem Statement & Context: This backlog's Security & Auditing category (issues #18–#26, #82–#97) demonstrates the codebase already has a track record of exactly the kind of logic-level vulnerability class SAST tooling is designed to catch early (auth gaps, injection-adjacent patterns, unsafe input handling) — currently, every one of those was found by manual/human audit rather than tooling, meaning the next one of the same class won't be caught automatically either.
Scope & Acceptance Criteria:
src/on every PR and on a schedule formain.Implementation Guidelines:
.github/workflows/ci.yml(add as a new, separate workflow file, following the existing job-isolation pattern ofsecrets-scan/vulnerability-scan),src/(scan target).--audit-level=highpattern already used byvulnerability-scan), with lower-severity findings surfaced as non-blocking annotations.main, document the full triage of findings (fixed / suppressed-with-rationale / follow-up-filed) in the PR — an empty, unexplained "0 findings" claim without evidence of an actual full-codebase run is not acceptable.Definition of Done:
Resources:
.github/workflows/ci.yml,src/Complexity: High (200 points)