Security

Security at DevReins

We take security seriously. If you find something, we want to know. Here's how to reach us and what to expect.

Last updated: July 11, 2026

How to reach us

Email support@devreins.ai with [SECURITY] in the subject line. Include enough detail to reproduce the issue - steps, affected endpoint or file, and impact. We acknowledge within 24 hours Monday-Friday and aim for a first triage within 72 hours.

We follow a 90-day responsible disclosure window from the date we acknowledge your report. We'll keep you posted on progress and coordinate any public disclosure with you; if a fix needs longer than 90 days we will ask, not demand.

PGP key

If your finding is particularly sensitive, encrypt your email. Ask us to send our PGP key directly when you open the thread and we'll reply with the key and its fingerprint.

What's fair game

In scope

  • Viewer Node.js server (viewer/server.mjs) and its REST + WebSocket APIs
  • Viewer PWA assets and service worker (viewer/public/, including sw.js)
  • /proxy/* localhost port gateway
  • /u/* arbitrary-URL gateway (SSRF hardening)
  • The DevReins relay (relay.devreins.ai) and account front door (app.devreins.ai) — connection brokering, login, and the E2EE layer between phone and machine
  • Marketing site (landing/ on devreins.ai)
  • Bring-your-own-tunnel guidance (our configuration guidance, not the tunnel provider itself)
  • Native iOS shell - when shipped (planned alongside Pro)

Out of scope

  • Third-party libraries - xterm.js, Prism, gorilla/websocket, cloudflared. Report those upstream.
  • Cloudflare infrastructure itself
  • Social engineering or physical attacks
  • DoS / volumetric / flood attacks (rate-limit findings are in scope; sustained floods are not)
  • Detection-evasion or attack-tooling research
  • Automated scanner output with no manual verification or working PoC
  • Dormant code paths that ship no traffic today — e.g. the unreleased native-mobile stack — until they go live in a release

How your code stays yours

DevReins is self-hosted by design: the server runs on your dev machine, and your code, files, terminal, and agent transcripts are never stored on our infrastructure.

  • Outbound-only connectivity. Your machine dials out to the relay; there are no inbound ports, no port forwarding, and no user-configured tunnels.
  • End-to-end encryption, on by default. Phone and machine agree keys via X25519 and encrypt every WebSocket frame with AES-GCM. The relay forwards ciphertext it cannot read — in account mode the key agreement is relay-blind.
  • Device-scoped auth. Each phone or browser holds its own token; you can log out a single device from Settings.
  • Append-only audit log. Every remote action is recorded on your box, where you can read it — not on ours.

You're covered

If you research in good faith and follow this policy we will not pursue legal action against you and will not refer your report to law enforcement. Good faith here means:

  • You limit testing to accounts and instances you own, or those you have explicit written permission to test.
  • You do not disrupt service for other users (no sustained floods, no resource exhaustion attacks).
  • You do not access, modify, or exfiltrate user data beyond the minimum needed to prove the issue.
  • You do not test against real users without their consent.
  • You report what you find to support@devreins.ai and give us the 90-day window before public disclosure.

We extend the same good faith back: we will not punish honest mistakes made in the course of legitimate security research, and we will credit you on this page (with your consent) regardless of payout tier.

CFAA and DMCA safe harbor. Research conducted in good faith under this policy is authorized access for purposes of the U.S. Computer Fraud and Abuse Act (CFAA), the Digital Millennium Copyright Act (DMCA) anti-circumvention provisions, and any state laws with similar prohibitions (such as California Penal Code 1030 and the UK Computer Misuse Act). We will not pursue civil action against you and will not initiate or support law-enforcement action for activity that complies with this policy. If a third party brings legal action against you for activity conducted under this policy, we will take steps to make it known that your actions were authorized. This safe harbor extends only to good-faith research and does not waive your obligations to comply with any applicable law unrelated to this policy. Modelled on the EFF vulnerability-disclosure template.

Payout table

Valid, in-scope findings are paid by severity. We pay on receipt of a valid invoice (Stripe transfer or Open Collective). Researchers under sanctions or in embargoed jurisdictions cannot be paid but are still credited.

Severity Payout (USD) Definition
S1 Critical $500 - $2,000 RCE, full auth bypass, unauthenticated takeover of a paired session.
S2 High $200 - $500 Sensitive data leak, persistent XSS in an authenticated context, privilege escalation, SSRF to internal services.
S3 Medium $50 - $200 CSRF on sensitive actions, open redirect, reflected/DOM XSS, info disclosure with limited impact.
S4 Low / Info Hall of Fame credit Hardening opportunities, missing security headers, low-impact issues with no direct exploit path.
Payment mechanics

Payouts go out via Stripe transfer or Open Collective on receipt of a valid invoice. Final severity classification is at our discretion; we will explain our reasoning if you disagree and we will not lowball in silence.

Researchers may also opt to take the equivalent value in DevReins Pro for life instead of cash when Pro launches. Stack-up is allowed: multiple distinct findings each earn their own payout.

S1 - S4 severity levels

Full severity definitions and incident response procedure will be published in the public repository (docs/INCIDENT_RESPONSE.md) at launch. Quick reference:

Level Description Example
S1 Critical Full auth bypass or RCE Unauthenticated access to any protected route
S2 High Significant data exposure or privilege escalation Path traversal reading arbitrary files, SSRF to internal services
S3 Medium Limited impact, requires user interaction or special conditions Stored XSS in a low-privilege context, CSRF on non-sensitive actions
S4 Low / Info Hardening opportunities, no direct exploit path Missing security header, verbose error messages

Researchers who helped

We'll list everyone who reports a valid in-scope finding here, unless they prefer to stay anonymous.

No disclosures yet. You could be first.