An automated secret-scanning gate exists in the CI or pre-commit change path

A one-time secrets sweep tells you what has already leaked; a scanning gate in the change path is what stops the next leak, and the next one is coming: GitGuardian measured 23.8 million new secrets pushed to public GitHub in 2023 alone, and the Toyota incident (an access key sitting in a public repo for five years) shows how long a single miss survives. This evidences SOC 2 CC7.1 (detection and monitoring of configuration changes and vulnerabilities): the auditor wants to see a recurring, automated detection mechanism, not a clean point-in-time grep. AI-generated and vibe-coded apps typically fail here because coding assistants scaffold the app and sometimes even a test workflow, but no tutorial-shaped prompt ever adds gitleaks or trufflehog to CI, so the change path ships with zero secret detection while .env values migrate into committed config during rapid iteration. One leg of this check is an evidence-pointer: GitHub's native secret scanning and push protection live in repo settings that are invisible from a clone, so a committed doc stating they are enabled counts as the evidence an auditor will ask for, with the detail noting it is doc-evidenced rather than directly observed.

Add a blocking gitleaks step to your CI workflow, e.g. in .github/workflows/ci.yml:

- uses: gitleaks/gitleaks-action@v2
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Do not add continue-on-error: true; the step must be able to fail the build. Alternatively wire gitleaks protect --staged into .husky/pre-commit or add the gitleaks hook to .pre-commit-config.yaml. If you rely on GitHub's built-in secret scanning with push protection instead, enable it in repo settings and commit a short note in SECURITY.md stating that it is enabled, so the control is evidenced in the repo an auditor reviews.