Vulnerability Disclosure Policy

1. Scope

This policy applies to public websites, hosted applications, and APIs operated by Sytance Technologies Limited that link to this page, including the Sytance service.

Customer environments, customer-managed systems, third-party services, integrations, open-source projects not maintained by us, and infrastructure that we do not own or control are outside scope. A third-party component used by Sytance is in scope only to the extent that your report concerns its effect on a Sytance-operated service.

If ownership or scope is unclear, contact security@sytance.com and wait for confirmation before continuing.

2. Authorised good-faith research

Security research is authorised under this policy only when it is conducted in good faith, remains within scope, follows the rules below, and is limited to what is reasonably necessary to confirm and report a suspected vulnerability.

• Use only accounts and data that you own or have permission to use.
• Use the minimum testing necessary to confirm the issue, and keep request volume low enough to avoid affecting the service or other users.
• Stop immediately if you encounter another person's data, credentials, or confidential information.
• Do not retain, alter, delete, disclose, or download data in bulk.
• Do not establish persistence, deploy malware, or use a vulnerability for any purpose other than validation and reporting.
• Report the issue promptly, keep the details confidential, and allow us a reasonable opportunity to investigate and address it.

3. Prohibited testing

• Denial-of-service, load, stress, or resource-exhaustion testing.
• Social engineering, phishing, credential stuffing, or password spraying.
• Physical attacks or testing of third-party facilities and infrastructure.
• Destructive activity, data corruption, mass account creation, or high-volume automated scanning.
• Testing that violates law or another person's rights.
• Threats, extortion, or demands for payment.

4. What to include in a report

A concise, reproducible report helps us assess the issue safely and respond more quickly. Include the following where available:

• The affected domain, URL, API route, feature, or component.
• A clear description of the vulnerability and potential impact.
• Reproduction steps using a test account and sanitised data.
• A minimal proof of concept, request and response, screenshot, or log extract.
• Any preconditions and safety measures taken.
• Your preferred contact details.

• security@sytance.com

5. Response targets

We aim to acknowledge a sufficiently complete report within three business days and provide an initial triage outcome within ten business days. While a validated issue remains under active investigation, we aim to provide a material status update at least every ten business days when the reporter has supplied a working contact channel.

A business day means Monday to Friday, excluding public holidays in Hong Kong. These are communication targets, not guaranteed remediation deadlines. An incomplete report, a high volume of submissions, unusual technical complexity, or reliance on a third party may extend the timing; if so, we will communicate a revised expectation where practicable.

6. How we handle a report

• Receipt and tracking — we record the report, check that the affected asset is in scope, and establish a contact channel with the reporter.
• Triage and reproduction — we assess the information supplied, attempt to reproduce the behaviour, remove duplicates, and request clarification where needed.
• Risk assessment and prioritisation — if validated, we assess severity, exploitability, affected data and users, exposure, compensating controls, and evidence of active exploitation.
• Remediation and verification — the responsible team develops a mitigation or fix, tests it, manages relevant release or third-party dependencies, and verifies the result.
• Closure and disclosure — we tell the reporter the outcome that we can share, coordinate any public disclosure, and consider whether a security advisory or acknowledgement is appropriate.

7. Safe harbour

If you make a good-faith effort to follow this policy, we will treat your research as authorised to the extent we can legally grant that authorisation and will not initiate legal action solely for accidental, good-faith conduct within its scope.

If a third party initiates legal action concerning activity that complied with this policy, we may confirm that the activity was conducted under our vulnerability disclosure process. We cannot authorise activity on behalf of another organisation or promise how a third party or public authority will respond.

This safe harbour does not authorise unlawful, reckless, malicious, or extortionate conduct, waive another person's rights, or protect conduct that continues after we ask you to stop.

8. Coordinated disclosure and recognition

Keep a suspected vulnerability, proof of concept, affected-customer information, and remediation detail confidential while we investigate. We normally work toward coordinated disclosure within 90 calendar days after acknowledging a sufficiently complete report. Before publishing, contact us so that we can agree the technical scope and a date that allows users to protect themselves.

The appropriate disclosure date may be earlier or later depending on severity, active exploitation, customer risk, release readiness, and affected third parties. We will not request an extension merely to avoid scrutiny; where more time is needed, we will explain the reason that can safely be shared.

We may publish an advisory when disclosure would help users protect themselves. We will discuss attribution with the reporter before naming them.

This policy is not a bug bounty and does not create an entitlement to payment, reward, employment, or other compensation.