This document records a public security review of Jaeger for the OpenSSF
Best Practices Gold security_review criterion. The criterion requires a
security review within the last five years that considers the project's security
requirements and security boundary.
This review is a project security review, not a third-party penetration test. Historical third-party audit evidence remains available in the jaegertracing/security-audits repository.
| Field | Value |
|---|---|
| Review date | 2026-05-17 |
| Reviewed branch | main |
| Review type | Public project security review |
| Reviewers | Jaeger maintainers (led by @jkowall), with public review by the jaegertracing/jaeger-maintainers team on the tracking pull request. |
| Tracking issue | jaegertracing#8485 |
| Parent tracker | jaegertracing#8481 |
| Sensitive findings | Not disclosed in this document; report and handle them through SECURITY.md. |
- Security Policy, including vulnerability reporting, dependency policy, and scanner-report guidance.
- Threat Model, including trust boundaries and primary threat scenarios.
- Security Architecture, including TLS, certificate verification, input validation, hardening, and credential management.
- Security Assurance Case, including security goals, design principles, weakness mitigations, and controls.
- CNCF TAG Security Self-Assessment, including project scope, security goals, and self-assessed weaknesses.
- Release Verification, including artifact and signature verification guidance.
- Current OpenSSF Best Practices Gold evidence in OpenSSF Best Practices Gold Evidence.
- Security-relevant CI workflows, including
codeql.yml,dependency-review.yml,scorecard.yml, andfossa.yml.
| Requirement | Review notes |
|---|---|
| Trace data confidentiality | Jaeger may process sensitive trace data. Operators are expected to enable TLS or mTLS on external and internal communication paths, configure access control for Query/UI, and avoid tracing secrets or personally identifiable information. |
| Trace data integrity | TLS/mTLS, certificate verification, structured OTLP/protobuf inputs, and authenticated storage connections protect trace data in transit and reduce tampering risk across component boundaries. |
| Availability | The threat model identifies span flooding and storage pressure as availability risks. Sampling, rate limiting, buffering, storage isolation, and deployment-level quotas remain the primary mitigations. |
| Access control | Query/UI access depends on operator-configured authentication mechanisms such as bearer tokens, OAuth2, and Kerberos, with authorization enforced at the deployment layer (for example, RBAC in Kubernetes or reverse-proxy policy). Storage credentials should be scoped to the minimum privileges needed by each component. |
| Secure transport and cryptography | Jaeger supports TLS 1.2 and TLS 1.3. Certificate verification is enabled when TLS is configured, and insecure modes require explicit operator configuration. |
| Input validation | Jaeger uses structured protocols such as OTLP, gRPC, HTTP, and protobuf. Message-size limits, schema-aware parsing, and storage-client query construction reduce injection and resource-exhaustion risk. |
| Credential handling | Credentials, TLS keys, certificates, tokens, and storage passwords are supplied through configuration, environment variables, or external secret-management systems rather than hardcoded in the binary. |
| Vulnerability handling | Vulnerabilities are reported privately through GitHub Security Advisories or encrypted public channels. Continuous code scanning is performed by codeql.yml, and public scanner reports are expected to be analyzed for applicability before disclosure. |
| Supply-chain and release integrity | The project uses code review, DCO, CI, dependency scanning (dependency-review.yml, scorecard.yml, and fossa.yml), hardened GitHub Actions workflows, signed releases, SBOM generation, and documented release-verification procedures. |
The reviewed security boundary includes Jaeger-owned binaries, services, configuration handling, public APIs, storage clients, official release artifacts, and official container images.
The boundary does not include instrumented applications, OpenTelemetry SDKs, external identity providers, browser environments, Kubernetes clusters, network infrastructure, or the internal implementation of external storage systems. Jaeger still has security obligations where it accepts data from or connects to those systems.
| Boundary | Description | Primary controls reviewed |
|---|---|---|
| Instrumented application to Collector | Applications and SDKs submit untrusted telemetry to Jaeger. | TLS/mTLS, structured telemetry formats, schema validation, size limits, sampling, and rate limiting. |
| Collector or Ingester to storage | Jaeger writes trace data to configured storage backends. | TLS, storage authentication, scoped credentials, and backend-specific client libraries. |
| Storage to Query service | Query reads trace data from storage and exposes it through APIs and UI. | TLS, authenticated storage access, read-oriented credentials where supported, and parameterized or client-mediated queries. |
| Query/UI to users | Users access trace data through Jaeger APIs and browser UI. | Operator-configured authentication, authorization, RBAC-capable deployments, TLS, and guidance to avoid storing secrets in traces. |
| Project source to release artifacts | Source changes become binaries, images, charts, and release metadata. | Code review, CI, dependency scanning, DCO, signed releases, SBOMs, and release-verification documentation. |
- The documented security requirements cover confidentiality, integrity, availability, access control, secure transport, credential handling, vulnerability handling, supply-chain controls, and release integrity.
- The documented trust boundaries cover telemetry ingestion, internal component-to-storage communication, Query/UI access, and source-to-release delivery.
- Existing public documentation provides linkable evidence for the security boundary and requirements considered by this review.
- No sensitive vulnerability details are disclosed in this public summary. Any vulnerability discovered during future review work must be reported and handled through SECURITY.md.
The OpenSSF Gold security_review evidence should point at this document.
Separate Gold workstream items remain tracked outside this review, including
technical evidence for hardened site headers, hardening, coverage, reproducible
builds, dynamic analysis, and newcomer-task availability.
This review should be refreshed within five years or sooner after a major security-boundary change, such as a new externally reachable service, a new storage security model, or a major release-process change.