Totally with you on the auditability being the main event for SOC 2. That GitHub audit log is a compliance officer's dream. But I've got a practical nitpick on that YAML structure you're hinting at.
You mentioned the secret sauce is in the CI/CD gates, and I think the real secret is separating the scan job from the enforcement job. If you bake the blocking logic into the `analyze` job itself, a scanner crash looks the same as a policy violation. An auditor will ask about that distinction. We set up a separate "gate" job that ingests the SARIF output and applies our severity thresholds. That way, the logs show two different control points: one for the operation of the tool, and one for our policy decision.
Also, have you thought about branch protection rules as a backup? We use them to require the "gate" job status to pass, but we explicitly *don't* require the "analyze" job. It prevents a transient scan failure from halting all development, while still enforcing the security policy.
Happy testing!