Mask Secrets in CI Logs

CI logs are the most widely-readable output any project produces: retained for months, visible to everyone with repository access, often mirrored into chat notifications and pull-request summaries, and rarely thought about as a security surface. Every platform offers automatic masking, which is genuinely useful and considerably less complete than people assume. This page covers where masking fails and how to build a pipeline where a leak is a build failure rather than a rotation, extending the CI/CD config validation topic.

Problem 1: masking only matches the exact value

# ANTI-PATTERN: every one of these defeats the platform's masking
echo "$API_TOKEN" | base64            # encoded: no longer the string the platform knows
echo "${API_TOKEN:0:20}"              # truncated: a partial match is not a match
python -c "import json,os; print(json.dumps({'t': os.environ['API_TOKEN']}))"   # escaped

Masking is string replacement on the output stream. The platform holds the literal secret value and replaces occurrences of it; anything that changes the bytes — encoding, escaping, truncation, a line break inserted by wrapping — produces something that no longer matches and is printed in full. Base64 is the most common in practice, because encoding a credential for transport is a routine step in exactly the pipelines that handle credentials.

Treat masking as a safety net for the accidental exact-match case and not as a control you can rely on. The controls that actually hold are structural: do not print the value, do not pass it where something else will print it, and fail the build if it appears.

Problem 2: shell tracing and verbose tooling

# ANTI-PATTERN: every expanded argument goes to the log
set -x
curl -H "Authorization: Bearer $API_TOKEN" https://api.example.com/deploy
# + curl -H 'Authorization: Bearer sk_live_...' https://api.example.com/deploy

set -x prints each command with its arguments already expanded, so a credential on a command line is echoed verbatim before the command even runs. Because tracing is usually added while debugging a failing step — precisely the step that handles credentials — the two coincide more often than chance would suggest.

The same applies to verbose flags on ordinary tools: an HTTP client’s verbose mode prints request headers, a package manager’s debug output prints repository URLs with embedded credentials, and a test runner’s failure output prints local variables. None of these is doing anything wrong; they are all printing what they were asked to print. The discipline is to keep credentials off command lines entirely — pass them through the environment or standard input — and to enable verbose modes only in steps that touch nothing sensitive.

Problem 3: a failing test that prints the value

# ANTI-PATTERN: the assertion failure renders both sides into the CI log
assert settings.api_token.get_secret_value() == expected_token

pytest prints the compared values on failure, in full, and CI logs are far more widely readable than production logs. The test was written to verify unwrapping and does so correctly; the problem is entirely in what happens when it fails, which is the case nobody rehearses.

Compare a hash or the masked form instead, and keep one narrowly-scoped test that verifies unwrapping using a value that is obviously fake. That way a failure prints something harmless, and the property is still proven. The same logic applies to any debugging output a test emits: print(settings) is safe because the model masks, print(settings.model_dump()) may not be if a URL type is present.

Secure implementation

# .github/workflows/deploy.yml — secrets by environment, never on a command line
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Validate configuration
        env:
          # 1. injected into the process environment, not interpolated into a shell command
          DATABASE_URL: $
          API_TOKEN: $
        run: python -m app.config_check      # 2. the script decides what to print

      - name: Scan the working tree for credentials
        run: gitleaks detect --no-git --redact      # 3. --redact so findings are not themselves a leak

# app/config_check.py — reports shape, never value
import sys
from config import Settings
from pydantic import ValidationError

try:
    settings = Settings()
except ValidationError as exc:
    # 4. pydantic error output includes input values for some error types
    for error in exc.errors():
        print(f"invalid configuration: {'.'.join(str(p) for p in error['loc'])}: {error['type']}")
    sys.exit(1)

for name in settings.model_fields:
    value = getattr(settings, name)
    # 5. everything printed here is a shape, not a value
    print(f"{name}: set, length {len(str(value))}" if value is not None else f"{name}: unset")
print("configuration valid")

Printing the error type rather than the full pydantic error is a deliberate narrowing. Some validation errors include the offending input in their message — which is helpful locally and is a disclosure in a shared log if the offending input was a credential with one wrong character. The field path plus the error type identifies the problem precisely enough to fix it, and carries nothing.

The --redact flag on the scanner matters for the same reason. A secret scanner that prints the matched string has turned a finding into a second copy of the leak, in a log that is now guaranteed to be read by whoever investigates. Redacted findings tell you the file, the line and the rule, which is everything needed to act.

Making a leak fail the build

Prevention is better with a detection backstop, and CI is one of the few places where detection can be automatic and immediate. A step that scans the run’s own output for the shapes of known credential formats — a provider’s key prefixes, a JWT structure, a PEM header — turns a leak into a red build the moment it happens, rather than something discovered by a scheduled scan a week later or by an outsider.

The practical form is a post-step that fetches the job’s log and greps it for high-confidence patterns, failing the job on a hit. Keep the patterns to formats with distinctive prefixes and lengths, because a loose pattern that matches ordinary output produces false failures and gets disabled within a fortnight. It is better to detect three formats reliably than twenty unreliably.

Pair it with an ordering rule that makes the response cheap: rotate first, then delete the run, then fix the cause. Deleting the run first feels like containment and is not — the value has already been copied into caches, into any notification the platform forwarded, and possibly into a downstream artefact — while rotation invalidates every copy at once regardless of where they are. Write that order into the runbook, because the instinct under pressure is the opposite one.

One structural change is worth more than every masking rule combined: reduce the number of long-lived credentials the pipeline holds at all. Where a platform supports exchanging the job’s own identity for a short-lived cloud credential, a leaked value expires in minutes rather than remaining useful until somebody notices. That does not remove the need for the practices above — a fifteen-minute credential in a public log is still an incident — but it converts the worst case from “an attacker has production access indefinitely” into “an attacker had a narrow window”, which is a different conversation entirely. Adopt it for the credentials that support it and reserve stored secrets for the ones that genuinely cannot be exchanged.

Gotchas and version-specific behaviour

• Masking is exact-match replacement; encoding, escaping, truncation and wrapping all defeat it.
• set -x expands arguments before printing, so anything on a command line is disclosed.
• Multi-line secrets often mask poorly, since the platform matches per line and a key’s middle lines look like ordinary base64.
• Pull requests from forks usually cannot read secrets, which is a protection and a source of confusing failures.
• Pydantic validation errors can include the offending input; print the field path and error type instead.
• Secret scanners should run with a redacting flag, or a finding becomes a second copy of the leak.
• Log retention on CI platforms is typically long and rarely configured deliberately; assume anything printed persists for months and is readable by everyone with repository access.
• Job summaries, annotations and pull-request comments are separate output streams that may not be masked at all.

Production parity checklist

• No credential is ever passed on a command line; values reach processes through the environment or standard input.
• set -x and verbose tool flags are used only in steps that handle nothing sensitive.
• Configuration checks print shapes — set, length, hash prefix — and never values.
• Secret scanning runs with redaction enabled in both the pre-commit hook and the pipeline, so a finding never becomes a second copy of the leak.
• A detection step fails the build if a high-confidence credential pattern appears in the output.
• The runbook states the order: rotate, delete the run, fix the cause.

Key takeaways

Platform masking replaces exact occurrences of a known value, which makes it useless the moment a credential is encoded, escaped, truncated or wrapped — and encoding a credential is a routine step in the pipelines that handle credentials. Treat it as a net for accidents and rely instead on structure: credentials reach processes through the environment rather than command lines, verbose modes stay off in sensitive steps, and diagnostics print shapes rather than values.

Add detection so a leak fails the build immediately, keeping the patterns few and high-confidence so nobody disables them for noise. And settle the response order before you need it: rotate, then delete the run, then fix the cause, then check what was forwarded. Rotation is the only step that acts on copies you have not found, which is why it comes first. The surrounding pipeline gates are covered on the CI/CD config validation topic page.