GitHub Extends Secret Scanning to GitHub Actions Workflow Logs

On November 9, 2026, GitHub announced a public preview that detects secrets inside GitHub Actions workflow run logs. Until now, secret scanning covered source code and a handful of other locations, but left out the logs generated by workflows themselves, a common leak vector whenever a build step accidentally prints a sensitive value.

#Why this blind spot mattered

A CI/CD workflow constantly handles tokens, API keys, and deployment credentials. A stray debug command, a forgotten print statement, or a mishandled error is enough to expose those values in a public or shared log, without any of the usual scanning tools catching them since they were never committed to the repository.

#How the feature works

Once enabled, GitHub scans each run’s logs after the run finishes; past runs are not scanned retroactively. Detected secrets appear in the repository’s secret scanning alert list, alongside alerts from code, with a direct link to the log location. Validity checks apply to secret types that support them, and alerts remain available even after the underlying logs are deleted.

#Turning it on

The setting lives at the enterprise level, under Policies, then Advanced Security, where Secret scanning for Actions workflow logs needs to be set to Enabled for the relevant repositories. The feature only applies to repositories that already have standard secret scanning turned on.

name: build
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: |
          # a debug command that leaked this variable would now
          # also land in the secret scanning alert list
          ./build.sh

Existing logs are not retroactively rescanned: only runs that finish after the feature is enabled are covered.

#Limits of this preview

Coverage remains partial: only known provider patterns are detected, excluding generic or custom patterns and secrets flagged by heuristic methods. The lack of notifications during the preview phase also means teams need to check the repository’s alert list manually rather than rely on an automatic nudge. The underlying discipline is the same one already covered when GitHub started blocking pull_request_target by default: enabling a safeguard ahead of time matters more than reacting after an incident.

#Key takeaways

This extension closes a known blind spot for teams running GitHub Actions pipelines, without replacing basic good practice: systematically masking secrets, rotating them regularly, and scoping down the tokens used in CI/CD. It fits alongside other recent platform changes aimed at shrinking the attack surface of workflows.

#Further reading

Primary source: GitHub’s official changelog, November 9, 2026.