GitHub now scans the output of completed Actions runs for secrets, adding a detection layer that sits alongside existing scans of code, issues, wikis, discussions, and pull requests. For teams that already rely on secret scanning, the change means that accidental exposure in build logs can be surfaced automatically, reducing the window of exposure.
How Actions workflow log scanning works
When a workflow finishes, GitHub parses the generated log and looks for patterns that match known secret providers. If a match is found, an alert is created in the repository’s secret‑scanning alert list, with a direct link back to the offending log entry. The service runs validity checks for the secret types it supports, and the alerts remain visible even after the original log files are deleted.
Enabling the preview in an enterprise
The feature is limited to enterprises on GitHub Enterprise Cloud that have either GitHub Secret Protection or GitHub Advanced Security, including those using data residency on GHE.com. An enterprise owner must open the enterprise settings, navigate to Policies → Advanced Security, and set the Enabled option in the All repositories dropdown. The policy is off by default and only applies to repositories that already have secret scanning turned on under the qualifying licenses.
Operational limits to consider
- Only workflow runs that complete after the policy is enabled are scanned; historic logs are not back‑filled.
- Generic patterns, custom patterns, AI‑detected secrets, and secrets that Actions has already masked are excluded from detection.
- During the preview, alerts generated from workflow logs do not trigger email or webhook notifications; practitioners must manually review the repository’s secret‑scanning alert list.
Related CloudNinjas coverage: security.
What This Means For Practitioners
Teams should verify that secret scanning is active on all relevant repositories before turning on the workflow‑log feature. Because alerts are not pushed, incorporate a regular check of the alert list into post‑run monitoring or dashboarding. Consider the impact of retaining logs long enough for scanning, and evaluate whether additional masking in workflows is still required given the new detection capability. Finally, track the preview’s progress toward general availability, as future updates may change notification behavior or broaden pattern coverage.
