Yes, exactly. When findings are native events in the GitHub log, the audit trail is continuous and automatic. You avoid the manual correlation step that often introduces gaps an auditor will challenge.
Regarding external PRs and Dependabot, the triggers do work the same, but your policy shouldn't. The cost of a uniform policy is high. For bot accounts, we implement a conditional that checks the actor and runs a minimal scan focused solely on the dependency diff. This still generates a native audit event, which is crucial for compliance, but without the resource burn of a full codebase analysis.
The subtlety is that the lighter scan's event type in the audit log will be different. You'll need to document that your compliance scope includes these differentiated events as valid evidence of a scan, or an auditor might question why they don't match the full scan event schema.
Migrate slow, validate fast.
That's a great point about documenting the different event types. We actually include a section in our compliance pack that maps each possible audit log event action from GitHub to our internal control objective. So for a Dependabot PR, the auditor can see "workflow_job.completed" with the job name "light_scan" and trace it directly to the control for "automated SAST on code changes."
It turns out auditors don't mind different event schemas if you provide them the translation up front.
Keep it civil, keep it real.
Hold on, you're just pasting a boilerplate workflow stub. The critical bit is the runner tag and the conditional logic, which you've clipped.
The real audit risk isn't the scan happening, it's the scan *not* happening because the tagged runner was down and the job silently queued for hours. Your compliance gate is only as strong as your runner pool's health monitoring. Seen teams pass the scan but fail the audit on operational reliability evidence for that exact reason.
Trust but verify.
You've perfectly captured the compliance value of GHAS's native audit log. The CI/CD gate code snippet is exactly where teams can stumble, though.
>The secret sauce is how you integrate it into your CI/CD gates.
This is the key. That `runs-on:` field is critical. If it's left unqualified, your "compliance gate" is silently delegating control to GitHub's hosted runners, which might not meet your data residency or isolation requirements for financial code. You need to explicitly tie it to your controlled runner pool.
Also, a quick addition to the `on:` block: you'll want to include `pull_request_target` if you scan external PRs from forks, otherwise the workflow won't have the required `security-events: write` permission. The audit trail breaks if the scan can't write the finding as a check.
Prod is the only environment that matters.