Back to Trigger

Security & vulnerability reporting

docs/self-hosting/security.mdx

4.5.31.9 KB
Original Source

We take the security of Trigger.dev seriously, for both Cloud and self-hosted deployments. This page covers how to report a vulnerability, what to expect, and how to stay informed about security releases.

<Warning> Do not report security vulnerabilities through public GitHub issues, pull requests, or Discord. Use one of the private channels below. </Warning>

Reporting a vulnerability

<Steps> <Step title="Choose a private channel"> - **GitHub (preferred):** open a private report from the repository's **Security** tab using **"Report a vulnerability"** ([direct link](https://github.com/triggerdotdev/trigger.dev/security/advisories/new)). - **Email:** `[email protected]` </Step> <Step title="Include the details"> A description and impact, steps to reproduce (a proof of concept helps), affected versions/components, and any suggested fix. </Step> <Step title="We track it privately"> Every report is tracked in a private GitHub Security Advisory. If you email us, we open the advisory on your behalf. </Step> </Steps>

What to expect

StageTarget
Acknowledgementwithin 3 business days
Validation + CVSS 3.1 severity assessmentwithin 1 week

We score issues with CVSS 3.1 and prioritise remediation by severity:

Severity (CVSS 3.1)Target time to resolve
Critical (9.0–10.0)7 days
High (7.0–8.9)30 days
Medium (4.0–6.9)90 days
Low (0.1–3.9)As needed
<Note> These are best-effort targets measured from when we validate and accept a report, not guarantees. We follow coordinated disclosure with a default 90-day window, and publish a GitHub Security Advisory (requesting a CVE where applicable) once a fix ships. </Note>

Supported versions

We patch the latest released version line only. Run the latest version-tagged release to receive security fixes — see Self-hosting overview.