Vulnerability Disclosure Policy

01How to report

Email security@adoptiv.com. That address goes to the people who can act on it, and it is the only address for this.

Do not open a support chat, do not post it publicly, and do not send it to a sales contact. Those routes are slower and they put the detail in front of people who cannot fix it.

You do not need an account, an invitation or a prior relationship with us to report something. If you have found a problem, we want to hear about it.

02What to include

A report we can reproduce gets fixed. A report we cannot gets an email asking for the things below, which costs everyone a week.

• Which host or part of the product is affected, with the exact URL or endpoint.
• What the vulnerability is, in one or two sentences, before the detail.
• Steps to reproduce, in order, precise enough that we can follow them without guessing.
• What an attacker gets out of it. This is the part that decides how fast we move.
• Any proof you have: a request and response, a short screen recording, a minimal script. Redact anything that is not yours.
• Whether you have told anyone else, and whether you intend to publish.
• How you want to be credited, or that you do not want to be.

Write in English if you can. If you cannot, send it in your own language rather than not sending it.

03In scope

The systems Adoptiv Inc runs.

• adoptiv.com and www.adoptiv.com, including the marketing site.
• The Adoptiv web application and its subdomains, including a workspace subdomain you own or have written permission from its owner to test.
• The Adoptiv public API.
• Authentication, single sign-on and session handling.
• Any place where one workspace's data could be reached from another. This is the class of finding we care about most.

04Out of scope

Systems we do not run, and findings that do not show impact.

• Anything hosted by a third party: Intercom, Calendly, Google, PostHog, Stripe, and our status page. Report those to the vendor. We will help you route it if you are not sure who owns something.
• Scanner output with no demonstrated impact. A tool's severity rating is not a finding.
• Missing security headers, cookie flags on cookies that carry nothing sensitive, and TLS configuration opinions, unless you can show a working exploit.
• Rate limiting on endpoints that are not authentication related, without demonstrated impact.
• Self-inflicted cross-site scripting, and clickjacking on pages with no state-changing action.
• Missing SPF, DKIM or DMARC records on domains that do not send mail.
• Software version numbers, without a working exploit against our deployment.
• Vulnerabilities that only affect browsers that are no longer supported by their vendor.
• Social engineering of our staff, our customers or our vendors, and any physical attack. These are not out of scope because they would not work. They are out of scope because we will not authorise you to try them on people.

05What you may do

• Test against your own account, or a trial workspace you create for the purpose.
• Use the minimum access needed to prove the issue, and then stop. Proving you can read one record you should not be able to read is enough. Reading a thousand is not more proof, it is a breach.
• Report a partially understood finding. You do not have to fully weaponise something before telling us.
• Ask us questions while you work. If you are unsure whether something is in scope or whether a step crosses a line, ask before you take it.

06What you may not do

• Access, modify, copy, keep or share another customer's data. If you reach data that is not yours, stop at once, do not save it, and tell us in the report what you saw and how much.
• Run denial of service tests, load tests, brute force at volume, or anything else that degrades the service for the people using it.
• Social engineer or phish our staff, our customers or our vendors.
• Test physical premises, or attempt access to offices or hardware.
• Install malware, leave a backdoor, create accounts you keep, or otherwise establish persistence.
• Modify or delete data that is not yours, including defacing a page to prove a point.
• Publish the finding before it is fixed or before the disclosure window below has passed.
• Demand payment, or offer to withhold a report in exchange for one. That is not research, and it ends the safe harbour below immediately.

07Safe harbour

If you follow this policy in good faith, we will treat your research as authorised.

• We will not bring legal action against you for the research, and we will not support action brought by anyone else for it.
• We consider that research authorised access for the purposes of computer misuse and anti-hacking laws that apply to us, and we will say so in writing if you need us to.
• If a third party brings action against you for research that stayed inside this policy, we will state publicly and to that party that it was authorised.
• If you accidentally cross a line and tell us promptly, we will treat that as good faith. Telling us is the thing that keeps it good faith.

The limits of that are worth stating too. Safe harbour covers only the systems listed as in scope. It does not extend to a third party's systems, even where you reached them through us, and it does not survive a breach of the rules above.

08What happens next

Our commitments on timing. These are business days, and they are ours to keep whether or not the report turns out to be valid.

• Acknowledgement within 3 business days, from a person, not an autoresponder alone.
• An initial assessment within 10 business days: whether we have reproduced it, whether it is in scope, and what severity we have assigned.
• An update at least every 14 days after that, until it is resolved or we have told you we will not be acting and why.
• Notice when the fix ships, so you can verify it. If our fix is incomplete, say so and we will reopen it.
• We ask you to hold publication for 90 days from your report, or until the fix ships, whichever comes first. If we need longer we will ask, explain why, and we will not simply keep asking.

If we decide not to fix something, we will tell you that directly and give the reason. Silence is not one of our options here.

09Rewards

Adoptiv does not run a bug bounty and does not pay for vulnerability reports.

We would rather say that here than let you spend a weekend on the assumption that we do. If that changes, this page changes first.

What we do offer is credit. If you want it, we will name you or your handle on the page in the release note for the fix, and we will write you a reference describing what you found if that is useful to you. If you would rather stay anonymous, say so and we will not name you.

10security.txt

The machine-readable version of this policy, served at /.well-known/security.txt on adoptiv.com.

• Contact: mailto:security@adoptiv.com
• Expires: 2027-02-01T00:00:00.000Z
• Preferred-Languages: en
• Canonical: https://adoptiv.com/.well-known/security.txt
• Policy: https://adoptiv.com/legal/vulnerability-disclosure

If the Expires date above has passed, the file is stale and the page you are reading is the authority. Tell us at security@adoptiv.com and we will refresh it.