Security & Compliance
Last Updated: September 5, 2026
Overview and Contractual Scope
OpenObserve provides software and services for logs, metrics, and traces. This page describes security considerations and available capabilities; implementation depends on the product edition, supported release, deployment model, configuration, and purchased services. It is not a warranty, a guarantee against incidents or data loss, or a promise that every listed capability is enabled in every deployment. Except for the express vulnerability-disclosure safe harbor below, this overview does not create additional contractual commitments. Binding security and processing obligations are those expressly set out in the applicable agreement and Data Processing Agreement (DPA); the SLA governs availability and support commitments. This overview does not diminish obligations under applicable law or an applicable signed agreement.
Supported Projects and Versions
OpenObserve consists of the open-source core, OpenObserve Enterprise, and OpenObserve Cloud. Public security fixes are made available for the current stable release; a fix may require upgrading. Pre-release builds, the main development branch, and release candidates receive best-effort attention. Paid support entitlements and any broader release-support window are governed by the applicable agreement. Customers operating their own deployments are responsible for installing updates and maintaining supported configurations.
Security Architecture and Access
Available capabilities include TLS-protected connections, scoped ingestion credentials, organization-level separation, role-based permissions, identity-provider integration, configurable retention, and data-processing pipelines. Availability varies by edition and configuration; consult the applicable product documentation before relying on a capability. Customers should enable appropriate authentication, access restrictions, encryption, credential rotation, and data minimization for their deployment.
Storage-layer encryption, key management, network controls, backup options, and infrastructure isolation depend on the hosting provider and deployment architecture. Support for a cloud provider or integration does not mean that OpenObserve uses that provider to process every customer's data. OpenObserve does not guarantee that customer configurations or third-party infrastructure meet a particular compliance framework.
Availability, Backup, and Recovery
The applicable Service Level Agreement provides a 99.8% monthly availability commitment, subject to its definitions, exclusions, claim requirements, and remedies, for eligible OpenObserve Cloud, Single-Tenant Hosted, and OpenObserve-managed BYOC deployments. It does not provide an uptime commitment for customer-operated Self-Hosted deployments.
Planned maintenance and emergency maintenance are governed by the SLA, including its usual 48-hour advance communication for scheduled maintenance. This overview does not promise zero-downtime changes, uninterrupted operation, a fixed recovery time, a fixed recovery point, or a particular storage durability percentage. Redundancy, monitoring, and recovery arrangements depend on the purchased deployment and configuration. Any specific recovery objective or backup obligation must be expressly agreed in writing.
Retention determines the data available through the service; it is not a promise of indefinite archival or a customer-restorable backup. Customers should arrange independent copies and recovery procedures where required for their business. For BYOC and Self-Hosted deployments, customers remain responsible for the infrastructure, storage lifecycle policies, capacity, credentials, and other components allocated to them by the applicable agreement.
Compliance Materials and Physical Security
Contact security@openobserve.ai to request available security assurance materials, including any applicable SOC 2 report or certification documentation, subject to confidentiality and access restrictions. A SOC 2 report is an independent attestation report, not a certification. Its reporting period, examined system, and stated scope control; no report or certification should be assumed to cover all products, providers, locations, or customer configurations. This page makes no representation of ISO certification or suitability for a regulated use case absent applicable supporting documentation and express agreement.
Hosting providers operate their physical facilities and infrastructure controls. Their certifications do not automatically certify OpenObserve or a customer's deployment. Customer-controlled infrastructure and facilities remain the customer's responsibility. Customers should evaluate the applicable provider's current assurance materials and their own regulatory obligations.
Personnel, Development, and Vulnerability Management
Security measures are selected according to the services operated and the risks involved. Relevant practices include access restrictions, personnel confidentiality obligations, access reviews, security awareness, change review, dependency and vulnerability assessment, and incident response. Any binding technical and organizational measures are set out in the applicable DPA or signed security schedule.
Security findings are assessed and prioritized according to severity, exploitability, available mitigations, and affected deployments. Fixes may be delivered through updates or supported upgrades. This overview does not establish a universal patch deadline, penetration-testing frequency, audit-log retention period, or backport obligation. Release notes and applicable security advisories provide information about published fixes.
Data Location and Retention
Customers select among the storage regions available for their service, as reflected in their order or deployment configuration. OpenObserve does not relocate stored Customer Data to another region without customer instructions or agreement. Self-Hosted customers control their own data location. Customer-selected storage location is distinct from account administration, support information, or other processing described in the applicable DPA and Privacy Policy.
Logs, metrics, and traces are not necessarily personal data, but customers may submit information about identifiable individuals. Customers are responsible for lawful collection, minimization, access controls, and appropriate retention settings. Where OpenObserve processes personal data on a customer's behalf, the DPA applies. International-transfer safeguards apply only where actual processing requires them under applicable law. Available export data follows applicable retention settings; expiry, customer deletion, or storage lifecycle rules can make data unavailable. Deletion, backup expiry, and assistance obligations are governed by the applicable agreement and DPA.
Incident Response
OpenObserve evaluates reported incidents, investigates and takes containment or remediation measures appropriate to the circumstances. Where an incident triggers notification duties under the applicable DPA, signed agreement, or law, OpenObserve will notify the relevant customer without undue delay and within any legally required period. Updates may be provided as material information becomes available, subject to legal, confidentiality, and investigation restrictions. This overview does not create a separate 24-hour notification deadline or a fixed reporting cadence.
Shared Responsibility and Recommended Configuration
OpenObserve's operational responsibilities depend on whether it operates the deployment. The SLA describes the allocation for Cloud, Single-Tenant Hosted, BYOC, and Self-Hosted services. Customers should:
- Restrict access, protect credentials, and configure appropriate authentication and network controls.
- Classify telemetry, minimize sensitive fields, and configure retention and deletion appropriately.
- Maintain capacity, storage policies, updates, and backups for customer-operated components.
- Review applicable security advisories and report suspected vulnerabilities or account compromise promptly.
- Determine whether the product and configuration satisfy their own legal, regulatory, and business requirements.
Vulnerability Disclosure
Reporting Security Issues
We encourage responsible disclosure of security vulnerabilities. Please use GitHub Security Advisory as the primary reporting channel, or email as the secondary channel:
-
GitHub Security Advisory (Primary)
- Navigate to our GitHub repository
- Go to Security → "Report a vulnerability"
- Submit a private advisory
-
Email (Secondary): security@openobserve.ai
- Use PGP encryption if available
- Include "SECURITY" in the subject line
What to Include in Reports
- Clear description of the vulnerability and its impact
- Affected components (repository, package, service)
- Version numbers and environment details
- Reproducible steps or proof of concept (non-destructive)
- CVSS v3.1 score estimation (if available)
- Any relevant logs, screenshots, or traces
Vulnerability Scope
In Scope
- Remote code execution, injection, authentication/authorization bypass, data exposure
- Logic flaws causing privilege escalation or data integrity issues
- Supply chain risks in our build/release artifacts
- Default configuration issues that materially reduce security
- OpenObserve Cloud issues (tenant isolation, API auth, data access)
Out of Scope
- Vulnerabilities requiring physical access or stolen credentials
- Denial of service from volumetric attacks without a product flaw
- Best-practice recommendations without a concrete vulnerability
- Issues only affecting unsupported/End-of-Life versions
- Vulnerabilities in third-party dependencies with no exploitable impact in OpenObserve's usage (we'll upstream where appropriate)
Responsible Testing Guidelines
Obtain OpenObserve's prior written authorization before testing any OpenObserve-operated service or infrastructure, and stay within the approved scope and conditions. The vulnerability categories above identify reportable issues; listing them does not authorize testing. You may test a Self-Hosted deployment you own or are authorized by its owner to test, subject to applicable licenses and law, provided that testing does not target OpenObserve-operated or other third-party systems. Unsolicited reports of issues discovered without prohibited testing remain welcome.
- Use test or your own accounts/data only; avoid accessing others' data
- Avoid actions that degrade service for other users (no volumetric/DoS)
- Limit testing on OpenObserve Cloud to non-production accounts and data
- Do not run automated scanners against OpenObserve Cloud without prior coordination
- Respect rate limits and legal boundaries in your jurisdiction
- If you discover sensitive data exposure, stop testing immediately and report privately
Coordinated Disclosure
We request a 90-day disclosure window by default. We may request an extension for complex fixes or cross-vendor coordination. We publish advisories via GitHub Security Advisories (GHSA) and CVE where applicable, crediting reporters who wish to be named.
Safe Harbor
We support good-faith research. If you:
- Follow this policy
- Avoid privacy violations, data destruction, and service disruption
- Report vulnerabilities promptly and do not abuse them
We will not pursue or support legal action against you. This safe harbor does not cover unlawful actions, uncoordinated testing on production systems, or use of data beyond what's necessary to demonstrate the issue.
Recognition
- Credit in security advisories (with permission)
- Inclusion in our security hall of fame
- Discretionary thank-you swag for significant findings
Bug Bounty Program
At this time, we do not operate a public bug bounty program. We are grateful for responsible disclosures and, with your consent, will credit you in release notes or advisories. From time to time we may offer thank-you swag. If a bounty program is introduced in the future, we will update this policy accordingly.
Reporting Fraud & Abuse
When to Report:
Please report the following types of incidents immediately:
- Phishing attempts using OpenObserve branding
- Unauthorized use of OpenObserve accounts or infrastructure
- Suspicious activity on OpenObserve Cloud affecting your organization
- Copyright or trademark infringement
- Abuse of OpenObserve services for malicious purposes
- Spam or harassment originating from OpenObserve systems
- Account abuse or suspicious activity affecting OpenObserve Cloud
How to Report
- Email: security@openobserve.ai
- For active incidents: Include "URGENT" in the subject line
- For OpenObserve Cloud: Include affected organization ID and timestamps
What to Include
- Description of the fraudulent or abusive activity
- Screenshots or evidence of the abuse
- Timestamps and relevant URLs
- Account information if known
- Any communications received
Our Response
- Initial acknowledgment: As reasonably practicable
- Investigation: We will investigate all credible reports
- Action: Appropriate measures including account suspension, legal action, or law enforcement referral
- Follow-up: Status updates for the reporter when possible
Zero Tolerance Policy
- OpenObserve maintains a zero-tolerance policy for:
- Use of our platform for illegal activities
- Attempts to compromise other users' data
- Distribution or execution of malware or malicious code, excluding authorized handling of inert security telemetry in accordance with the Acceptable Use Policy
- Violation of our Terms of Service or Acceptable Use Policy
Security Contacts
- Primary: GitHub Security Advisory via "Report a vulnerability"
- Secondary: security@openobserve.ai
- Abuse/Fraud: security@openobserve.ai
- General Support: support@openobserve.ai