relay: periodic security-scan cron workflow (re-runs Trivy + govulncheck against main)

[ilmoniemi]

User Story

As a relay maintainer, I want a scheduled workflow that re-runs both the runtime-image CVE scan and the source-side reachable-Go-vuln scan against the latest main SHA, so that newly-disclosed CVEs against dependencies that have not changed since the last PR produce a visible workflow-run signal instead of being invisible until someone next bumps that dep.

Context

PR-time scanning only catches CVEs that exist at PR time. New CVEs are disclosed continuously against dependencies the relay has not touched in weeks. Without a periodic re-scan against main, a vuln disclosed today against a long-stable dep stays invisible.

This ticket adds the cron workflow itself that re-runs:

1. The runtime-image Trivy CVE scan from ci.yml's image-scan job (relay: PR-time Trivy image CVE scan in ci.yml — fail on fixable CRITICAL/HIGH #68).
2. The reachable-Go-vuln govulncheck scan from ci.yml's security job (relay: govulncheck in CI — flag reachable Go vulns at PR time #41).

At this stage a finding produces a red workflow run only — no auto-issue is filed. Auto-issue filing is layered on top in #73 so the cron workflow has a single concern: schedule and execute both scans against main.

Split from #69.

Acceptance Criteria

• A new workflow file .github/workflows/security-scan.yml is added that runs on a schedule (daily or weekly — architect chooses) and on workflow_dispatch for manual re-runs.
• The workflow checks out the latest main SHA and runs both the Trivy runtime-image scan and govulncheck ./... with the same pinned versions, flags, and policies as their PR-time equivalents in ci.yml (image-scan job from relay: PR-time Trivy image CVE scan in ci.yml — fail on fixable CRITICAL/HIGH #68, security job from relay: govulncheck in CI — flag reachable Go vulns at PR time #41) — including ignore-unfixed: true, severity CRITICAL,HIGH, and vuln-type: os,library for Trivy.
• Any third-party action introduced by this workflow that is not already used by ci.yml (e.g. additional setup actions) is pinned per the same supply-chain logic as the PR-time scans (commit-SHA pin for non-first-party actions, version pin with tracking comment for binaries).
• Workflow permissions: is set to contents: read at the workflow level (no issues: write yet — that comes with relay: auto-file GitHub issue when periodic security-scan finds a regression #73).
• A manual workflow_dispatch invocation against current main completes both scan steps end-to-end. On a clean main the workflow run is green; verification that a vulnerable state produces a red run is exercised by relay: auto-file GitHub issue when periodic security-scan finds a regression #73's auto-issue test, so this ticket's verification only requires that the green path works.

Technical Notes

• Re-using shared steps with ci.yml via a reusable workflow or composite action is fine but not required. Optimize for clarity over DRY at v1.
• A failing scan step should fail the workflow run (default behavior of govulncheck and the Trivy action with exit-code: '1'). No additional summarization logic in this ticket.

Size Estimate

S

[ilmoniemi]

🤖 Product Owner — creates structured issues

po agent has completed work on this ticket.

Agent output (click to expand)

Refinement complete. The ticket already had a strong skeleton from the prior split of #69; the only red-line violation was 6 acceptance criteria (>5 limit), so I:

- Merged the parallel Trivy (AC2) and govulncheck (AC3) acceptance criteria into one, since both restate "same as the PR-time job" — collapsed into a single AC that names the concrete `ci.yml` jobs and the policy values (`ignore-unfixed: true`, severity `CRITICAL,HIGH`, `vuln-type: os,library`) so the architect doesn't have to re-read `ci.yml` to know them.
- Tightened the pinning AC (formerly AC4) to cover only *new* actions this workflow introduces, since the "same pinned versions" wording in the merged scan AC already covers the Trivy and govulncheck binaries.
- Pointed the deferred work explicitly at #73 rather than "the follow-up ticket."

Final shape: 5 ACs, one concern (cron-schedule a re-run of two existing scans), single file (`.github/workflows/security-scan.yml`), well under 100 LOC of YAML — `size:s` and `security-sensitive` labels stand. Dispatcher will auto-advance with `ready:po`.

Ready for human review. Move to the next column when approved.

[ilmoniemi]

🤖 System Architect — defines Go interfaces, data flows, concurrency patterns

architect agent has completed work on this ticket.

Agent output (click to expand)

Spec committed at `docs/specs/architecture/72-periodic-security-scan.md`.

**Summary**
- One new file `.github/workflows/security-scan.yml`, two parallel jobs (`image-scan`, `govulncheck`) that copy the policy from `ci.yml`'s `image-scan` job (#68) and the `govulncheck` portion of the `security` job (#41) verbatim.
- `cron: '0 6 * * *'` (daily, 06:00 UTC) + `workflow_dispatch`. Rationale for daily over weekly: caps disclosure-to-detection window at ~24h; runtime cost is ~3 min/run; pre-#73 the red-row signal needs to be recent to be noticed.
- Workflow-level `permissions: contents: read`; `issues: write` deferred to #73.
- No reusable workflow — clarity-over-DRY per AC. Lockstep convention with `ci.yml` is named in the spec; a CI lint to enforce it is listed in Open Questions but deferred per evidence-based-fix-selection.
- Security-review pass appended inline (label is `security-sensitive`). Verdict: PASS — no MUST FIX findings. The two non-trivial residual risks (silent SHA drift between `ci.yml` and `security-scan.yml`, hostile-maintainer `workflow_dispatch` abuse) are both pre-existing or out of threat-model scope.

Ready for human review. Move to the next column when approved.