Production secrets are platform-managed and the repo documents where they live

SOC 2 CC6.1 (logical access security software, infrastructure, and architectures) expects credentials that gate production systems to live in a managed store with controlled access, not in flat files anyone with repo read access can copy. This check evidences CC6.1: an auditor's first secrets question is "where do production credentials live and who can read them", and the answer must be a platform (Vercel or Netlify encrypted env vars, AWS Secrets Manager, Google Secret Manager, Vault), not a tracked .env. AI-generated and vibe-coded apps typically fail this because coding assistants scaffold dotenv plus a working .env, the app runs, and nothing ever forces the move to a managed store or the writing of a .env.example, so the team cannot even enumerate which secrets exist. This is partly an evidence-pointer check: for dashboard-managed platform env vars it verifies committed evidence of the control (a .env.example, platform config, or ops doc naming the store), which is exactly the artifact a SOC 2 auditor will ask for. It deliberately does not grep for leaked literal values; the sibling no-hardcoded-secrets check covers that. This one checks management posture and documentation.

Move every production credential into your deploy platform's encrypted env vars (Vercel, Netlify, Railway) or a secrets service (AWS Secrets Manager, Google Secret Manager, Vault), read them via process.env only, and commit a .env.example that enumerates each expected variable with placeholder values (STRIPE_SECRET_KEY=sk_live_xxx_set_in_vercel_dashboard). If any tracked file currently holds live values, rotate those credentials, then git rm --cached .env and add it to .gitignore. Add a short ops note (for example docs/secrets.md or a README section) naming the store so the location is auditable from the repo.