Administration and Security

Vulnerability reporting

How to report a security vulnerability to Ottili responsibly: the disclosure channel (security@ottili.one), what to include, scope, rules of engagement, severity classification, safe harbor and coordinated disclosure.

Overview

Ottili ONE takes security vulnerabilities seriously. If you discover a weakness in the Ottili ONE platform or a public Ottili surface, this article explains how to report it responsibly and what to expect afterwards.

Reporting is separate from the incident-response process: this page is about *how to tell us*; the detection, containment and resolution steps are covered in [Incident response](/docs/incident-response). The broader security architecture (tenant isolation, authentication, permissions, encryption, secrets management, audit) is in [Security overview](/docs/security-overview).

Report a vulnerability

Ottili operates a coordinated disclosure channel for security researchers and customers.

Disclosure channel:* send reports to security@ottili.one*. This is the single canonical address for vulnerability reports.
Acknowledgment:* Ottili acknowledges a well-formed report within 72 hours* (acknowledgment SLA).
Encrypted reports (optional):* reports may be submitted encrypted. No PGP fingerprint is published at this time; this page shows no PGP block rather than an invented fingerprint.
Direct contact:* customers with an active engagement may also raise security concerns through their account team; the report is still routed to the same security queue.

What to include

A good report helps us triage quickly. Include as much as you can:

A clear description of the vulnerability and the affected product or surface.
Steps to reproduce, or a proof-of-concept if you have one.
The potential impact you identified.
Any mitigating factors or suggested fixes (optional).
Your contact details (optional, so we can follow up and credit you).

Scope

In scope:* the Ottili ONE platform and the public Ottili surfaces (website, status page, public docs). Ottili Auth and the public boundary of the Unified API.
Out of scope:* social-engineering attacks targeted at Ottili staff; physical security of Ottili offices or facilities; third-party services outside Ottili's control.

Rules of engagement

Please do not*:

run high-intensity automated scanners against production;
access, modify or delete customer data;
disclose the vulnerability publicly before it is resolved.

Stay within the bounds of authorized testing and never put customer data at risk.

Severity classification

When you report, we assign a severity so response effort matches impact. The model is the same one used during incident response:

Severity	Description	Response target	Update cadence
Critical*	Active exploitation, data exposure, or loss of availability of a core service.	Acknowledge and begin mitigation within 1 hour.	Status updates at least every 4 hours until resolved.
High*	Serious vulnerability with a plausible path to exploitation, or partial degradation of a core service.	Acknowledge within 4 hours and begin mitigation.	Status updates at least twice per day until resolved.
Medium*	Limited impact or exploitation requires specific conditions.	Acknowledge within 1 business day.	Daily status updates until resolved.
Low*	Minimal impact, hardening or defense-in-depth improvement.	Acknowledge within 2 business days.	Updates as work progresses.

After you report

Every report moves through the same path:

1. Triage* — we confirm receipt, reproduce where possible, and assign a severity.

2. Updates* — for active issues we publish status on the [Ottili status page](https://status.ottili.one) and contact affected companies directly.

3. Resolution* — we remediate the root cause and, where appropriate, share a transparent post-incident review with affected customers.

You will receive at least one follow-up acknowledging receipt; for higher severities you can expect the cadence above.

Safe harbor and coordinated disclosure

We coordinate disclosure with reporters and avoid naming individuals.
We do not pursue legal action against researchers acting in good faith who follow the rules of engagement.
We credit researchers who wish to be acknowledged for their report.

Feature status

The vulnerability-disclosure program and the public /security page are Live (General Availability)*. Ottili ONE clearly distinguishes Live, Beta, Private Beta, In Development, Planned and Concept. What these terms mean is explained in [Understand feature status labels](/docs/understand-feature-status-labels).

[Security overview](/docs/security-overview) — the whole security architecture at a glance.
[Incident response](/docs/incident-response) — how Ottili responds once a vulnerability is confirmed.
[Secrets management](/docs/secrets-management) — how configuration and integration secrets are protected.
[Tenant isolation](/docs/tenant-isolation) — how your company stays separate from others.
[Account and data security](/docs/account-and-data-security) — authentication, sessions, isolation, audit.
[Roles and permissions](/docs/roles-and-permissions) — who can do what.
[Support escalation](/docs/support-escalation) — how to escalate to support.
[Understand feature status labels](/docs/understand-feature-status-labels) — what the status terms mean.
[Audit logs](/docs/audit-logs) — accountability across every module.

Was this article helpful?