relay: periodic security-scan cron workflow with auto-issue filing on detection

[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 and automatically files a GitHub issue when it detects a regression, so that newly-disclosed CVEs against dependencies that have not changed since the last PR are surfaced for action instead of scrolling past in Actions logs.

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 until someone next happens to bump that dep.

This ticket adds a single "security audit" cron workflow that re-runs:

1. The runtime-image CVE scan introduced in the PR-time image-scan ticket split from relay: CI image scanning — Trivy or Grype, fail on CRITICAL CVEs #40.
2. The reachable-Go-vuln scan introduced in relay: govulncheck in CI — flag reachable Go vulns at PR time #41.

A scan failure must result in a GitHub issue being created automatically — not just a red workflow run — so the failure has an action owner and visible status.

Split from #40. Depends on the PR-time image scan landing first (so the cron can reuse the same scan invocation) and on #41 landing first (so the cron can invoke govulncheck against main with an established pattern).

Acceptance Criteria

• A new workflow file (e.g. .github/workflows/security-scan.yml) runs on a schedule — daily or weekly, architect chooses — and additionally supports workflow_dispatch for manual re-runs.
• The workflow checks out the latest main SHA and runs both the runtime-image CVE scan (same scanner, severity policy, and ignore-unfixed policy as the PR-time job) and govulncheck ./... (same invocation as relay: govulncheck in CI — flag reachable Go vulns at PR time #41).
• When either scan reports a failure-condition finding, the workflow creates a GitHub issue in this repository via gh issue create whose body contains the scanner output excerpt, the offending CVE id(s) or vuln id(s), the affected dependency or image layer, and the workflow run URL.
• The created issue is labeled security-sensitive so it routes through the normal triage flow.
• The workflow does not file a duplicate issue if an open issue with the same CVE/vuln id and the same affected component already exists — either by searching open issues before filing or by using a deterministic title pattern that lets operators spot duplicates by eye. Perfect dedup is not required; non-spammy is.
• Workflow permissions are scoped to the minimum needed: contents: read for checkout; issues: write only on the issue-filing step.
• Scanner / action versions are pinned (same supply-chain logic as the PR-time scan).
• A manual workflow_dispatch invocation against a clean main succeeds end-to-end without filing an issue (no findings → no issue); during verification a deliberately-vulnerable state results in an issue being filed.

Technical Notes

• Re-using shared steps with the PR-time workflow (e.g. via a reusable workflow or composite action) is fine but not required at this size. Optimize for clarity over DRY at v1.
• The auto-filed issue is the starting point for human triage, not its final form — the body can be terse as long as it links the workflow run.

Size Estimate

S

[ilmoniemi]

Closing as split during PO refinement.

The original ticket combined two concerns (periodic re-scan + auto-issue filing) and tripped the >5 AC red line (8 ACs), so it was split per the PO playbook:

• relay: periodic security-scan cron workflow (re-runs Trivy + govulncheck against main) #72 — relay: periodic security-scan cron workflow (re-runs Trivy + govulncheck against main). Adds .github/workflows/security-scan.yml with the cron schedule, workflow_dispatch, and both scan invocations. Red workflow run on failure; no issue-filing yet.
• relay: auto-file GitHub issue when periodic security-scan finds a regression #73 — relay: auto-file GitHub issue when periodic security-scan finds a regression. Depends on relay: periodic security-scan cron workflow (re-runs Trivy + govulncheck against main) #72. Adds the issue-creation step with dedup, security-sensitive label, scoped issues: write permission, and the vulnerable-state verification.

Each child is self-contained and references upstream specs (#41, #68) directly. #73 is marked blocked-by #72 natively so the dispatcher will automatically unblock #73 when #72's PR merges.

[ilmoniemi]

🤖 Product Owner — creates structured issues

po agent has completed work on this ticket.

Agent output (click to expand)

Split complete. #69 tripped the >5 AC red line (8 ACs) and the "and" red line (user story combined two distinct deliverables), so per the playbook it had to split — no judgment call.

**Children created:**
- **#72** — relay: periodic security-scan cron workflow (re-runs Trivy + govulncheck against main). `size:s`, `security-sensitive`. Ready in Backlog.
- **#73** — relay: auto-file GitHub issue when periodic security-scan finds a regression. `size:s`, `security-sensitive`. Marked **blocked-by #72** natively, so the dispatcher will hold it until #72's PR merges.

Both children added to project #3 as sub-issues of #69, status set to Backlog, positioned immediately after the parent's old slot (so they inherit #69's column priority). #69 moved to Done and closed with a split-summary comment. No external dependents needed re-pointing (`blocking` query was empty).

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