[Feature] Security scanning: CodeQL, dependency review/OSV, SECURITY.md

[pathosDev]

Use case

The repo has a security issue template, security / severity: labels, a large security audit catalog (#108–#145) and a security-first posture in AGENTS.md — but no automated security tooling at all: no CodeQL/SAST, no dependency vulnerability scanning (osv-scanner / dependency-review-action / audit step), no SBOM, and no SECURITY.md, so GitHub surfaces no disclosure policy. For a framework that parses untrusted wire frames, HOCON, and HTTP input, this is the biggest missing tool class after the linter (#417).

Proposed approach

• SECURITY.md: supported versions (pre-1.0 policy), private disclosure channel, response expectations. Quick win, land first.
• CodeQL workflow (javascript-typescript), scheduled + PR, with a triage-then-tune approach to keep noise down.
• dependency-review-action on PRs + a scheduled osv-scanner run over bun.lock.
• Optional follow-up: SBOM generation on release.

Acceptance criteria

• SECURITY.md present and linked from the README
• CodeQL running on PRs + schedule with a triaged baseline (no open untriaged alerts)
• Dependency review / OSV scanning wired and documented
• New findings get filed with the existing security + severity: taxonomy

Related

• [Security] HKDF info-parameter is static across deployments #108–[Security] SeedProvider DNS resolution not pinned, vulnerable to DNS hijack #145 (manual audit catalog this complements), [Feature] Adopt Biome as the repo formatter + linter #417 (Biome — the other missing tool class)

[pathosDev]

Cross-referencing from the 2026-08-01 security audit (#627): the audit independently flagged the missing SECURITY.md as a process gap before this issue existed. Filed it as #617, now closed as a duplicate of this one — the substance is folded in here so nothing is lost.

Two details worth carrying into the SECURITY.md deliverable:

1. The security issue template already points at a file that does not exist. .github/ISSUE_TEMPLATE/security_report.yml:13-14 says "please first check the project's security policy in SECURITY.md (or, if absent, contact the maintainer privately)". Once the file lands, the (or, if absent, …) hedge should come out — right now the discoverable path leads a reporter back to the public tracker, which is the one place a live vulnerability should not go first.

2. Worth stating scope explicitly, because this project has an unusual boundary. The cluster transport defaults to plain, unauthenticated TCP by design (docs/src/content/docs/operations/security/cluster-security.mdx), so reports about that default are out of scope — but reports about the documented mitigations failing very much are. That distinction is not hypothetical: the audit found that the documented mTLS recipe provides no peer authentication at all ([Security] Cluster TLS listener never requests a client certificate — requestClientCert defaults to false, so the documented mTLS recipe gives zero peer authentication #565). Drawing the line in SECURITY.md saves triage effort on both sides.

Also relevant to the "new findings get filed with the existing taxonomy" criterion: the audit added 65 issues (#562–#626) using exactly that taxonomy, so there is now a worked example of the intended shape.

[pathosDev]

Round-4 scope addition: attach a CycloneDX SBOM to each GitHub Release (generated in the publish workflow). Pairs naturally with the OSV/dependency-review part of this issue and with #779's advisory-scanning ask.