GitHub adds secret scanning for completed Actions logs GitHub adds secret scanning for completed Actions logs

A new surface for credential checks

The November 9 release puts detected log credentials in the repository’s existing secret scanning alert list. Findings link back to the workflow log, and supported credential types receive validity checks. Alerts persist after the underlying logs are deleted. This changes where detection happens: a credential printed during execution can become an alert even when the source file itself contains no hardcoded value. For a team running automated builds, the log becomes a security surface with its own review queue. The feature’s access requirements also matter. Enterprise Cloud data-residency deployments on GHE.com are included, subject to the same licensing and repository prerequisites.

Detection and notification are separate

GitHub’s documentation distinguishes this feature from scanning Git history across branches. One log alert can collect several appearances of a credential across runs or jobs. Each location points to the originating workflow file and output line, without displaying an inline log excerpt. That grouping gives responders a way to trace repeated exposure without treating every occurrence as a different secret. The documentation also separates detection from remediation: revoking or rotating an exposed credential addresses its continued use. Removing stored output alone does not perform that revocation. A record that survives log deletion can therefore still carry useful follow-up work.

Provider patterns are getting narrower

A separate November 5 update changed the detectors behind secret scanning. GitHub added a Starlink API credential pattern and named SpaceX as a scanning partner. It also tightened matching for several providers. OpenVSX filtering now uses stronger context around legacy tokens; Pydantic Services matching follows the documented token length and character set. Those changes illustrate a different quality problem from missing log coverage. A scanner needs to distinguish a usable credential from an unrelated identifier or placeholder. Expanding the places searched and reducing incorrect matches are two separate improvements to the same alert backlog.

This is different from an AI security review

GitHub’s October 28 AI Scan preview examines repository code with an agentic scanner operating within a fixed time budget. It analyzes the latest default-branch commit and can cover languages outside CodeQL’s scope. Another October 28 preview targets AI application risks in pull requests, including indirect prompt injection, sensitive information disclosure and excessive agency. These features examine different evidence. An agent permission problem lives in application behavior and code paths; a credential leak may appear in execution output. Passing one review therefore does not establish that the other surface is clean. The new log scan adds a specific layer to that broader set of checks.