# Quilt Security Response Policy

Version 1.0, 4 November 2026. Owner: Quilt security lead (security@quilt.bio).

This policy describes how Quilt receives reports of security vulnerabilities in its products, how it fixes them, and how it tells customers and the public. It applies to the Quilt Platform (the catalog, registry, and the AWS stack that runs them), the `quilt3` Python client and CLI, QuiltSync, the Quilt MCP servers, and the code Quilt publishes on GitHub.

## Reporting a vulnerability

Please report suspected vulnerabilities privately, through either channel:

- Email **security@quilt.bio**. This reaches the whole Quilt team.
- Use GitHub's private vulnerability reporting on [quiltdata/quilt](https://github.com/quiltdata/quilt/security/advisories/new).

Please do not open a public issue, pull request, or forum post for a security problem until a fix is available and we have agreed on disclosure.

A useful report includes the product and version, the steps or a proof of concept needed to reproduce the problem, the impact you believe it has, and how you would like to be credited. Encrypted email is not required; if you need a key, ask at the address above.

## What to expect from us

- **Acknowledgement** within 1 business day (Pacific time) of receiving a report.
- **Triage and a severity rating** within 3 business days, with a point of contact who owns the report.
- **Progress updates** at least every 7 days while the issue is open, and a chance to review the fix before release when the reporter wants one.

We do not run a paid bounty programme. We credit reporters in the published advisory unless they ask us not to.

## Severity and fix targets

We rate issues with CVSS v3.1 as a guide and use four levels.

| Severity | Typical impact | Interim mitigation | Fix released |
|---|---|---|---|
| Critical | Takeover of a user session, exposure of credentials or data without a login, remote code execution | Within 1 business day | Within 14 days |
| High | Exposure of data or privilege escalation that needs a login or user interaction | Within 3 business days | Within 30 days |
| Medium | Limited data exposure, denial of service, bypass of a secondary control | Next scheduled release | Within 90 days |
| Low | Minimal security impact, defence-in-depth hardening | As scheduled | As scheduled |

A mitigation is a step a stack manager can take now, such as turning off a feature or changing a setting. A fix is a Quilt release that removes the issue without manual steps. These are targets; where a fix takes longer, we say so in the advisory and keep the mitigation current.

These targets sit alongside the response times in our [support policy](https://docs.quilt.bio/). A Critical or High security issue is handled as a P1 incident for all customers, regardless of plan.

## Telling customers

Quilt Platform runs in each customer's own AWS account, so customers apply fixes themselves. For every Critical or High issue we send a **security advisory** to the registered managers of each Quilt stack, through the same channel as release notes. The advisory states:

- what the issue is and who is affected, by product and version;
- the severity;
- interim steps to take now, with the commands needed, and what those steps turn off;
- the release that fixes it, and anything to do before or after upgrading;
- how to check your own logs for signs of misuse, where that is possible;
- who found it.

We send the advisory when a mitigation is available, even if the fix is not. When the fix ships, we write again. Advisories carry a Quilt identifier of the form `QSA-YYYY-NNN` and, where one is issued, a GitHub advisory (GHSA) or CVE identifier.

Stack managers who want to add or change the people who receive advisories can write to security@quilt.bio.

## Public disclosure

We follow coordinated disclosure. We publish a GitHub security advisory for each Critical or High issue in code we publish, normally when the fixing release is available and no later than 90 days after the report, whichever comes first. The published advisory credits the reporter and links the fix. We ask reporters to hold their own write-ups until then; if a reporter needs an earlier date, we will work out a timeline with them.

We do not publish advisories for issues in third-party software we depend on; we update the dependency and note it in release notes.

## Safe harbour

If you make a good-faith effort to follow this policy, we consider your research authorised, we will not pursue or support legal action against you for it, and we will work with you to understand and resolve the issue quickly. Good faith means testing only against systems you own or have permission to test, not accessing, changing, or destroying data that is not yours, not degrading service for others, and keeping details private until we have agreed on disclosure.

Please do not test against Quilt stacks you do not operate. Customer stacks run in customer AWS accounts and are not ours to authorise. Quilt-operated demo stacks are in scope.

## Out of scope

Reports about the following are welcome but will usually be rated Low or closed: findings from automated scanners with no demonstrated impact, missing security headers on static or marketing pages, clickjacking on pages with no sensitive actions, rate limiting without a demonstrated attack, and social engineering of Quilt staff or customers.

## Changes to this policy

This policy is published at https://security.quilt.bio/. Changes are dated and versioned at the top of the document.