Skip to main content
On this page

Suspicious PII Leakage in Resource Attributes

Critical Signal: Resource

Problem

Your resource attributes carry values that look like personal or sensitive data: emails, national or tax IDs, credentials, or financial identifiers, including values nested in arrays or JSON. A common source is a credential passed as a command-line argument and captured in process.command_args. Resource attributes are attached to every span, metric, and log the process emits, so one leaked value is repeated across all of your telemetry.

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

This finding scores against Instrumentation Score rule RES-010.

Impact

  • Regulatory exposure: personal data in telemetry falls under GDPR, LGPD, and similar regimes, including breach-notification duties.
  • The data spreads: every backend, every retention window, every export now holds a copy, readable by anyone with dashboard access.
  • Cleanup after the fact is far more expensive than never emitting it.

Example

Leaking:

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

Safe:

# resource attributes
process.command_args: ["./worker"]
# read the password from a file or environment variable the SDK does not capture

How to fix

  1. Identify where the resource attribute is set: SDK resource detectors, OTEL_RESOURCE_ATTRIBUTES, or Collector processors.
  2. Remove or redact the sensitive value at the source. Never pass credentials as command-line arguments captured in process.command_args.
  3. Until the source is fixed, use the Collector resource or transform processor to delete or hash the attribute.

Expected gains

Sensitive data stops riding along on every signal the service emits, and your compliance surface shrinks to the systems that actually need the data.

See the Insights catalog for everything Insights can detect.