feat(ci): add Trivy security scanning

[nathan-weinberg]

What does this PR do?

Add Trivy vulnerability scanning across the CI pipeline to complement existing CodeQL SAST coverage. All scans start as informational (SARIF upload to GitHub Security tab, no PR blocking) so existing findings can be triaged before tightening thresholds.

New workflows:

• trivy-security.yml: PR/push scanning with path filters for dependency vulnerabilities, IaC misconfigurations, and secret detection
• trivy-scheduled.yml: weekly full repo and published container image scans

Modified workflows:

• build-distributions.yml: scan built images after config label verification
• pypi.yml: post-push scan of published Docker images

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[nathan-weinberg]

More info around Trivy: https://trivy.dev/

[leseb]

how is this different/better (complementary?) to the code scanning with have from gh already?

[nathan-weinberg]

Good question — they're complementary, covering different threat categories with minimal overlap.

CodeQL (what we have today) is a SAST tool — it analyzes our Python and GitHub Actions source code for bugs like SQL injection, command injection, path traversal, etc. It's great at finding vulnerabilities in code we write.

Trivy covers three categories CodeQL doesn't touch:

Category	What it catches	Example
Dependency vulnerabilities	Known CVEs in our Python/npm dependencies (from uv.lock, package-lock.json)	A critical RCE in a transitive dependency we pull in
IaC misconfigurations	Insecure settings in Containerfiles, K8s manifests, EKS configs	Running containers as root, missing security contexts, overly broad permissions
Secret detection	Hardcoded API keys, tokens, passwords checked into source	An accidentally committed OPENAI_API_KEY
Container image scanning (scheduled)	OS-level CVEs in our published Docker images	Vulnerable system packages in the base image

In short: CodeQL finds bugs in our code, Trivy finds known vulnerabilities in our dependencies, configs, and container images. No overlap — they scan different artifacts for different classes of issues. Both feed into the same GitHub Security tab via SARIF, so the triage experience is unified.

[skamenan7]

Nice PR. Thanks. Just couple of nits.

[skamenan7]

nit: vuln scan steps reference trivy-config: 'trivy.yaml' but misconfig/secret scans don't. functionally fine today, but if trivy.yaml grows, those scanners would miss it. worth adding for consistency?

[skamenan7]

the build-distributions scan uses format: 'table' so results only show in CI logs , the pypi.yml scan covers the same images with SARIF upload. was the table format intentional here? not blocking.

[skamenan7]

future-proofing: no merge_group trigger, if Trivy ever becomes required, it won't run in merge queue. might be worth adding now while it's informational. not blocking.