{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "item": { "id": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "slug": "minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction", "url": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction.md", "json": "https://update.dsesecurity.com/api/v1/posts/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/" }, "title": "Minimize sensitive OpenTelemetry data before relying on downstream redaction", "summary": "The simplest exposure to avoid is information the pipeline never needed to collect.", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-10-20T18:15:49+00:00", "modified_at": "2026-10-20T18:34:34+00:00", "reviewed_on": "2026-10-20", "reading_minutes": 2, "word_count": 254, "potentially_affected": "Review necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.", "dse_recommendation": "DSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner.", "primary_source": { "name": "OpenTelemetry documentation — Handling sensitive data", "url": "https://opentelemetry.io/docs/security/handling-sensitive-data/", "published_on": null, "authority": "opentelemetry.io" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "

The simplest exposure to avoid is information the pipeline never needed to collect.

\n

Source facts

\n

OpenTelemetry’s sensitive-data guidance recommends collecting only information serving an observability purpose, avoiding personal data unless necessary, and considering aggregation or anonymization. It describes attribute removal, transformation, and redaction approaches, while emphasizing review of collected attributes. The source treats minimization as an initial design decision rather than merely a final export filter.

\n

Source: OpenTelemetry documentation — Handling sensitive data.

\n

Applicability

\n

Review necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.

\n

DSE recommendation

\n

DSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner. Remove unnecessary collection at the earliest practical point. For required sensitive information, define access, retention, and a documented transformation policy. Keep unexpected-field detection in the review so a new application release cannot quietly reintroduce data. Test changes with synthetic values and inspect every relevant signal type, including diagnostic outputs that might bypass the normal backend path.

\n

Verification

\n

In a nonproduction pipeline, send representative synthetic sensitive fields through the intended configuration. Inspect receiver-side assumptions, processed output, and final destination behavior without using real customer information. Confirm required operational context remains usable and that unexpected attributes receive the documented treatment before enabling the policy broadly. Retain the synthetic input/output field inventory with the transformation policy. Ask the data owner to approve both necessary retained context and the handling of a newly introduced unexpected field before the policy is applied to real telemetry.

\n

Official reference

\n

OpenTelemetry documentation — Handling sensitive data. Reviewed October 20, 2026.

", "content_text": "The simplest exposure to avoid is information the pipeline never needed to collect.\nSource facts\nOpenTelemetry’s sensitive-data guidance recommends collecting only information serving an observability purpose, avoiding personal data unless necessary, and considering aggregation or anonymization. It describes attribute removal, transformation, and redaction approaches, while emphasizing review of collected attributes. The source treats minimization as an initial design decision rather than merely a final export filter.\nSource: OpenTelemetry documentation — Handling sensitive data.\nApplicability\nReview necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.\nDSE recommendation\nDSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner. Remove unnecessary collection at the earliest practical point. For required sensitive information, define access, retention, and a documented transformation policy. Keep unexpected-field detection in the review so a new application release cannot quietly reintroduce data. Test changes with synthetic values and inspect every relevant signal type, including diagnostic outputs that might bypass the normal backend path.\nVerification\nIn a nonproduction pipeline, send representative synthetic sensitive fields through the intended configuration. Inspect receiver-side assumptions, processed output, and final destination behavior without using real customer information. Confirm required operational context remains usable and that unexpected attributes receive the documented treatment before enabling the policy broadly. Retain the synthetic input/output field inventory with the transformation policy. Ask the data owner to approve both necessary retained context and the handling of a newly introduced unexpected field before the policy is applied to real telemetry.\nOfficial reference\nOpenTelemetry documentation — Handling sensitive data. Reviewed October 20, 2026.", "content_markdown": "The simplest exposure to avoid is information the pipeline never needed to collect.\n\n## Source facts\n\nOpenTelemetry’s sensitive-data guidance recommends collecting only information serving an observability purpose, avoiding personal data unless necessary, and considering aggregation or anonymization. It describes attribute removal, transformation, and redaction approaches, while emphasizing review of collected attributes. The source treats minimization as an initial design decision rather than merely a final export filter.\n\nSource: [OpenTelemetry documentation — Handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/).\n\n## Applicability\n\nReview necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.\n\n## DSE recommendation\n\nDSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner. Remove unnecessary collection at the earliest practical point. For required sensitive information, define access, retention, and a documented transformation policy. Keep unexpected-field detection in the review so a new application release cannot quietly reintroduce data. Test changes with synthetic values and inspect every relevant signal type, including diagnostic outputs that might bypass the normal backend path.\n\n## Verification\n\nIn a nonproduction pipeline, send representative synthetic sensitive fields through the intended configuration. Inspect receiver-side assumptions, processed output, and final destination behavior without using real customer information. Confirm required operational context remains usable and that unexpected attributes receive the documented treatment before enabling the policy broadly. Retain the synthetic input/output field inventory with the transformation policy. Ask the data owner to approve both necessary retained context and the handling of a newly introduced unexpected field before the policy is applied to real telemetry.\n\n## Official reference\n\n[OpenTelemetry documentation — Handling sensitive data](https://opentelemetry.io/docs/security/handling-sensitive-data/). Reviewed October 20, 2026." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "url": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-20" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Minimize sensitive OpenTelemetry data before relying on downstream redaction", "item": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/#article", "identifier": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "url": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/", "headline": "Minimize sensitive OpenTelemetry data before relying on downstream redaction", "description": "The simplest exposure to avoid is information the pipeline never needed to collect.", "abstract": "The simplest exposure to avoid is information the pipeline never needed to collect.", "articleBody": "The simplest exposure to avoid is information the pipeline never needed to collect.\nSource facts\nOpenTelemetry’s sensitive-data guidance recommends collecting only information serving an observability purpose, avoiding personal data unless necessary, and considering aggregation or anonymization. It describes attribute removal, transformation, and redaction approaches, while emphasizing review of collected attributes. The source treats minimization as an initial design decision rather than merely a final export filter.\nSource: OpenTelemetry documentation — Handling sensitive data.\nApplicability\nReview necessary telemetry collection and supported attribute-removal or transformation options in the sensitive-data guide.\nDSE recommendation\nDSE recommends inventorying attributes, log bodies, resource metadata, and destinations with the application owner. Remove unnecessary collection at the earliest practical point. For required sensitive information, define access, retention, and a documented transformation policy. Keep unexpected-field detection in the review so a new application release cannot quietly reintroduce data. Test changes with synthetic values and inspect every relevant signal type, including diagnostic outputs that might bypass the normal backend path.\nVerification\nIn a nonproduction pipeline, send representative synthetic sensitive fields through the intended configuration. Inspect receiver-side assumptions, processed output, and final destination behavior without using real customer information. Confirm required operational context remains usable and that unexpected attributes receive the documented treatment before enabling the policy broadly. Retain the synthetic input/output field inventory with the transformation policy. Ask the data owner to approve both necessary retained context and the handling of a newly introduced unexpected field before the policy is applied to real telemetry.\nOfficial reference\nOpenTelemetry documentation — Handling sensitive data. Reviewed October 20, 2026.", "datePublished": "2026-10-20T18:15:49+00:00", "dateModified": "2026-10-20T18:34:34+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/minimize-sensitive-opentelemetry-data-before-relying-on-downstream-redaction/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Minimize sensitive OpenTelemetry data before relying on downstream redaction" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 254, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "OpenTelemetry documentation — Handling sensitive data", "url": "https://opentelemetry.io/docs/security/handling-sensitive-data/" } } ] } }