GitHub secret scanning now covers Actions workflow logs
A new public preview scans completed Actions runs for exposed secrets, closing a gap that let credentials leak through build output rather than source code.
GitHub’s secret scanning can now check GitHub Actions workflow logs for exposed secrets, the company said on 9 November. Previously it covered issues, wikis, discussions and pull requests, but not the build output where a stray echo $API_KEY or an unmasked environment variable most often ends up.
The feature is in public preview and available to enterprises on GitHub Enterprise Cloud with GitHub Secret Protection or GitHub Advanced Security, including GHE.com data residency customers. It’s off by default: an enterprise owner has to turn it on under Policies > Advanced Security. Once enabled, it only scans workflow runs that complete afterwards, so nothing in your existing log history gets checked. During preview, findings show up in the repository’s secret scanning alert list but don’t trigger a notification, and generic patterns, custom patterns and AI-detected secrets aren’t covered yet, only the known-pattern secrets GitHub already recognises.
Why it matters: workflow logs are a common and under-watched leak path, a debug step or a misconfigured action can print a token straight into a log anyone with repo read access can see. If you’re on an eligible plan, turning this on costs nothing and catches a class of leak that source-code scanning never will.
The caveat: it won’t backfill old runs, and it skips custom and AI-detected secret patterns for now, so it’s a narrower net than the alert list might suggest.