Trust · Security

Security

How we protect your account, your data, and the credentials you connect — at every layer.

Overview

RunMyCrew sits between you and the apps you trust most — your inbox, your CRM, your team chat. We treat that responsibility accordingly. This page documents how we protect data in transit, at rest, in process, and after deletion, plus our process for incident response and vulnerability disclosure.

Authentication

  • Passwords are hashed with Argon2id (memory cost ≥ 64 MiB, time cost ≥ 3). We never store plaintext passwords.
  • Optional Google Sign-In via OpenID Connect. We accept the Google ID token, validate signature + audience + expiry + email_verified, and create or look up a local user.
  • JWT access tokens are HS256-signed, short-lived, and stored in localStorage (not a third-party cookie). The signing secret rotates with each deploy unless explicitly pinned.
  • CSRF on the Google sign-in callback is defended with a short-lived signed state JWT carrying a per-request nonce.
  • Password reset tokens are JWTs with a 15-minute TTL and a dedicated type claim that prevents login tokens from being reused as reset tokens.
  • Rate limits per IP on every auth endpoint (/login, /register, /forgot-password, /reset-password,/google/start, /google/callback).

Encryption

  • In transit. All traffic is TLS 1.2+ with modern cipher suites. HSTS is preloaded (max-age=31536000; includeSubDomains; preload). Marketing site + product app + API are all HTTPS-only.
  • At rest (application). OAuth refresh tokens, API keys, webhook secrets, and any user-supplied credential are encrypted with AES-256 Fernet using a per-deployment master key (ENCRYPTION_KEY) that never leaves the secret store.
  • At rest (database + backups). Postgres storage is encrypted at the volume level by the cloud provider. Nightly dumps are gzip-compressed and stored in a separate volume; rotation is 14 days.

Tenant + data isolation

  • Every API request is authenticated and re-authorized against the requesting user’s workspace membership. Workspace scoping is enforced at the repository layer, not just the router.
  • Workflow execution is isolated per workspace; one workspace’s credentials are never visible from another workspace.
  • Code-execution nodes (Python sandbox) run in a stripped environment with no inherited worker env (verified by a canary test: a worker env var is unreachable from sandboxed user code).

Third-party OAuth handling

  • We only request the minimal scopes required for the connector you actually use. See OAuth Scopes for the per-provider list.
  • Refresh tokens are encrypted at rest and never logged. Access tokens are kept in memory for the duration of a request.
  • Webhook signature verification is mandatory and cryptographically time-safe (hmac.compare_digest equivalent).

Infrastructure

  • Production runs on a hardened single-VPS Docker Compose stack fronted by Caddy. SSH is key-only; password auth is disabled in sshd_config.
  • Container images are built reproducibly in GitHub Actions, signed with cosign attestations, and scanned by Trivy on every push. CRITICAL CVEs block the deploy.
  • Caddy issues + renews Let’s Encrypt certificates automatically. All app responses include modern security headers (HSTS, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy).
  • Operator access to production is restricted to a small allow-list of SSH keys; every ssh session is logged.
  • Database backups are tested for restorability monthly.

Software development practices

  • Code is reviewed before merge to main. CI runs ruff (Python lint), tsc (TypeScript), eslint, and the test suite on every PR.
  • Dependencies are kept current via Dependabot with daily scans and grouped weekly merges.
  • Secret scanning runs pre-commit and on the server (Detect Hardcoded Secrets).
  • Production deploys are automated via GitHub Actions with pinned image digests for atomic rollback.

Incident response

If you suspect a security issue, email security@runmycrew.com immediately. We aim to:

  • Acknowledge within 24 hours.
  • Triage and reproduce within 3 business days.
  • Patch and disclose to affected users within 30 days, sooner if the issue is actively exploited.
  • Notify regulators where required (e.g. GDPR Art. 33 — 72 hours).

We will credit researchers who responsibly disclose, with their consent, in our release notes.

Coordinated vulnerability disclosure

Security researchers acting in good faith are safe-harbored under our Responsible Disclosure policy. Please:

  • Test only against accounts and workspaces you own. Use free-tier accounts to avoid affecting other customers.
  • Do not access, modify, or delete data belonging to other users. Stop and notify us if you encounter such data.
  • Do not perform DDoS, brute-force, automated scanning at scale, or social engineering of staff.
  • Give us a reasonable window to remediate before public disclosure (typically 90 days; faster for trivial issues).

Eligible report categories include but are not limited to: authentication / authorization flaws, broken access control, injection (SQL / template), SSRF, RCE, sensitive-data leakage, broken OAuth handling, and significant denial-of-service vectors.

Contact

Security inbox: security@runmycrew.com
PGP key: published at /.well-known/security.txt (coming soon)