mirror of
https://github.com/openobserve/openobserve.git
synced 2026-11-05 08:09:22 +00:00
107 lines
4.9 KiB
Markdown
107 lines
4.9 KiB
Markdown
# Security Policy
|
||
|
||
Thank you for helping keep OpenObserve and our users safe. This document explains how to report security vulnerabilities, what’s in scope, and what you can expect from us.
|
||
|
||
## Supported Projects & Versions
|
||
|
||
OpenObserve is composed of multiple projects and distributions:
|
||
|
||
* **OpenObserve (OSS)** – the open-source core in this repo
|
||
* **OpenObserve Enterprise** – commercial features built on top of OSS
|
||
* **OpenObserve Cloud** – our hosted service
|
||
|
||
We provide security fixes for the **current stable release**. Pre-release builds (e.g., `main`, release candidates) are supported on a best‑effort basis.
|
||
|
||
## Reporting a Vulnerability (Preferred)
|
||
|
||
Please **privately disclose** suspected vulnerabilities to our security team:
|
||
|
||
1. **GitHub → Security → “Report a vulnerability”** (opens a private advisory with maintainers).
|
||
2. Or email **[security@openobserve.ai](mailto:security@openobserve.ai)**.
|
||
|
||
### What to Include
|
||
|
||
* A clear description of the issue and potential impact
|
||
* Exact components affected (repo, package, service)
|
||
* Version(s), commit hash(es), and environment details
|
||
* Minimal, reproducible steps or PoC (non-destructive)
|
||
* Any logs, screenshots, or traces that help reproduce
|
||
* Proposed severity (CVSS v3.1 vector, if available)
|
||
|
||
We’re happy to coordinate on disclosure timelines when your research impacts other vendors or ecosystems.
|
||
|
||
## Coordinated Disclosure
|
||
|
||
* We request a **90‑day** disclosure window by default. We may extend this 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.
|
||
|
||
## Scope
|
||
|
||
**In scope** (examples):
|
||
|
||
* Remote code execution, injection, authN/authZ 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** (examples):
|
||
|
||
* 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
|
||
|
||
Please:
|
||
|
||
* 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.
|
||
|
||
## Safe Harbor
|
||
|
||
We support good‑faith research. If you:
|
||
|
||
* Follow this policy,
|
||
* Avoid privacy violations, data destruction, and service disruption, and
|
||
* 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 & Bounty
|
||
|
||
At this time we **do not operate a public bug bounty program**. We’re 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, we will update this policy accordingly.
|
||
|
||
## Security Updates & SBOM
|
||
|
||
* We proactively update dependencies and ship security fixes in patch releases.
|
||
* We publish release notes highlighting security‑relevant changes.
|
||
* SBOMs for supported releases are available in this Git repository.
|
||
|
||
## Build & Supply‑Chain Integrity
|
||
|
||
We follow industry best practices:
|
||
|
||
* Reproducible builds and pinned dependencies where feasible
|
||
* **Version pinning** for all dependencies and build tools to ensure deterministic and verifiable builds
|
||
* Use of **distroless container images** to reduce the attack surface
|
||
* Public verification of builds via **GitHub Actions logs** – all release builds are executed through GitHub Actions, and logs are publicly available in this repository’s Actions tab to allow independent verification of the build process.
|
||
|
||
## Reporting Abuse or Fraud (Cloud)
|
||
|
||
For phishing, account abuse, or suspicious activity affecting OpenObserve Cloud, contact **[abuse@openobserve.ai](mailto:abuse@openobserve.ai)**. For active incidents, include urgency in the subject.
|
||
|
||
## Security Contact
|
||
|
||
* Primary: **[security@openobserve.ai](mailto:security@openobserve.ai)**
|
||
* Backup: **security reports via GitHub → Security → “Report a vulnerability”**
|
||
|
||
We appreciate your help in keeping OpenObserve safe for everyone.
|