Propose new critical rules for detecting sensitive data in telemetry (RES-010, SPA-006, LOG-003)

[jpkrohling]

Problem

Telemetry data is typically stored in observability backends with broader access than production databases. When telemetry contains sensitive data — personally identifiable information, financial identifiers, credentials, or health data — it creates compliance risks (GDPR, HIPAA, PCI-DSS) and security vulnerabilities.

This is one of the most common and impactful instrumentation mistakes, yet the spec currently has no rules addressing it. We propose a family of three Critical rules, one per signal target.

Common types of sensitive data

• Personal identifiers: email addresses, phone numbers, social security numbers, national ID numbers, passport numbers
• Financial data: credit card numbers (PANs), bank account/routing numbers, tax IDs (EIN, ITIN, VAT numbers)
• Credentials & secrets: bearer/JWT tokens, API keys, passwords, private keys, session tokens
• Health data: patient IDs, diagnosis codes, insurance IDs

Common leakage vectors

Sensitive data most commonly enters telemetry through:

1. db.query.text — SQL statements with embedded user data (e.g., SELECT * FROM users WHERE email='alice@example.com')
2. url.full / url.query — PII in query parameters (e.g., ?email=user@example.com&ssn=123-45-6789)
3. http.request.header.* — Authorization headers, cookies, and other headers carrying tokens or session data
4. process.command_args — credentials passed as CLI flags (e.g., -Djavax.net.ssl.trustStorePassword=SECRET)
5. Log record body — application logs that dump user context or request payloads
6. Custom/application-specific attributes — developers instrumenting their own code and inadvertently capturing sensitive fields

Proposed rules

RES-010: Resource attribute values do not contain sensitive data

Target: Resource | Impact: Critical
Key vectors: process.command_args with embedded credentials, custom resource attributes capturing environment variables with secrets.

SPA-006: Span attribute values do not contain sensitive data

Target: Span | Impact: Critical
Key vectors: db.query.text with embedded user data, url.full / url.query with PII in query parameters, http.request.header.* with authorization headers or cookies, custom attributes capturing unsanitized request/response payloads.

LOG-003: Log record bodies do not contain sensitive data

Target: Log | Impact: Critical
Key vectors: Application logs that dump user context, request payloads, or error messages containing credentials or PII.

Shared criteria

Attribute values / log record bodies MUST NOT contain patterns matching common sensitive data formats, including but not limited to:

• Email addresses
• Credit card numbers (sequences of 13–19 digits matching Luhn validation)
• Social security numbers or national ID numbers
• Bearer tokens, API keys, or other credentials
• Passwords or secrets in key-value patterns (e.g., password=..., secret=..., token=...)
• Financial identifiers such as bank account numbers or tax IDs

Open questions for discussion

1. Pattern specificity: Should the spec prescribe specific regex patterns, or leave detection heuristics to implementers?
2. Impact level: Is Critical the right level for all three, or should some be Important given the heuristic nature of pattern matching?
3. Overlap with RES-006–RES-009: The proposed RES-009 (Data Sensitivity) from #99 covers service.data_sensitivity — complementary but distinct from this proposal, which detects actual sensitive data in attribute values.

References

• OTel Semantic Conventions: Sensitive Information
• Note: RES-006 through RES-009 are reserved by a pending proposal; this uses RES-010.