chore(security): integrate Trivy into CI for dependency, config, and image scanning

[luandro]

Summary

Integrate Trivy into this repository’s CI so we scan:

• repository dependencies in PRs and on main
• Docker/IaC misconfigurations in Dockerfile and related config
• the published API image before push/release

Why

This repo has a larger security surface than a static docs site:

• Bun/Node dependencies in the repo root
• an api-server/ service
• a published Docker image built in CI
• Docker-related config and GitHub Actions workflows

Current CI runs tests and builds/publishes the Docker image, but it does not appear to perform Trivy-style vulnerability/config scanning in CI today.

There is already secret scanning via Gitleaks, so Trivy should complement that rather than replace it.

Current State

Relevant files/workflows:

• package.json
• .github/workflows/test.yml
• .github/workflows/docker-publish.yml
• Dockerfile
• SECURITY.md

Notable gaps:

• no dependency vulnerability scan in the main test workflow
• no image vulnerability scan before Docker push
• no config/misconfiguration scan for Docker-related files
• SECURITY.md says Dependabot is enabled, but there does not appear to be a .github/dependabot.yml in the repo

Proposed Scope

1. Add Trivy filesystem/repo scanning to CI

Run Trivy in fs mode on pull requests and on main to catch dependency vulnerabilities from lockfiles such as bun.lock and package-lock.json.

Suggested initial policy:

• severity: HIGH,CRITICAL
• fail CI on confirmed findings above threshold
• consider ignore-unfixed: true initially to reduce noise
• optionally upload SARIF to the GitHub Security tab

2. Add Trivy config scanning

Run Trivy in config mode against:

• Dockerfile
• docker-compose.yml / docker-compose.yaml
• any other relevant infra/config files in scope

Suggested initial policy:

• severity: HIGH,CRITICAL
• fail on actionable misconfigurations
• keep the scope narrow to Docker/IaC-related files first

3. Add Trivy image scanning in Docker publish workflow

In .github/workflows/docker-publish.yml, scan the built image before pushing/publishing.

Suggested initial policy:

• scan the image built from the repo Dockerfile
• severity: HIGH,CRITICAL
• fail before push on blocking findings
• optionally emit SARIF or upload report artifacts

Non-Goals / Initial Exclusions

• Do not replace Gitleaks with Trivy secret scanning. Gitleaks remains the primary secret scanner.
• Do not start with full license scanning unless we have an explicit compliance requirement.
• Do not broaden the initial rollout to every workflow; start with PR/main CI and Docker publish.

Deliverables

• a new or updated workflow for Trivy fs/config scanning
• Docker publish workflow updated to run Trivy image scan before push
• any required Trivy config file committed to the repo
• documentation updates in SECURITY.md describing what is enforced in CI
• optional: SARIF upload to GitHub code scanning if we want findings in the Security tab

Acceptance Criteria

• PRs run Trivy against the repo filesystem and fail on configured high-severity findings
• Docker-related config is scanned for high-severity misconfigurations
• the Docker publish workflow scans the built image before push
• Trivy configuration is checked into the repo and tuned to avoid noisy false positives
• SECURITY.md reflects the actual enforced controls

Suggested Follow-up

Create a separate issue for Dependabot if we want to align SECURITY.md with actual repo configuration.

References

• https://trivy.dev/docs/latest/guide/target/repository/
• https://trivy.dev/docs/latest/scanner/misconfiguration/
• https://trivy.dev/docs/latest/guide/target/container_image/
• https://github.com/aquasecurity/trivy-action