Security

The short version. The full, code-level detail — data-flow diagram, threat model, permissions, encryption, retention, audit log, incident response — is in TRUST.md.

What runs where

The scanner runs inside your GitHub Actions, on your runner. Mendr's hosted App never clones or reads your code — it holds checks: write and metadata: read only, and receives only what your CI posts to it: a signed findings report per scan and, on a migration run, a redacted diff hunk of the proposed swap for display. Scans run on every push, every pull request, a daily schedule and on manual dispatch.

One permission is optional: actions: write. Grant it and clicking Approve on a finding starts your migration workflow at once; without it, that workflow's own schedule carries approvals out within hours. The permission lets the App start or cancel workflow runs in your repository and nothing more — no contents, no pull requests, no code. The migration itself always runs in your CI with your workflow's token: it verifies the swap on a throwaway copy (type-check, build, tests, and your eval if configured) and opens one pull request only if all of that passes. The App never touches your default branch and never merges (auto-merge is disabled for the beta), and a resolution is confirmed only by the next completed scan, never by the merge event.

Enforced in code, not just promised

• Nothing about your repository is uploaded by the scan. The audit sends nothing; a build-time test runs it under a preload that makes every network primitive throw, and it must still pass. Its one outbound request in CI is a GET of the signed retirement registry, which carries nothing of yours — and a stale or unsigned registry makes the run inconclusive, never clean. Run it fully offline yourself with --offline.
• Secrets redacted. Everything that could leave — the tracking-issue body, every stored snippet and the diff hunk sent on a migration run — passes through the same secret redaction, tested on every build.
• No stored credentials. No GitHub tokens or provider keys are stored; findings and migration reports are encrypted at rest, field by field (AES-256-GCM), with a key kept outside the database; /healthz on the App reports whether encryption is on and whether the newest sealed report opens. A code test fails if a credential-shaped column is ever added.
• Least privilege. The audit workflow the App generates asks for contents: read + id-token: write (to prove the run to the App); the migration workflow adds contents: write + pull-requests: write for its one branch and one PR; the CLI's tracking-issue workflow asks for contents: read + issues: write; the App asks for checks: write + metadata: read (plus the optional actions: write, which only starts workflows). Nothing modifies your default branch; nothing merges.

Your data, your control

Uninstalling the App deletes everything stored for its repositories — runs, migration reports, approvals, acknowledgements — and reinstalling restores nothing (verified on a real uninstall); removing a repository or clicking "Delete stored data" removes the same for that repository. The App keeps at most the newest 100 runs and 100 migration reports per repository. See Privacy.

Where it runs

The App (Hono) runs on Render and keeps its Postgres database on Neon; this site is static on Vercel; sign-in is GitHub OAuth. Those are the only four providers that handle your data. The App carries no analytics SDK and no third-party trackers. Uploads from your CI are authenticated with GitHub OIDC tokens, so no shared secret exists to leak.

Supported versions

Only the newest tagged release receives fixes; a fix ships as the next tag, never a moved one. See the changelog.

Reporting a vulnerability

Use GitHub's private vulnerability reporting: github.com/ajitheee/mendr/security/advisories/new. Expect acknowledgement within three business days and a fix as a new tag with the advisory named in the changelog. Full policy and safe-harbour terms: SECURITY.md. How we handle a confirmed incident: INCIDENT-RESPONSE.md.

Mendr is beta software (public beta from 20 September 2026). This page describes the current, real posture; it is corrected in lock-step with the code whenever a claim changes.