# Security Policy

**Operator:** Ekravo  
**Last updated:** 28 October 2026  
**Canonical URL:** https://ekravo.com/security (HTML), with /security.md as Markdown alternate (also linked from the [`/ai`](https://ekravo.com/ai) manifest as `trust.securityPolicy`)

This document describes how to report security vulnerabilities, what good-faith research we permit, and a factual summary of technical controls. It supplements — and does not replace — our [Privacy Policy](https://ekravo.com/privacy), [Terms of Service](https://ekravo.com/terms), and [Trust Center](https://ekravo.com/trust). Security research must comply with this policy and the [acceptable use](https://ekravo.com/terms#acceptable-use) rules in our Terms. **This policy is not a contract and may be updated from time to time.** If you are unsure whether a test is permitted, contact us before testing.

## Quick reference

| If the user needs… | Send them to… |
|---|---|
| Report a security vulnerability | [security@ekravo.com](mailto:security@ekravo.com) (this document) |
| Privacy, data rights, retention, or breach questions | [privacy@ekravo.com](mailto:privacy@ekravo.com) and [Privacy Policy](https://ekravo.com/privacy) |
| Subprocessors, security controls, vendor questionnaires, DPA | [Trust Center](https://ekravo.com/trust) · [dpa@ekravo.com](mailto:dpa@ekravo.com) |
| Terms of service or acceptable use | [Terms of Service](https://ekravo.com/terms) |
| Account help (not a product vulnerability) | [support@ekravo.com](mailto:support@ekravo.com) |
| Outages or uptime (not security bugs) | [Status](https://ekravo.com/status) |

## Reporting a vulnerability

If you believe you have found a security issue in Ekravo, please report it responsibly.

**Preferred contact:** [security@ekravo.com](mailto:security@ekravo.com)

**Machine-readable contact (RFC 9116):** [/.well-known/security.txt](https://ekravo.com/.well-known/security.txt)

**Alternative:** [privacy@ekravo.com](mailto:privacy@ekravo.com) with the subject line `Security report` if you cannot reach the security inbox — we will route it promptly.

**Encrypted reports (optional):** If you need to send sensitive material encrypted, email us and we will provide a PGP key or alternate secure channel.

Please include:

- A clear description of the issue and the realistic impact
- Steps to reproduce, including URLs, request examples, or proof-of-concept where possible
- The affected component (production route, API surface, or repository path)
- Your assessment of severity (CVSS is welcome but not required)
- Whether you would like public credit when the issue is fixed

Redact personal data belonging to others. Use only the minimum access needed to demonstrate the issue. If your report involves personal data you do not own, tell us immediately so we can coordinate with affected users and our privacy team.

Do **not** open a public GitHub issue for security vulnerabilities.

## Scope

### In scope

Security issues in the following are **in scope** when reported in accordance with this policy:

- The production service at **ekravo.com** and first-party subdomains operated by Ekravo (including `/api`, `/v1`, and related API surfaces)
- The public website, OpenAI-compatible API, authentication flows used by CLI and Desktop clients, Code mode workspaces, team features, webhooks, file uploads, billing/credits, and account data handling described in our [Privacy Policy](https://ekravo.com/privacy)
- The private source repository that builds and deploys the production service

Use only **accounts and data you own**, unless we provide written permission or a dedicated test account.

### Out of scope

The following are **out of scope** for this policy (please report them to the relevant provider instead):

- Third-party services Ekravo integrates with (GitHub, model providers, payment processors, email providers, Cloudflare, etc.)
- Social engineering or phishing against Ekravo staff or users
- Physical security, office access, or supplier premises
- Unmaintained forks, unofficial deployments, or self-hosted instances not operated by Ekravo
- Issues with no demonstrated security impact (for example, missing best-practice headers without a plausible exploit path in our deployment)
- Vulnerabilities in dependencies already fixed in a newer supported release, without a demonstrable exploit path in our deployment

We may still accept out-of-scope reports privately, but they are not eligible for the coordinated disclosure commitments below.

## Safe harbor

We support **good-faith security research** that follows this policy. If you:

- Contact [security@ekravo.com](mailto:security@ekravo.com) before testing and follow the rules in [What not to test](#what-not-to-test) below
- Make a reasonable effort to avoid privacy violations, service degradation, and data destruction
- Do not access, modify, or exfiltrate data belonging to other users
- Give us a reasonable amount of time to investigate and remediate before public disclosure

…we will not pursue legal action against you for research that complies with this policy and our [Terms of Service acceptable-use rules](https://ekravo.com/terms#acceptable-use).

If you conduct security research **in good faith**, **within scope**, and **in compliance with this policy**, we will:

- Consider your research **authorised** with respect to Ekravo systems covered by this policy
- **Not** bring civil or criminal action against you, and **not** report you to law enforcement, for accidental or good-faith violations of this policy
- Work with you on coordinated disclosure

Safe harbor **does not** apply if you:

- Violate applicable law or our Terms
- Harm users or Ekravo operations beyond what is necessary to demonstrate the issue
- Access or exfiltrate other users' data
- Act in bad faith (extortion, public shaming before coordination, etc.)
- Test out-of-scope systems or accounts you do not own without our written permission

We cannot bind third parties. Research that affects another organisation's systems may not be covered.

## What not to test

Please do **not**:

- Run automated scanners that generate high request volume against production
- Attempt denial-of-service, load testing, or resource exhaustion attacks
- Brute-force credentials, session tokens, or API keys
- Access, download, or alter other users' data
- Use social engineering against the operator or Ekravo users
- Test on accounts you do not own without explicit written permission
- Deploy malware, ransomware, or destructive payloads
- Publicly disclose vulnerability details before [coordinated disclosure](#coordinated-disclosure), except as permitted after the disclosure deadline
- Demand payment or threaten disclosure (extortion)
- Share report details with third parties except to help us remediate

If you need a staging environment or a test account for a complex issue, email us first — we will try to help.

## Response expectations

For vulnerability reports sent to [security@ekravo.com](mailto:security@ekravo.com):

| Stage | Target |
|---|---|
| Initial acknowledgement | **5 business days** |
| Triage (valid / invalid / needs info) | **10 business days** of a complete report |
| Status updates | At least every **14 days** until resolved or mutually closed |
| Resolution notification | Within **7 business days** of fix deployment or accepted mitigation |

Complex issues may take longer; we will explain delays and revised timelines.

### Severity and remediation

We prioritise by severity and exploitability:

| Severity | Examples | Remediation target |
|---|---|---|
| **Critical** | Unauthenticated remote code execution, authentication bypass, cross-tenant data access, credential theft at scale | Urgent — begin mitigation immediately; target fix **≤ 7 days** |
| **High** | Privilege escalation, stored XSS with account impact, significant data exposure | Target fix **≤ 30 days** |
| **Medium** | CSRF with meaningful impact, limited information disclosure | Target fix **≤ 90 days** |
| **Low** | Low-impact issues, hardening | Best effort; may be scheduled |

Timelines are targets, not guarantees. Active exploitation may accelerate our response and disclosure.

### Coordinated disclosure {#coordinated-disclosure}

We follow **coordinated disclosure**:

1. Keep reports confidential until we have a fix or mitigation and agree on publication timing.
2. **Default disclosure deadline:** **90 days** from our acknowledgement of a complete, actionable report.
3. If we need more time, we will ask before the deadline and explain why. Extensions are by **mutual agreement**.
4. After a fix is released, we aim to publish an advisory (for example, a GitHub Security Advisory and/or notice on ekravo.com) within **30 days**, with credit if you requested it.
5. If we are unresponsive or cannot remediate within the deadline, you may disclose **after** the 90-day period (or agreed extension), provided you give us **7 days' notice** of intended publication.

### Rewards and recognition

We do **not** operate a paid bug bounty programme at this time. We do not offer monetary rewards for vulnerability reports.

We **do** offer:

- Public credit in advisories (with your permission)
- Thanks and acknowledgment for valid reports
- Clear duplicate handling: the first complete report receives credit; duplicates are closed with thanks

## Security incidents (user-facing)

This section is for **end users** asking what happens if Ekravo suffers a data breach — not for researchers reporting new vulnerabilities (use the reporting section above).

If we become aware of a breach that poses a significant risk to personal data, we notify affected users and regulators as required by applicable law. Our internal target is to notify affected users within **72 hours** of confirming a qualifying breach, even when local law allows longer. Full detail is in the [Privacy Policy security section](https://ekravo.com/privacy#security).

For live service disruption without a confirmed data breach, check [Status](https://ekravo.com/status).

## Independent external checks

External scanner reports for **ekravo.com** are pending. They will be published here after the first baseline scan of the new domain. Grades are issued and hosted by each provider on their own schedule — **not** Ekravo certifications, penetration tests, or guarantees of security.

Machine-readable metadata is in [`/security.json`](https://ekravo.com/security.json) under `externalVerification`.

## Automated scanning (OWASP ZAP)

We run periodic **OWASP ZAP baseline** scans against the public production site (`https://ekravo.com`). Results are sanitized before publication — no raw reports, request/response bodies, headers, or exploitable details are published.

- **Public summary:** [https://ekravo.com/security](https://ekravo.com/security) (human-readable) and [https://ekravo.com/security.json](https://ekravo.com/security.json) (machine-readable)
- **Operator workflow:** `npm run security:zap` (requires Docker). Raw reports stay in `security/zap-runs/` (gitignored); only sanitized summaries in `apps/server/src/lib/securityPosture/` are committed.

**Important:** Automated ZAP scanning is **not** an independent penetration test and does **not** imply OWASP certification. External scanner reports are pending; see [Independent external checks](#independent-external-checks) above.

No baseline scan has been published for ekravo.com yet. Once one runs, summaries distinguish **unique findings** (alert rules) from **alert instances** (URLs hit per rule), and publish the **raw ZAP report SHA-256** alongside the **sanitized summary SHA-256**. The raw ZAP report remains private; its SHA-256 hash is published so the original report can be integrity-verified. Intentionally accepted findings are documented on [/security](https://ekravo.com/security) with a public reason — not hidden.

## Security controls in place

Ekravo implements the following technical and organisational controls in the Ekravo codebase and production deployment:

- **Credential storage:** bcrypt-hashed passwords; SHA-256–hashed session tokens and API keys at rest; AES-256-GCM–encrypted BYOK provider keys and connected-service tokens (GitHub, Vercel, Supabase)
- **Sign-in options:** email verification (required for API access and gated features); optional TOTP authenticator app (Google Authenticator, 1Password, or any compatible app) as a second step at login — enable in Dashboard → Settings → Security
- **Your data:** one-click JSON export and one-click account deletion from Dashboard → Settings → Data & account (password confirmation for delete)
- **Transport:** TLS for data in transit in production; plaintext HTTP requests receive a **301 redirect to HTTPS** at the origin (complements Cloudflare **Always Use HTTPS** at the edge — enable both; they do not conflict). **HSTS** (`max-age=31536000`) is sent on HTTPS responses only; `includeSubDomains` and preload are intentionally disabled until every Ekravo subdomain is confirmed HTTPS-only (`hooks.ekravo.com` is a separate tunnel; `www.ekravo.com` is not published).
- **Authentication audit logging:** sign-in (success/failure), sign-out, signup, password change/reset, and API key create/revoke events; team administration events recorded in audit trails where the product logs them
- **Request protections:** per-route rate limiting; origin validation on cookie-authenticated state-changing requests (with `SameSite=strict` cookies); SSRF controls on user-configured outbound webhook delivery (HTTPS-only, public DNS, pinned connections); HSTS (HTTPS only, all app routes including preview/webhooks), Content-Security-Policy, and Permissions-Policy on application responses via Helmet (plus a restrictive Permissions-Policy header). Cloudflare-injected `/cdn-cgi/*` assets are edge-served and may not carry origin headers — see accepted findings on [/security](https://ekravo.com/security).
- **Web app rendering:** sanitised Markdown (`rehype-sanitize`) and outbound links restricted to `http`/`https` schemes
- **Application logging:** designed to exclude message content; accidental logging of sensitive content is treated as a security defect — report it to [security@ekravo.com](mailto:security@ekravo.com)
- **CI (every pull request and every push to `main`, via `.github/workflows/security.yml`):** secret scanning (Gitleaks), `npm audit` at high severity and above, build, and tests
- **Dependencies:** weekly automated update pull requests via Dependabot (Mondays)
- **Operator access:** production access is limited to operations, abuse response, and legal compliance — not advertising or model training. Direct operator access to customer content is logged where implemented; see our [Privacy Policy](https://ekravo.com/privacy#access-to-your-data)
- **Retention:** security and authentication audit logs are retained for up to **12 months** unless a longer period is required for an investigation or legal obligation — see [Retention and deletion](https://ekravo.com/privacy#retention) in our Privacy Policy

**Independent verification.** We have **not** published SOC 2 Type II, ISO 27001, or an independent penetration-test report. Our controls are described here, in our [Privacy Policy](https://ekravo.com/privacy#security), and in our [Trust Center](https://ekravo.com/trust). Business customers may request security questionnaire responses via [privacy@ekravo.com](mailto:privacy@ekravo.com).

## Vendor security review

For vendor review, we provide our standard Data Processing Addendum on request, a subprocessor list, and answers to common security questionnaires. Email [dpa@ekravo.com](mailto:dpa@ekravo.com) for the current DPA or [privacy@ekravo.com](mailto:privacy@ekravo.com) for other vendor questions. We respond to verified business requests within **30 days**. See the [Trust Center](https://ekravo.com/trust) for subprocessors and enterprise questions.

Do not route vulnerability reports through privacy@ or dpa@ unless security@ is unreachable — use the reporting section above.

## Related policies

- [Trust Center](https://ekravo.com/trust) — subprocessors, security controls, certifications roadmap, and vendor review
- [Privacy Policy](https://ekravo.com/privacy) — data collection, retention, rights requests, logging, and breach notification
- [Terms of Service](https://ekravo.com/terms) — acceptable use and service terms

---

**Governing law.** Ekravo is based in the United States. Disputes relating to use of the service are governed by the [Terms of Service](https://ekravo.com/terms).

**Material changes.** We may update this policy from time to time. Significant changes will be reflected in the updated date above and announced in our [Trust Center](https://ekravo.com/trust) where appropriate.