Suspicious Credential Leakage in Resource Attributes

Problem

Your resource attributes carry values that look like credentials: passwords, access tokens, API keys, or other secrets. Because resource attributes ride along on every span, log record, and metric datapoint the service emits, one leaked value is repeated millions of times. A common source is a secret passed on the command line and captured in process.command_args; values nested in arrays or JSON are caught too.

Insights reports where it found the value and what kind of credential it looks like. The matched value itself is never stored.

This finding scores against Instrumentation Score rule RES-010.

Impact

• A credential in telemetry is live attack surface: anyone with dashboard access can read and use it.
• The data spreads: every backend, every retention window, every export now holds a copy, far outside the systems the credential was scoped to.
• A detected credential has to be treated as compromised. Rotation and access review cost far more than never emitting it.

Example

Leaking:

# resource attributes
process.command_args: ["./server", "--db-password=hunter2"]

Safe:

# resource attributes
process.command_args: ["./server"]
# the secret comes from a file or secret manager, never argv

How to fix

1. Treat every detected credential as compromised: rotate or revoke it, then review access made with it.
2. Find where the attribute is set — SDK resource detectors, OTEL_RESOURCE_ATTRIBUTES, or Collector processors — and remove the secret at the source. Pass secrets through files or a secret manager, never as command-line arguments.
3. Until the source is fixed, use the Collector resource or transform processor to delete or redact the attribute, and restrict or purge the copies already stored.

Expected gains

Credentials stop flowing into your observability stack, and a leak stops being multiplied onto every signal the service emits.

See the Insights catalog for everything Insights can detect.