Skip to content
Exlogare
← Back to all posts
by Exlogare Team CI/CD logs redaction security

Redacted logs: what to remove from CI logs and what not to redact blindly

Tokens and private keys must be hidden, but job IDs, versions, service names, and exit codes are often required for RCA. Here is the balance between safety and diagnosability.

Redaction is easy to overdo. It feels like the more you remove, the safer you are. Technically, yes. But if the cleaned log only says ERROR [REDACTED] failed at [REDACTED], nobody can diagnose the failure anymore.

A good redacted log preserves diagnostic context and removes only what can cause harm: secrets, private keys, personal data, and internal tokens.

Redaction vs anonymization

Redaction hides specific risky fragments: a token becomes [REDACTED_TOKEN], a URL with a password becomes a safe URL without credentials. Anonymization removes broader identity information. CI usually needs redaction, because the structure of the error is still important.

What to always redact

  • JWTs and bearer tokens.
  • AWS/GCP/Azure keys.
  • SSH/private keys.
  • Basic-auth credentials in URLs.
  • kubeconfig and service account tokens.
  • .npmrc, .pypirc, Docker auth.
  • Customer emails/phones in test dumps.

When in doubt, redact. A secret that reaches an external service or artifact is much harder to “forget” than a local log line.

What not to redact blindly

RCA often needs:

  • job and stage name;
  • pipeline/build/job number;
  • exit code;
  • Docker image/runtime version;
  • package name;
  • test file and test case;
  • service name;
  • URL without credentials;
  • the final 20–50 stack-trace lines.

For example, connect ECONNREFUSED db:5432 contains useful service and port context. If you replace everything with connect [REDACTED], the RCA loses the signal.

Typed markers are better than blank output

Bad:

Error: request failed with token abc123...

Good:

Error: request failed with token [REDACTED_TOKEN]

Better:

Error: registry auth failed for registry.internal.example.com with token [REDACTED_NPM_TOKEN]

The log stays safe while preserving context: this is a registry-auth problem, not a test failure.

Where Exlogare fits

Exlogare benefits from good redaction: the model sees enough context to say “npm registry authorization failed after a token change,” but it never sees the token. Before connecting external analysis, decide which fields stay and which are always masked.

For payload shape, see the ingest API and the generic CI integration. For data-handling principles, see Security.

Related reading

Checklist

  • Tokens become typed placeholders.
  • URLs stay, credentials are removed.
  • Job/stage/build IDs remain in the log.
  • Exit code and final stack trace lines remain.
  • PII in test data is masked.
  • Redaction is tested against real failures, not only synthetic samples.