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

# Security

> How to report a vulnerability and what we do with your data.

## Reporting a vulnerability

If you've found a security issue in Riftmap, please **disclose it privately** rather than posting it publicly.

Email **[hello@riftmap.dev](mailto:hello@riftmap.dev)** with reproduction steps and any relevant version, request, or environment info. We aim to acknowledge within two business days.

<Card title="Email security disclosures" icon="envelope" href="mailto:hello@riftmap.dev">
  Goes straight to maintainers. Please use this channel rather than opening a public issue anywhere.
</Card>

### What's in scope

* The hosted product at `app.riftmap.dev`, its API at `api.riftmap.dev`, and the marketing site at `riftmap.dev`
* The static schema and docs at `docs.riftmap.dev` and `app.riftmap.dev/openapi.json`

### What's out of scope

* Reports based purely on automated scanner output without a working proof‑of‑concept
* Volumetric DoS / brute-force findings against the hosted product (we have rate limits; please don't try to find their thresholds)
* Issues that require a privileged position the attacker shouldn't have (e.g. "if I steal an owner's API key, I can act as that owner")
* Social engineering of staff or customers

### What we'll do

1. Acknowledge the report.
2. Triage and confirm the issue, or push back with reasoning.
3. Develop and ship a fix; coordinate disclosure timing with you.
4. Credit you in release notes if you'd like (and if the fix is shipped).

We don't currently run a paid bug-bounty program, but we do appreciate the work and will say so publicly when a fix lands.

## What Riftmap does with your data

Short version:

* **Source code is never stored.** Repos are shallow-cloned (depth=1) into a per-scan temporary directory at `0700` permissions, parsed for dependency manifests, and `rmtree`'d in a `try/finally`. Only the dependency graph metadata persists in the database.
* **Contributor data is opt-in.** The ownership / bus-factor signal is off by default. When a workspace enables it, Riftmap extracts contributor names and emails from git **author metadata only** (no commit messages, diffs, or file blobs) to compute a per-repo bus factor. This personal data is workspace-scoped and cascade-deleted on workspace deletion and the 30-day GDPR purge; the API ever returns contributor **names only**, never emails.
* **Tokens are encrypted at rest** with Fernet. The encryption key lives in env (`ENCRYPTION_KEY`) and is required at startup outside dev mode.
* **Cross-workspace isolation** is enforced at every endpoint: workspace API keys can't reach another workspace's data, and foreign-workspace requests return 404 (not 403, to avoid leaking existence).
* **GDPR data export** is available at `GET /workspaces/{id}/export` (owner/admin only). Account deletion is at `POST /auth/account/delete` with a 30-day grace period.

## Auth design (one-pager)

| Surface          | Auth                                                    | Notes                                       |
| ---------------- | ------------------------------------------------------- | ------------------------------------------- |
| Browser sessions | JWT cookies (15-min access, 30-day refresh, `HttpOnly`) | Set by `/auth/login` and OAuth callback.    |
| API integrations | Workspace API keys (`rfm_live_…`)                       | SHA-256 hashed at rest; raw key shown once. |

Mutations are rate-limited per identity. Cross-workspace access returns 404. See [Authentication](/authentication) for the header conventions and limit specifics.

## Responsible exposure decisions

We deliberately:

* **Disable live `/openapi.json` and `/docs` in production** — agents read the static schema published from CI at [`app.riftmap.dev/openapi.json`](https://app.riftmap.dev/openapi.json), which is reviewed and exported deliberately rather than auto-introspected from a running prod server.
* **Return 404, not 403, for cross-workspace requests** — so attackers can't enumerate which workspace IDs are real.
* **Return rate-limit errors with a precise `Retry-After`** rather than silently dropping requests — predictable behaviour beats opaque failure.

If you find a place where these defaults haven't been applied, that's exactly the kind of report we want.