GitHub’s new Actions log scanning: what your team needs to check

A deployment finishes successfully. Nobody receives a security notification. Before calling the run clear, there is another question to ask: which checks actually covered its output?

GitHub’s 9 November 2026 announcement adds secret scanning for GitHub Actions workflow logs in public preview. Actions runs automated jobs such as tests and deployments; their logs record what those jobs print. A secret is an access credential, such as a token or password.

The useful change is another place to detect exposure. Making it useful also requires a clear account of the feature’s scope and a person responsible for looking at its findings.

What changed, and who can use it

GitHub’s announcement makes the preview available to GitHub Enterprise Cloud enterprises with GitHub Secret Protection or GitHub Advanced Security, including GHE.com data residency. It is disabled by default. An enterprise owner enables the policy under Policies, then Advanced Security; eligible repositories must also have secret scanning enabled.

Completed runs are checked for provider patterns, recognisable formats associated with credential providers. Findings enter the repository’s secret scanning alert list. Validity checks apply to supported types, and alerts remain after log deletion.

This is an enterprise preview, rather than a promise that every GitHub account has received another automatic check. If you cannot find the setting, confirm the plan and your role with the enterprise owner before troubleshooting an individual workflow.

Check the boundary before interpreting the result

GitHub’s documentation says that past logs are not scanned. Only runs completing after enablement are included. The log preview excludes generic patterns, custom patterns, AI-detected secrets and values already masked by Actions. It also sends no notifications for these alerts during the preview.

Masking replaces sensitive output with a concealed value. It is different from detecting an exposed credential afterwards. Similarly, a successful workflow reports that its jobs met their execution conditions; it does not establish that their output contains no sensitive material.

An empty alert list therefore needs context. Perhaps the relevant run predates enablement. Perhaps the material belongs to an excluded pattern class. Perhaps there was nothing for this detector to find. Those are different explanations, and the list alone cannot choose between them.

A worked example: three runs, different coverage

Consider this example: Lena owns the release process for a workshop-booking service. Her enterprise owner enables the preview on Tuesday 10 November at 09:30. The repository otherwise meets the eligibility requirements. All example times are UK time.

The team compares three constructed run records. No credentials are shown, created or submitted to a scanner in this exercise.

Run A still needs a separate decision about historical exposure. Run C needs controls appropriate to the internal credential. Run B belongs in the review of the new feature, but the team should not record it as safe merely because no message arrived.

Lena records the time boundary and exclusions alongside the review task. That gives a colleague enough information to question the conclusion without asking anyone to paste a token into a ticket.

Write a review agreement before switching it on

I would use a short agreement rather than leaving “check security” in a release checklist. It should answer six questions:

For Lena’s team, an example agreement assigns the release engineer to inspect the alert list after the deployment run and before the release handover. The service owner handles credential decisions; a named deputy covers absence. This is an illustrative working agreement, not a GitHub requirement.

If your team lacks the enterprise preview, keep the questions. They expose missing responsibilities without pretending that a setting is available on your plan.

Practise without planting a secret

Spend fifteen minutes with a colleague and a blank version of the table. Choose one authorised workflow. Record its run identifier, completion time and logging steps, without copying sensitive output.

Confirm the feature’s eligibility and enablement with the responsible administrator. Classify the run against the time boundary and pattern scope. Write down what remains unknown. If those settings cannot be confirmed, record coverage as unverified rather than assuming it.

GitHub’s existing secure-use guidance recommends auditing how workflows handle secrets and checking logs after valid and invalid inputs. Redaction is not guaranteed in every case. Start by preventing unnecessary sensitive output and reviewing the commands and actions that produce it.

If you discover an exposure, use your organisation’s incident process and involve the credential owner. GitHub recommends rotation and removal of exposed log material. Deleting a log does not make a credential unusable, and a retained alert still needs a response.

Your next step is small: choose one workflow and name the person who will review its alerts. Pair that name with a written coverage boundary. Then an empty list becomes a limited piece of evidence that the team can explain, rather than a conclusion nobody checked.