Skip to content
Infragr.amDocs

Secret scanning

After the collector sanitizes the plan, Gitleaks scans the exact serialized bundle, the same bytes that would be uploaded. It shares no code or rules with the collector. Its job is to catch what the collector’s rules didn’t anticipate, such as a token pasted into a tag or a key embedded in a description.

How Gitleaks runs

Section titled “How Gitleaks runs”
  • Version 8.28.0, downloaded from the official GitHub release.
  • Checksum-verified against a SHA-256 pinned in the Action for x64 and arm64. A mismatch fails the step.
  • Run with --redact=100, so a finding never prints the secret into your workflow log.

Modes

Section titled “Modes”

Set with the secret-scan input:

Mode On a finding Upload
block (default) Fails the step Nothing is sent
warn Adds a ::warning:: annotation Bundle is sent anyway
off Scan doesn’t run, and a warning says so Bundle is sent unscanned

Collector sanitization runs in every mode. Only this second pass changes.

If Gitleaks itself fails, meaning any exit status other than 0 (clean) or 1 (findings), the step fails in every mode and nothing is uploaded. A scanner that didn’t run isn’t a passing scan.

Handling a finding

Section titled “Handling a finding”

The step fails with:

Error: Gitleaks found a potential secret in sanitized output; nothing was uploaded.
  1. Assume it’s real until shown otherwise. Gitleaks found it in values that survived sanitization, which usually means a resource name, tag, description or other free-text attribute.
  2. Find it. Run the collector locally on the same plan, then run gitleaks stdin --no-banner < bundle.json without --redact on your own machine.
  3. Fix the source. Move the value into a sensitive variable, a secrets manager reference, or a TF_VAR_* environment variable. Once it is marked sensitive, the collector drops it.
  4. Only for an understood false positive, set secret-scan: warn on that workflow. Leave a comment in the YAML saying why.