Add security documentation for OpenSSF Silver badge

CONTRIBUTING.md

@@ -138,6 +138,8 @@ import (
 
 ## Testing guidelines
 
+**Policy**: All new functionality must include tests. Bug fixes should include regression tests that would have caught the bug, where feasible. Pull requests without adequate test coverage will not be merged.
+
 We strive to maintain as high code coverage as possible. The current repository limit is set at 95%,
 with some exclusions discussed below.
 

SECURITY-INSIGHTS.yml

@@ -1,8 +1,8 @@
 header:
   schema-version: 1.0.0
-  last-updated: '2023-10-20'
-  last-reviewed: '2023-10-20'
-  expiration-date: '2024-10-20T01:00:00.000Z'
+  last-updated: '2026-01-16'
+  last-reviewed: '2026-01-16'
+  expiration-date: '2027-01-16T01:00:00.000Z'
   project-url: https://github.com/jaegertracing/jaeger/
   changelog: https://github.com/jaegertracing/jaeger/blob/main/CHANGELOG.md
   license: https://github.com/jaegertracing/jaeger/blob/main/LICENSE
@@ -32,6 +32,7 @@ security-artifacts:
   self-assessment:
     self-assessment-created: true
     evidence-url:
+    - https://tag-security.cncf.io/assessments/projects/jaeger/self-assessment/
     - https://github.com/cncf/tag-security/blob/main/assessments/projects/jaeger/self-assessment.md
 security-testing:
 - tool-type: sca

SECURITY.md

@@ -121,6 +121,15 @@ oF+qZY4uEvqFvYo8
 [mailing-list]: https://groups.google.com/forum/#!forum/jaeger-tracing
 [slack-room]: https://cloud-native.slack.com/archives/CGG7NFUJ3
 
-## Securing a Jaeger installation
 
-If you are looking to secure your Jaeger installation, check out our documentation on the topic: [Securing Jaeger Installation](https://www.jaegertracing.io/docs/latest/security/).
+## Security Documentation
+
+For more detailed security information, see:
+
+| Document | Description |
+|----------|-------------|
+| [Threat Model](docs/security/threat-model.md) | Threat model and trust boundaries |
+| [Assurance Case](docs/security/assurance-case.md) | Security assurance case |
+| [Security Architecture](docs/security/architecture.md) | TLS and cryptographic practices |
+| [Self-Assessment](docs/security/self-assessment.md) | CNCF TAG Security self-assessment |
+| [Release Verification](docs/security/verifying-releases.md) | Release signature verification |

docs/security/architecture.md

@@ -0,0 +1,66 @@
+# Jaeger Security Architecture
+
+This document outlines the security architecture of Jaeger, focusing on cryptographic practices, input validation, and system hardening.
+
+## TLS and Cryptographic Practices
+
+Jaeger supports TLS for all its network communications, including span ingestion, internal component communication, and access to the Query API and UI.
+
+### TLS Configuration
+
+TLS can be configured for both clients and servers across all Jaeger components (Collector, Query, Ingester, Agent).
+
+- **Supported TLS Versions**: Jaeger can be configured to use TLS 1.2 and 1.3, and these are the only versions that should be used in production. Users should configure the minimum supported version as TLS 1.2 or higher using the `--tls.min-version` flag (or corresponding YAML configuration), with TLS 1.3 recommended where available. While TLS 1.0 and 1.1 may still be technically supported for legacy interoperability, they are deprecated, have known security weaknesses, and **must not be enabled in production environments**.
+- **Cipher Suites**: A custom list of allowed cipher suites can be configured to ensure only strong cryptographic algorithms are used.
+- **Certificate Management**:
+    - **CA Certificate**: Can be provided to verify the server's or client's certificate.
+    - **Server Certificate and Key**: Required for enabling TLS on servers.
+    - **Client Authentication (mTLS)**: Jaeger supports mutual TLS, requiring clients to provide a valid certificate for authentication.
+- **Reloading Certificates**: Jaeger supports hot-reloading of TLS certificates and keys from the filesystem without restarting the service, controlled by a configurable reload interval.
+
+### Secure Defaults
+
+- **Certificate Verification**: When TLS is enabled, certificate verification is performed by default.
+- **Insecure Communication**: Users must explicitly set `insecure: true` or `insecure_skip_verify: true` to bypass security controls, which is strongly discouraged for production environments.
+
+## Input Validation
+
+Jaeger performs strict input validation to prevent injection attacks and ensure system stability.
+
+- **OTLP and Protobuf**: Jaeger primarily uses structured data formats like OTLP (via gRPC and HTTP) and Protobuf for internal communication. These formats provide inherent protection against many common injection vulnerabilities.
+- **Schema Validation**: Inbound spans are validated against the defined schemas.
+- **Size Limits**:
+    - **gRPC Message Size**: Limits are enforced on the maximum size of incoming gRPC messages.
+    - **HTTP Request Size**: Limits are enforced for HTTP-based ingestion.
+- **Storage Queries**: Queries to storage backends (Elasticsearch, Cassandra, etc.) are constructed using parameterized queries or dedicated client libraries that prevent injection.
+
+## System Hardening
+
+Jaeger is designed to be deployed in a hardened manner.
+
+### Container Security
+
+- **Minimal Base Images**: Jaeger's official Docker images are built using minimal base images like `alpine` or `scratch` to reduce the attack surface.
+- **Non-Root User**: Containers are designed to run as a non-privileged user where possible.
+
+### Dependency Management
+
+- **Vulnerability Scanning**: The project uses Dependabot for automated dependency monitoring and daily vulnerability scans.
+- **Software Bill of Materials (SBOM)**: An SBOM is generated for each release to provide transparency into the included components.
+
+### Secure Build Pipeline
+
+- **Signed Commits**: All contributions are required to follow the Developer Certificate of Origin (DCO) and should be signed.
+- **GitHub Actions Security**: The build pipeline uses security features like `harden-runner` to monitor and restrict network access during the build process.
+- **Release Signing**: All release artifacts and Git tags are GPG-signed by the maintainers.
+
+## Credential Management
+
+- **No Hardcoded Credentials**: Jaeger does not contain any hardcoded credentials. All secrets (passwords, tokens, etc.) must be provided via environment variables, command-line flags, or configuration files.
+- **Environment Variables**: Recommended for providing sensitive information in containerized environments.
+- **Secure Storage**: Users are encouraged to use secure secret management systems (like Kubernetes Secrets or HashiCorp Vault) to manage Jaeger's credentials.
+
+## References
+
+- [Securing Jaeger Installation](https://www.jaegertracing.io/docs/latest/security/)
+- [OpenTelemetry TLS Configuration](https://github.com/open-telemetry/opentelemetry-collector/blob/main/config/configtls/README.md)

docs/security/assurance-case.md

@@ -0,0 +1,165 @@
+# Jaeger Security Assurance Case
+
+This document provides a security assurance case for the Jaeger project, demonstrating how security requirements are met through the application of secure design principles and mitigation of common implementation weaknesses.
+
+## Table of Contents
+
+- [Threat Model Summary](#threat-model-summary)
+- [Trust Boundaries](#trust-boundaries)
+- [Secure Design Principles](#secure-design-principles)
+- [Common Weakness Mitigations](#common-weakness-mitigations)
+- [Security Controls](#security-controls)
+
+## Threat Model Summary
+
+Jaeger is a distributed tracing system that collects, stores, and visualizes trace data from instrumented applications. The primary security concerns are:
+
+1. **Data Confidentiality**: Trace data may contain sensitive information (service names, endpoints, timing data)
+2. **Data Integrity**: Trace data should not be tampered with
+3. **Availability**: The tracing infrastructure should not become a DoS vector
+4. **Access Control**: Only authorized users should access trace data
+
+### Threat Actors
+
+| Actor | Motivation | Capability |
+| -- | -- | -- |
+| Malicious Internal Service | DoS, data injection | Network access to collector |
+| External Attacker | Data exfiltration, reconnaissance | Varies based on deployment |
+| Unauthorized User | Access to sensitive traces | UI/API access |
+
+For detailed threat analysis, see [threat-model.md](threat-model.md).
+
+## Trust Boundaries
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│                    External Network                              │
+│  ┌──────────────┐                                               │
+│  │ Instrumented │                                               │
+│  │ Applications │ ─────────── BOUNDARY 1 ───────────────────┐   │
+│  │ (OTel SDK)   │                                           │   │
+│  └──────────────┘                                           ▼   │
+│                                                    ┌────────────┤
+│                                                    │  Jaeger    │
+│                                                    │  Collector │
+│                                                    └─────┬──────┤
+│                                                          │      │
+│                              ─────── BOUNDARY 2 ─────────┤      │
+│                                                          ▼      │
+│                                                    ┌────────────┤
+│                                                    │  Storage   │
+│                                                    │  Backend   │
+│                                                    └─────┬──────┤
+│                                                          │      │
+│                              ─────── BOUNDARY 3 ─────────┤      │
+│                                                          ▼      │
+│  ┌──────────────┐                                 ┌────────────┤
+│  │   Users      │ ─────────── BOUNDARY 4 ────────▶│   Jaeger   │
+│  │  (Browser)   │                                 │   Query/UI │
+│  └──────────────┘                                 └────────────┤
+└─────────────────────────────────────────────────────────────────┘
+```
+
+| Boundary | From | To | Security Controls |
+| -- | -- | -- | -- |
+| 1 | OTel SDK | Collector | TLS/mTLS, rate limiting |
+| 2 | Collector | Storage | TLS, authentication |
+| 3 | Storage | Query | TLS, authentication |
+| 4 | Users | Query/UI | TLS, bearer tokens, RBAC |
+
+## Secure Design Principles
+
+### Economy of Mechanism
+
+- **Implementation**: Jaeger leverages established protocols (OTLP, gRPC) rather than custom implementations
+- **Evidence**: Uses OpenTelemetry Collector framework for core functionality
+
+### Fail-Safe Defaults
+
+- **Implementation**: TLS certificate verification is enabled by default when TLS is configured
+- **Evidence**: `insecure_skip_verify` must be explicitly set to disable verification
+- **Note**: TLS itself is opt-in to simplify initial testing and non-production deployments; for all production deployments, TLS (preferably mTLS where supported) MUST be enabled on all external and inter-service connections.
+
+### Complete Mediation
+
+- **Implementation**: All API endpoints require passing through authentication when configured
+- **Evidence**: Bearer token and RBAC support at Query service level
+
+### Open Design
+
+- **Implementation**: All source code is publicly available on GitHub
+- **Evidence**: Apache 2.0 license, public security documentation
+
+### Separation of Privilege
+
+- **Implementation**: Different components (Collector, Query) can be deployed with different access levels
+- **Evidence**: Collector only writes, Query only reads from storage
+
+### Least Privilege
+
+- **Implementation**: Storage credentials can be scoped to minimum required permissions
+- **Evidence**: Separate read/write keyspaces supported for Cassandra
+
+### Least Common Mechanism
+
+- **Implementation**: Admin endpoints separated from data endpoints
+- **Evidence**: Separate ports for admin, metrics, and data APIs
+
+### Psychological Acceptability
+
+- **Implementation**: Security is configurable via standard YAML configuration
+- **Evidence**: Consistent TLS configuration across all components
+
+## Common Weakness Mitigations
+
+### OWASP Top 10 / CWE Top 25 Coverage
+
+| Weakness | Mitigation |
+| -- | -- |
+| **Injection (CWE-89, CWE-79)** | Structured data formats (protobuf/OTLP), parameterized storage queries |
+| **Broken Authentication (CWE-287)** | Bearer tokens, OAuth2, mTLS support |
+| **Sensitive Data Exposure (CWE-200)** | TLS for all communications, no credentials in traces |
+| **XML External Entities** | Not applicable - uses protobuf/JSON |
+| **Broken Access Control (CWE-284)** | RBAC support in Query service |
+| **Security Misconfiguration** | Secure defaults where possible, configuration validation |
+| **Cross-Site Scripting (CWE-79)** | UI built with React (auto-escaping), CSP headers |
+| **Insecure Deserialization (CWE-502)** | Uses protobuf with schema validation |
+| **Insufficient Logging** | Comprehensive logging in all components |
+| **SSRF (CWE-918)** | No user-controlled URLs in backend requests |
+
+### Go-Specific Security
+
+| Practice | Implementation |
+| -- | -- |
+| Memory Safety | Go's inherent memory safety |
+| Integer Overflow | Go's bounds checking |
+| Race Conditions | Go's race detector in CI |
+| Dependency Security | Dependabot, daily vulnerability scans |
+
+## Security Controls
+
+### Build and Release
+
+| Control | Implementation |
+| -- | -- |
+| Signed Commits | DCO required for all contributions |
+| Signed Releases | GPG-signed tags and artifacts |
+| SBOM | Generated for each release |
+| Container Security | Minimal base images (alpine/scratch) |
+| Supply Chain | Harden-Runner, pinned dependencies |
+
+### Runtime
+
+| Control | Implementation |
+| -- | -- |
+| TLS/mTLS | Configurable for all connections |
+| Authentication | Bearer tokens, OAuth2, Kerberos |
+| Rate Limiting | Configurable at collector |
+| Input Validation | OTLP schema validation, size limits |
+
+## References
+
+- [SECURITY.md](../../SECURITY.md) - Vulnerability reporting
+- [Threat Model](threat-model.md) - Detailed threat analysis
+- [Security Architecture](architecture.md) - Cryptographic practices
+- [Securing Jaeger Installation](https://www.jaegertracing.io/docs/latest/security/)

docs/security/self-assessment.md

@@ -0,0 +1,48 @@
+# Jaeger Self-Assessment
+
+This document is a local copy of the Jaeger project's security self-assessment, originally conducted following the CNCF TAG Security assessment process.
+
+## Project Overview
+
+Jaeger is a distributed tracing system originally developed at Uber Technologies and now a graduated project within the Cloud Native Computing Foundation (CNCF).
+
+## Security Profile
+
+| Attribute | Value |
+| -- | -- |
+| Security Policy | [SECURITY.md](https://github.com/jaegertracing/jaeger/blob/main/SECURITY.md) |
+| Threat Model | [threat-model.md](threat-model.md) |
+| Assurance Case | [assurance-case.md](assurance-case.md) |
+| Security file | [SECURITY.md](https://github.com/jaegertracing/jaeger/blob/main/SECURITY.md) |
+
+## Self-Assessment Summary
+
+### Secure Design Principles
+
+Jaeger adheres to established secure design principles:
+- **Economy of Mechanism**: Uses standard protocols (OTLP, gRPC).
+- **Fail-Safe Defaults**: TLS verification enabled by default.
+- **Open Design**: Fully open-source and publicly documented.
+
+### Trust Boundaries
+
+Trust boundaries exist between instrumented applications and the collector, between the collector and storage, and between the query service and users. Each boundary is protected by TLS and authentication controls.
+
+### Security Testing
+
+- **Unit/Integration Tests**: Comprehensive test suite with high coverage requirements.
+- **Static Analysis**: Uses `golangci-lint` and `gosec`.
+- **Dependency Scanning**: Daily scans via Dependabot.
+- **Vulnerability Reporting**: Formal process documented in `SECURITY.md`.
+
+## Metadata
+
+| Attribute | Details |
+| -- | -- |
+| Last Updated | 2026-01-16 |
+| Status | Completed |
+| Assessment Process | CNCF TAG Security Self-Assessment |
+
+## Vulnerability Handling
+
+Refer to [SECURITY.md](https://github.com/jaegertracing/jaeger/blob/main/SECURITY.md) and [Report Security Issue](https://www.jaegertracing.io/report-security-issue/).