Security

DraftView sits next to your documentation and your repositories, so the bar for handling that content is high. Here is how we approach it, in plain terms.

Infrastructure

How We Handle Your Content

• We read only what a review needs. DraftView pulls the documentation files a pull request touches. We do not clone repositories and we do not crawl the rest of your codebase.
• We keep a copy for the life of the review. Storing the file versions under review is what lets a reviewer come back later, see what changed since they last looked, and take part without a Git account of their own. Delete the review and that copy goes with it.
• Encrypted at rest and in transit. Stored data is encrypted at rest, and every connection uses TLS. Access tokens get a second layer of encryption on top, with keys held outside the database.
• Scoped to your organization. Reviews are visible to members of the organization that owns them, plus anyone you deliberately share a review link with.

Authentication and Access

• Sign in through your Git host or by email. There are no DraftView passwords to leak. Email sign-in uses single-use links that expire quickly.
• Tokens stay on the server. Access tokens are encrypted, refreshed automatically, and never handed to the browser.
• Permissions come from your Git host. We check what you can see on the repository itself rather than keeping a separate permission list that can drift out of date.
• Shared review links are controlled. Links can be password protected, given an expiry, capped by number of submissions, and revoked at any time.

What the GitHub App Can Do

The DraftView GitHub App asks for the smallest permission set that makes the product work, and you see the exact list on the install screen before you approve it:

• Pull requests: read and write, to load a PR and post reviews
• Contents: read, to render the documentation files
• Metadata: read, for basic repository information

Nothing is written to your repository unless a person asks for it. Suggestions and comments are posted to GitHub under the account of the reviewer who sent them, so your PR history shows who actually made the call.

Product Practices

• Dependencies are tracked for known vulnerabilities and updated regularly.
• Production access is kept to the people who need it, with multi-factor authentication on the accounts that hold it.
• Changes run through an automated test suite before they ship.
• Your content is never used to train machine learning models.

Reporting a Vulnerability

If you find a security issue, please tell us before you tell anyone else. Email help@draftview.app with enough detail to reproduce it. We will confirm we received it within two business days, keep you posted while we work on it, and credit you when the fix ships if you would like us to. We will not pursue legal action over good-faith research that avoids privacy violations, data destruction, and service disruption.

Security Questionnaires

DraftView is a small, independent product, so we are honest about scope: we do not hold a SOC 2 report today. If your team needs a security review, a data processing agreement, or the named list of subprocessors, email us and we will work through it with you.