GitHub secret scanning now reads your Actions logs, once the run is over

Somewhere in your org there is a build log with a live credential in it. Nobody put it there on purpose. A debug flag, a verbose CLI, a token that got base64-encoded on its way to stdout, and now it sits in a log that everyone with read access can open. GitHub's answer, now in public preview, is to have secret scanning read those logs for you.

The release, line by line

Secret scanning already covered issues, wikis, discussions and pull requests. It now covers GitHub Actions workflow logs too. When a workflow run completes, GitHub scans its logs for provider patterns. Findings land in the repository's secret scanning alert list, next to the alerts from code and other content, with a link back to the workflow log that leaked.

The rest of the changelog:

• Validity checks run for supported secret types, so you can see whether the leaked credential still works.
• Alerts stay around after the logs are deleted.
• The preview is for enterprises on GitHub Enterprise Cloud with GitHub Secret Protection or GitHub Advanced Security, including those with data residency on GHE.com.
• The policy is disabled by default, and it only applies to repositories that already have secret scanning enabled.

Why the log, of all places?

Because the log is where the masking gives up. Actions redacts secrets it knows about, the ones you registered or masked yourself. It redacts them by matching the exact string. Transform the value (encode it, slice it, wrap it in JSON, let a tool echo back an exchanged token) and the match fails. The redaction never sees it. Then set -x or a chatty deploy CLI prints the result, and the log keeps it for as long as your retention policy says.

So the trust boundary here is read access to Actions logs, which is usually a much wider group than the group that can see your secrets. A scanner that checks every completed run turns a quiet exposure into a tracked alert. That part is good. Credit where due.

Deleting the log does not close the alert, which is right. A deleted log is not a rotated key.

Turning it on

There is no YAML change. An enterprise owner goes to the enterprise settings, then Policies > Advanced Security, and picks Enabled in the All repositories dropdown. Repositories without secret scanning enabled are unaffected.

While you are at it, mask derived values yourself. The scanner reports a leak after the fact. A mask stops it from being printed at all:

- name: Exchange a short-lived token
  run: |
    TOKEN="$(./scripts/exchange-token.sh)"
    echo "::add-mask::$TOKEN"
    echo "DEPLOY_TOKEN=$TOKEN" >> "$GITHUB_ENV"

Mask first, export second. Get the order wrong and the value is printed before the mask exists.

Read the exclusions before you relax

The changelog is upfront about the limits, so be upfront with yourself about them.

• Only runs that complete after you enable it get scanned. Your existing logs are not backfilled. Whatever leaked before you flipped the switch stays where it is.
• Generic patterns, custom patterns, AI-detected secrets and already-masked secrets are excluded. Your internal API keys, which only a custom pattern would catch, are invisible to this feature.
• Alerts don't send notifications during the preview. Someone has to open the alert list and look. (Every security team's favourite workflow: remembering.)

Put together, this covers well-known provider credentials that slipped past masking in new runs, and that is all it covers. That is useful. It also turns into a false sense of coverage if your dashboard says "log scanning: on" and nobody reads the alerts.

What other CI systems do with leaked values

Most CI platforms handle this at print time:

• GitLab CI/CD masks variables flagged as masked in job logs, and requires the value to meet format rules before it can be masked.
• Jenkins, through the Credentials Binding plugin, masks bound credentials in console output.
• CircleCI masks project and context environment variables in job output.
• GitHub Actions itself masks registered secrets and anything passed to ::add-mask::.

All four share the weakness above: they match the exact value, so a transformed secret gets through. Reading the finished log is a second net behind the first. Neither one replaces short-lived credentials. A token that expires in an hour cannot do much harm in a log that lives for months.

Verdict

Turn it on if you're eligible. It costs nothing and catches the leaks masking misses. Then do the less pleasant work: rotate whatever it finds, move long-lived keys to federation, and give someone the job of checking an alert list that won't notify anyone. By the time the scanner finds a secret, the log has been readable by everyone with repo access. Treat each alert as a key that is already compromised.