Driftstack — Vulnerability Disclosure Policy

Version: 1.0 · Effective: 2026-05-11

Driftstack welcomes vulnerability reports from independent security researchers. This policy describes what we consider in scope, how to report a finding, the safe-harbour protections we extend to researchers who follow this policy, and the disclosure timeline you can expect from us.

If you are reading this because you have already found something — please skip to the How to report section and contact us before doing anything else.

What this policy is + isn’t

This is a coordinated-disclosure policy, not a bug bounty programme. We do not pay cash rewards at this time. We do publicly credit researchers who report valid issues — see the Recognition section.

This policy is binding on Driftstack. So long as you operate within its terms, we will treat your testing as authorised under the applicable computer-fraud statutes and will not pursue legal action against you. The scope of authorisation is defined precisely below; testing that goes outside the listed scope or violates the listed restrictions is not covered by safe-harbour.

In scope

The following assets are in scope for security testing under this policy:

driftstack.dev and any subdomain (e.g. api.driftstack.dev, app.driftstack.dev, status.driftstack.dev).
The Driftstack public API (*.driftstack.dev/v1/*).
The Driftstack browser sandbox (the customer-supplied script surface) — but see Restrictions below for what you may and may not do inside it.
The Driftstack CLI (@driftstack/cli on npm) and the published SDKs.
The Driftstack desktop + web dashboard.
The Driftstack-published OAuth client metadata and discovery endpoints.

Out of scope

The following are not in scope and reports against them will be closed:

Sub-processor surfaces (Stripe, NowPayments, Cloudflare, AWS, Postmark, Sentry, LiveKit, GitHub, Hetzner). Report directly to those vendors.
Customer-controlled scripts running on Driftstack’s sandbox. By policy a customer’s own script is their own code; vulnerabilities in customer logic are not our scope. Vulnerabilities in the sandbox isolation itself are very much in scope (see above).
The Driftstack marketing site (www.driftstack.dev, the docs pages, the pricing page) — these are statically generated and carry no customer data. Reports on cosmetic / non-security issues in marketing copy should go to [email protected] instead.
Theoretical issues with no demonstrated impact.
Reports generated by automated tooling without manual analysis + verification. We accept tool-assisted findings, but the report must include a manual reproduction.

What classes of bugs we care about

These categories receive priority handling + the strongest recognition:

Sandbox escape. Any path by which a customer-supplied script can read disk, open arbitrary network connections, exfiltrate state from a co-tenant, or escape the per-session isolation.
Cross-account data exposure. Any path by which one customer can read or modify another customer’s data (sessions, recordings, profiles, billing, audit log, API keys).
Authentication / authorisation bypass. Token forgery, OAuth flow weaknesses, scope-escalation bugs, MFA bypass, session fixation, admin-scope escalation.
RCE on Driftstack infrastructure. Any path by which an unauthorised party can execute code on a Driftstack-managed host.
Data integrity bugs in billing / payments. Any path by which a customer can underpay, double-spend a credit, or alter another customer’s invoice.
PII handling / secret exposure. Any path that leaks API keys, hashed credentials, customer email lists, or audit-log contents.

Lower-priority categories (still in scope, but lower-recognition):

Self-XSS without a clear privilege-escalation path.
Rate-limit / DoS observations that do not exploit a vulnerability (we publish our rate-limit posture; “you can hit it” is by design).
Missing security headers on internal endpoints that are not reachable from the public internet.
Issues that require physical access to a researcher’s own device.

Restrictions

While testing under this policy you must not:

Touch other customers’ data. If a vulnerability lets you access data that does not belong to your own test account, stop immediately. Do not enumerate, download, or modify any data beyond the minimum needed to demonstrate the bug. Report it; we will reproduce internally with appropriate accounts.
Run automated load / DoS against production. Volume testing is out of scope under this policy. If you believe you’ve found an asymmetric-resource bug, describe it analytically and we will reproduce in isolation.
Use social engineering against Driftstack employees, customers, or our sub-processors. No phishing, no pretexting, no calls.
Use physical attacks. No tailgating, hardware tampering, etc.
Persist beyond the demonstration. Do not install backdoors, leave webshells, or maintain access past the proof-of-concept.
Disclose publicly before we have resolved the issue + the coordinated-disclosure window has elapsed. See Disclosure timeline below.

Within the sandbox itself you may:

Run any script you’d like in your own account’s sessions to probe the isolation boundary.
Use synthetic test accounts (you may register as many as needed — we ask only that you tag them with your handle, e.g. [email protected], so we can correlate them to reports).
Run scripts that intentionally consume your own quota until the rate-limit kicks in — that’s expected testing.

You may not in the sandbox:

Attempt to enumerate / observe other customers’ sessions or artefacts.
Use the sandbox as a launch point for attacks against third parties (no using it to scan/exploit unrelated internet hosts).

How to report

Email [email protected] with:

A clear title. “SSRF in /v1/sessions/create via redirect parameter” beats “Bug found.”
A reproduction. Minimum reliable steps + the account/session ID(s) you used. Curl commands or scripts are ideal.
Impact. What an attacker can do with this. Don’t just say “this is high severity” — show what the worst-case outcome is.
Your contact handle. How you want to be credited (if credited) once we publish.
(Optional) Your PGP key. Our security key is published at https://driftstack.dev/.well-known/security.txt if you’d like to encrypt the report.

You will receive an automated acknowledgement within five minutes and a human reply within one business day (Mon–Fri, EU/Central).

Disclosure timeline

We use 90-day coordinated disclosure by default, measured from the date we acknowledge the report. The clock is:

Day 0 — acknowledge. Within 1 business day. We confirm receipt + assign an internal tracking ID.
Day 7 — triage. We respond with a severity assessment + a rough remediation timeline. If we cannot reproduce the issue we will say so + ask for additional detail.
Day 0 to ~30 — fix. Most issues are resolved well within the 90-day window. For platform-bug-class issues (sandbox, authentication) the fix typically ships in days.
Pre-publication coordination. Before we publish anything (blog post, CVE, status-page advisory) we share the draft with the reporter for review.
Day 90 — public. If the issue is unresolved at day 90 we publish what we know + the workaround we recommend. We will not hide an unresolved security issue past 90 days — neither party wants that.

We may extend the 90-day window in writing if the reporter agrees + the underlying issue requires unusual coordination (e.g. a sub-processor patch is needed first). We will not unilaterally extend the window.

Safe harbour

So long as you comply with this policy, Driftstack:

Will not initiate legal action against you under the Computer Fraud and Abuse Act, the EU Cybercrime Convention implementing statutes, the UK Computer Misuse Act, or any equivalent applicable law for activity that falls within the authorisation granted here.
Will not pursue claims for breach of our Terms of Service for testing-related activity that falls within this policy.
Will work with you in good faith to clarify scope when there is ambiguity.
Will publicly support you, where relevant, against good-faith legal threats from third parties arising from your conduct under this policy.

This safe harbour is granted only by Driftstack and covers only Driftstack-controlled assets. Activity against third-party services (our sub-processors, customer-controlled infrastructure, etc.) is not covered and you must obtain those parties’ authorisation separately.

Recognition

With your consent we will:

Credit you in the security-advisory or release-notes entry that closes the issue.
Add you to a public researcher roll of honour — a page we will publish once we have entries to populate it.
Tweet / post a thank-you from @driftstack if you’d like.

You may also request anonymity; we honour that.

Contact

Vulnerability reports + scoping questions: [email protected]
Press / coordinated-disclosure questions: [email protected]
Out-of-band contact (if security@ is unreachable): DM @driftstack; we’ll move the thread to a secure channel.

Vulnerability Disclosure Policy