chore: add security docs

SECURITY.md

@@ -0,0 +1,49 @@
+# Security Policy
+
+We take the security of Trigger.dev seriously — for both our Cloud service and self-hosted deployments. This document explains how to report a vulnerability and what to expect from us.
+
+## Reporting a vulnerability
+
+**Please do not report security vulnerabilities through public GitHub issues, pull requests, or our Discord.**
+
+Use one of these private channels instead:
+
+1. **GitHub (preferred):** Open a private report from the repository's **Security** tab — click **"Report a vulnerability"** ([direct link](https://github.com/triggerdotdev/trigger.dev/security/advisories/new)).
+2. **Email:** `security-advisories@trigger.dev`
+
+Please include as much of the following as you can:
+
+- A description of the vulnerability and its impact
+- Steps to reproduce, ideally with a proof of concept
+- Affected version(s) and component(s)
+- Any suggested remediation
+
+If you report by email, we will open a private GitHub Security Advisory to track the issue. All reports — however they reach us — are tracked there.
+
+## What to expect
+
+| Stage | Target |
+| --- | --- |
+| Acknowledgement of your report | within 3 business days |
+| Validation and severity assessment (CVSS 3.1) | within 1 week |
+
+We assess severity using CVSS 3.1 and prioritise remediation accordingly:
+
+| 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 |
+
+These are best-effort targets, measured from the point we validate and accept a report — not guarantees. Real-world exploitability may lead us to escalate an issue beyond its base score.
+
+## Coordinated disclosure
+
+We follow coordinated disclosure. Please give us a reasonable opportunity to investigate and ship a fix before any public disclosure. Our default disclosure window is 90 days from acceptance, though we aim to resolve issues sooner.
+
+Once a fix is released we publish a GitHub Security Advisory (and request a CVE where applicable), and we credit reporters unless you ask to remain anonymous.
+
+## Supported versions
+
+We patch the **latest released version line** only. Self-hosters should run the latest version-tagged release to receive security fixes. See the [self-hosting documentation](https://trigger.dev/docs/self-hosting/overview).

docs/docs.json

@@ -276,6 +276,7 @@
               "self-hosting/overview",
               "self-hosting/docker",
               "self-hosting/kubernetes",
+              "self-hosting/security",
               {
                 "group": "Environment variables",
                 "pages": ["self-hosting/env/webapp", "self-hosting/env/supervisor"]

docs/self-hosting/docker.mdx

@@ -342,6 +342,8 @@ By default, the images will point at the latest versioned release via the `lates
 TRIGGER_IMAGE_TAG=v4.5.0
 ```
 
+We patch the latest released version line only, so keep an eye on new releases to receive security fixes. See [Security & vulnerability reporting](/self-hosting/security) to subscribe to security notices.
+
 ## Task events
 
 By default, task events (timeline, logs, spans) are stored in PostgreSQL. For production deployments we recommend storing them in ClickHouse instead, it scales to much higher volumes and avoids unbounded growth of the `TaskEvent` table.

docs/self-hosting/overview.mdx

@@ -6,7 +6,7 @@ description: "You can self-host Trigger.dev on your own infrastructure."
 
 Self-hosting Trigger.dev means you run and manage the platform on your own infrastructure, giving you full control over your environment, deployment process, and the URLs you expose the service on.
 
-You are responsible for provisioning resources, handling updates, and managing any security, scaling or reliability challenges that arise.
+You are responsible for provisioning resources, handling updates, and managing any security, scaling or reliability challenges that arise. See [Security & vulnerability reporting](/self-hosting/security) for how to report issues and stay informed about security releases.
 
 We provide version-tagged releases for self-hosted deployments. It's highly advised to use these tags exclusively and keep them locked with your CLI version.
 
@@ -106,4 +106,7 @@ It's dangerous to go alone! Join the self-hosting channel on our [Discord server
   <Card title="Kubernetes" color="#326CE5" icon="dharmachakra" href="/self-hosting/kubernetes">
     Learn how to self-host Trigger.dev with Kubernetes.
   </Card>
+  <Card title="Security" icon="shield-halved" href="/self-hosting/security">
+    Report vulnerabilities and stay informed about security releases.
+  </Card>
 </CardGroup>

docs/self-hosting/security.mdx

@@ -0,0 +1,50 @@
+---
+title: "Security & vulnerability reporting"
+description: "How to report security issues in Trigger.dev, our response targets, and how self-hosters receive security notices."
+sidebarTitle: "Security"
+---
+
+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:** `security-advisories@trigger.dev`
+  </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
+
+| Stage | Target |
+| --- | --- |
+| Acknowledgement | within 3 business days |
+| Validation + CVSS 3.1 severity assessment | within 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](/self-hosting/overview).