How We Secure DevReview (October 2026)

Originally published on the DevReview blog.

DevReview reads your pull requests. That means you are trusting us with code that isn't public yet. This post lays out what we do to deserve that trust, what outside scanners say about us, and what we have not finished.

This is our own write-up, not an audit. Scores are dated because they change.

What outside scanners say (measured 2026-10-24)

• Qualys SSL Labs: A+ on one endpoint, A on the other. Our site is served from two edge addresses; we report both rather than the better one. Run the test yourself.
• Mozilla HTTP Observatory: B (75), 11 of 12 checks passed. The one we lose points on is Content Security Policy. Our CSP currently runs in Report-Only mode: browsers report violations to us but do not block them yet. We are collecting reports first so that enforcing it doesn't break checkout or sign-in. We plan to switch to enforcement in early November 2026 and will update this post when we do. Run the test yourself.

Your code

• We don't keep your code. DevReview fetches the diff it needs to review, sends it to the model, and posts comments. We don't store the diff, and we don't log the model's raw output.
• Old data is deleted on a schedule. A daily job removes installations that were never completed after 30 days, and error details from failed reviews after 90 days. We checked the first scheduled run in production on 2026-10-24.

What this means for you: if you uninstall, there isn't an archive of your source code sitting on our side.

The doors into our servers

• Webhooks are verified before anything else. GitHub and Stripe webhooks are checked for a valid signature first. Bodies over a fixed size (2 MB for GitHub, 1 MB for Stripe) are rejected with 413 before we parse them.
• Errors don't leak internals. If something fails, you get a generic message. Stack traces and database errors stay in our logs.
• HTTPS only. HSTS is set for two years.
• New free accounts get a short wait. GitHub accounts younger than 7 days can't use the free plan, which keeps throwaway accounts from burning review capacity.
• Referral codes are random. They come from a cryptographic random generator, not a counter you could guess.

How we run things behind the scenes

• Two-step sign-in on every admin account we use to run DevReview (hosting, database, payments, domain, email, source code). One provider (our domain registrar) only offers emailed codes rather than an authenticator app.
• Email that can't easily be spoofed. SPF, DKIM and DMARC all pass, and DMARC is set to quarantine mail that fails.
• Breach monitoring for our domain via Have I Been Pwned.
• Secret scanning before every push. A gitleaks hook blocks a push if it finds something that looks like a key.
• Production dependencies: npm audit reports 0 known vulnerabilities as of 2026-10-22.
• We practiced restoring the database. Our database keeps 6 hours of point-in-time history, and we ran a restore drill on a copy rather than trusting the docs.
• A written first-30-minutes incident card, plus a ledger of every key we hold and how to rotate it.

What is not done yet

We'd rather say this plainly than have you find it:

• CSP is Report-Only, as explained above.
• Per-user rate limits and re-authentication for sensitive actions are built but not shipped yet. They're waiting on a final review.
• CAA DNS records aren't set, because our DNS provider doesn't support them. We're looking at options.

Tips for your side

• Install DevReview only on the repositories you want reviewed, not "All repositories".
• Turn on two-factor authentication on your GitHub account if you haven't.
• If you leave, uninstall the GitHub App. That stops all access immediately.

Found something?

Please tell us. Our security.txt and security page explain how to report a vulnerability. We read every report.