> ## Documentation Index
> Fetch the complete documentation index at: https://sponson.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Security policy

> Supported versions, how to report a vulnerability, and what is in scope.

Sponson resolves secrets, writes to cloud providers on your behalf, and decides whether a run may touch
production. A bug in any of those is a security bug. Please report it privately.

## Supported versions

Sponson is pre-1.0. Only the latest minor release line receives security fixes; fixes are released as a new
patch version of every affected package (`sponson`, `@sponson/core`, `@sponson/adapters`, `@sponson/sim`).

| Version | Supported |
| - | - |
| 0.2.x | yes |
| \< 0.2 | no — upgrade; v1 receipts are migrated automatically |

The GitHub Action (`action/`) follows the version of the `sponson` package it runs (its `version` input).

## Reporting a vulnerability

**Never put vulnerability details in a public issue or pull request.**

1. Open an issue with the **Security contact request** form (or titled "Security contact request") and **no
   details** — only that you have something to report. A maintainer ([MAINTAINERS.md](https://github.com/MishaBear94/Sponson/blob/main/MAINTAINERS.md)) will reply
   with a private channel, normally within two working days.
2. Send the details there.

If the repository's **Security → Advisories → Report a vulnerability** button is available to you, use it instead:
it is private from the first message. (It appears only when the maintainers have enabled private vulnerability
reporting.)

Please include:

* the Sponson version (`sponson --version`) and Node.js version;
* a minimal `release.plan.yaml` and the commands that reproduce the problem (against `pnpm sim` if possible —
  the fake cloud needs no real credentials);
* what leaked or what was bypassed, and where (stdout, stderr, `--json`, a receipt file, a receipts branch,
  a PR comment, MCP output, a provider request).

**Never send real secrets.** Use obvious placeholders such as `sk_test_PLACEHOLDER`; the reproduction should show
the placeholder appearing where it must not.

What to expect:

| Step | Target |
| - | - |
| Acknowledgement | within 3 business days |
| Triage and severity assessment | within 7 days |
| Fix or mitigation for high/critical issues | within 30 days, coordinated with you |
| Public advisory (GHSA, and a CVE when warranted) | when the fix is released |

We credit reporters in the advisory unless you ask us not to.

## Scope

### In scope

These break promises Sponson makes in its README and in the invariants in `CONTRIBUTING.md`; we treat them
as vulnerabilities, not ordinary bugs:

* **Secret leakage.** A resolved secret value, a provider credential (`VERCEL_TOKEN`, `NEON_API_KEY`,
  `CLERK_SECRET_KEY`, …) or an output marked `sensitive` appearing — in any encoding (plain, URL-encoded,
  base64, JSON-escaped, truncated) — in stdout, stderr, `--json` output, error messages, plan text, MCP
  responses, PR comments written by the Action, or log lines. (Invariant 1.)
* **Receipts.** A secret value or a reversible hash of one written into a receipt or into the history of a
  receipts branch (`sponson-receipts/<env>/<scope>`, or the legacy `sponson/receipts`); a receipt that can be made to
  claim ownership of resources Sponson did not create so that `apply --destroy` deletes them; a receipt or lock that can be forged or tampered with to make
  Sponson modify resources it does not manage. (Invariants 5, 6, 8.)
* **Production approval bypass.** Any way to make Sponson write to `production` — directly, through a line whose
  `writesEnvironment()` is production while `--env` is something else, through MCP, through the GitHub Action,
  or through plugin loading — without `--approved-by` / `SPONSON_APPROVED_BY`. (Invariant 7.)
* **Scope boundary violations.** One scope (a PR, a branch) changing or destroying resources owned by another.
* **Plan-time writes.** `sponson plan` or `status` performing any write to a provider. (Invariant 4.)
* **Code execution from untrusted input.** A plan file, a receipt, or a provider response that causes code to be
  loaded or executed (plugins are loaded only from `SPONSON_PLUGINS`, which is trusted configuration).
* **The GitHub Action** (`action/action.yml`): script injection from PR titles, branch names or other
  attacker-controlled event fields; leaking `github-token` or provider secrets to forked-PR workflows.

### Out of scope

* Vulnerabilities in the providers themselves (Vercel, Neon, Clerk, Doppler, 1Password) — report those to the
  provider.
* Anything requiring an attacker who already controls the machine, the CI runner, the environment variables,
  `SPONSON_PLUGINS`, or write access to the repository's default branch. A plugin is trusted code by design.
* Secrets that the user writes as literals in places Sponson does not treat as secret-bearing, after Sponson's
  `SECRET_LITERAL` check has been deliberately bypassed (please do report a value the check should have caught).
* `@sponson/sim` (the fake cloud) — it is a test tool, binds to `127.0.0.1` and accepts any token on purpose.
* Denial of service through very large plans, or by holding a scope's lock with legitimate credentials.
* Missing hardening with no demonstrated impact (e.g. headers, best-practice suggestions from scanners).
* Vulnerabilities in dependencies with no reachable path in Sponson — Dependabot handles those; open a normal PR.

## Handling secrets as a contributor

* Tests and scenarios use placeholder values and the sim; never commit real tokens. `pnpm test:live` reads
  credentials from your environment only.
* New output paths must go through `Redactor`, and JSON only through `serialize()` in
  `packages/cli/src/output.ts`. If you add an output channel, add it to the secrets journey
  (`scenarios/journeys/secrets/`).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.