A SECURITY.md vulnerability-disclosure policy with a real reporting contact is committed to the repo

This is an evidence-pointer check: it verifies committed evidence of the control, which is what an auditor will ask for. SOC 2 CC2.3 requires the entity to communicate with external parties about matters affecting internal control, and a vulnerability-disclosure policy is the cheapest CC2.3 evidence a repository can carry: a SECURITY.md naming a working reporting contact plus instructions for what to send. AI coding tools scaffold READMEs, licenses, and CI configs but essentially never generate a disclosure policy, and template repos that do include one often ship it with security@example.com placeholder text, so vibe-coded apps routinely reach production with no intake channel at all. The consequence is concrete: a researcher who finds a hole and cannot locate a contact either gives up or discloses publicly, and when the SOC 2 auditor asks how external parties report security issues, there is nothing to point at.

Commit a SECURITY.md at the repo root (or .github/SECURITY.md) with a real contact and reporting instructions, for example:

# Security Policy

## Reporting a Vulnerability
Email security@yourdomain.com, or use GitHub private vulnerability
reporting on this repository ("Report a vulnerability" under the
Security tab). Include the affected endpoint or file, reproduction
steps, and expected impact. We acknowledge reports within 5 business days.

If the app is deployed, additionally publishing /.well-known/security.txt (see https://securitytxt.org) gives researchers a machine-findable contact; the SECURITY.md can link to it as the canonical channel.