Skip to main content

​
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 with reproduction steps and any relevant version, request, or environment info. We aim to acknowledge within two business days.

Email security disclosures

Goes straight to maintainers. Please use this channel rather than opening a public issue anywhere.

​
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.
  • Scanned repos are treated as hostile input. Clones run with symlinks disabled (core.symlinks=false) and the file walks skip symlinks and never read outside the clone tree — a malicious repo can’t point the scanner at /etc/passwd or the worker’s environment. Working trees above a total size cap are rejected before parsing.
  • The scan worker can’t be aimed at internal networks. Every organisation URL and clone URL must be public https:// — hosts resolving to private, loopback, link-local, or cloud-metadata addresses are rejected at registration (422) and re-checked at connect time. Upstream error bodies are never echoed into scan results.
  • 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)

Mutations are rate-limited per identity. Cross-workspace access returns 404. Configuration mutations — registering a connected org, triggering a scan, creating or rotating API keys — require the Owner or Admin role for session users (workspace API keys are owner-equivalent by design). Password-reset links are single-use, and login timing is constant for unknown emails. See 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, 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.

​
Audit history

Riftmap goes through recurring full-codebase security audits — most recently April 2026 and July 2026 — covering the backend, the scanner pipeline (untrusted repository content), the frontend, dependencies, and infrastructure. Every finding is remediated with an accompanying regression test, and the complete remediation records are public:
  • July 2026 audit & remediation record — no critical findings; all findings fixed before publication.
  • Verified controls table — every documented control cross-checked against the code, including what we deliberately risk-accept. This is also where the user-facing security summary on the marketing site is sourced from.