Vulnerability Disclosure Policy

Zynth Media Technology builds identity and access infrastructure. A vulnerability in Zynth Auth is a vulnerability in every system that trusts it, so we would rather hear about one from you than from an incident. This policy tells you what you may test, what you may not, what protection you have while doing it, and what we will do with what you find.

We will not pursue or support legal action against anyone who reports a vulnerability in good faith under this policy, and we will work with you rather than around you.

Email security@zynthmedia.com. The same address is published machine-readably at /.well-known/security.txt (RFC 9116), served on both this site and the application origin, whose Policy field points back at this page.

A report is most useful when it contains: the affected host or endpoint, the version or date you tested, the steps to reproduce it, what an attacker gains, and any proof-of-concept you used. Screenshots and request/response captures help. Write in English.

Please report to us first, and give us a reasonable opportunity to fix the issue before disclosing it publicly (see “Coordinated disclosure”, below). Do not file a security issue in a public tracker.

The following are in scope for good-faith testing under this policy:

• The application origin auth.zynthmedia.com and the APIs it serves.
• This marketing site, zynthmedia.com, and the published documentation.
• The published SDKs, container images, and the offline installation bundle — including their signatures and supply-chain metadata.
• A self-hosted deployment you run yourself, on your own infrastructure. This is the preferred way to test anything intrusive, and we will help you stand one up.

New organizations are created by invitation only during the private beta, so you may not be able to register an account to test against the managed service. Tell us at security@zynthmedia.com and we will arrange access or help you run a local deployment. Testing without an account, against the managed service, is limited to what an anonymous visitor can reach.

The following are not authorised. They are excluded because they harm someone — a customer, a third party, or an unrelated service — not because we would rather not know:

• Accessing, modifying, or deleting data belonging to another tenant, customer, or user. If a flaw exposes someone else’s data, stop at the minimum proof that it does, and tell us.
• Exfiltrating data. Do not download, retain, or copy personal data, credentials, keys, or customer content. A record count or a redacted field is proof enough.
• Denial of service, resource exhaustion, load or stress testing, or anything that degrades the service for others — including automated scanning at volume.
• Social engineering, phishing, or pretexting against our people, our customers, or our vendors; and any physical attack on offices or infrastructure.
• Attacks on third-party services we depend on (our cloud provider, email, payments, identity providers). Report those to the party that runs them.
• Spam, brute-forcing live accounts, or any attempt to lock out, impersonate, or persist as a real user.
• Installing malware, backdoors, or persistence of any kind, or pivoting further into our infrastructure once you have proven an entry point.

We also do not treat the following as vulnerabilities on their own, absent a demonstrated impact: missing security headers with no exploit path, reports produced solely by an automated scanner, best-practice findings on TLS configuration or email records, self-XSS, clickjacking on pages with no state-changing action, and version-disclosure banners.

If you make a good-faith effort to comply with this policy during your research, we will consider your activity authorised. Specifically, and for as long as you stay within the scope and rules above:

• We will not initiate or support legal action against you, and we will not report you to law enforcement, in connection with your research.
• We will not treat your activity as a breach of our Terms of Service, and we will not suspend your account for it.
• If a third party brings action against you for research conducted under this policy, we will make it known, publicly if necessary, that your actions were authorised.

This authorisation is ours to give and covers only our own systems. It does not authorise you to act against a third party, and it does not override any law that applies to you. If you are unsure whether something is in scope, ask before you test it — a question is always in scope.

Reporting a vulnerability in good faith, even one that turns out to be a duplicate or a non-issue, never costs you anything under this policy.

• Acknowledgement of your report within 5 business days.
• An initial assessment — reproduced or not, severity, and our intended course — within 10 business days.
• Progress updates at least every 15 business days while the issue is open, and a note when it is fixed.
• Credit for the finding in our release notes if you want it, under whatever name you choose. We will not name you without your consent.

These are the targets we hold ourselves to. Zynth Auth is in private beta and the security response is a small team, so they are commitments of effort and communication, not a service level: no service level applies during the beta, and this policy creates none.

We do not operate a paid bug-bounty programme and do not offer monetary rewards. We say so here rather than leave it to be discovered after the work is done.

We ask that you keep the details of a vulnerability confidential until we have released a fix, or for 90 days from your report, whichever comes first. If we need longer we will say so and explain why, and we will not use the request to delay indefinitely.

We publish fixes for security-relevant defects in our release notes, and we would rather describe an issue accurately than quietly. Where a fix affects self-hosted deployments, the release notes say what an operator must do.

Our security posture and the controls behind it are described in the Trust Centre. Acceptable use of the service is governed by the Terms of Service; where they and this policy differ on security research, this policy governs.