Trust centre
Trust
Where we actually are
SuperDiffs is a pre-beta product. That has consequences a security reviewer needs stated directly rather than inferred: there is no SOC 2 report yet, no completed penetration test, and several subprocessors listed below are ones we intend to use rather than ones we use today. Each is marked.
What is already true is architectural, because it was designed in rather than certified after: your code is analysed in a disposable sandbox, the credential that reaches it is a one-hour read-only token for a single repository, and nothing you give us trains a model.
Architecture in six facts
Analysis runs in a disposable sandbox
Your code is checked out inside a per-review isolated instance with default-deny egress: it can reach the package registries the analysers need and nothing else. The instance is destroyed when the review ends. No customer code is ever executed on the machines that hold platform credentials.
One read-only, repository-scoped token
The only credential that crosses into the sandbox is an installation token limited to a single repository, contents-read, valid for one hour. It cannot post, cannot read a second repository, and cannot be widened by the code that requests it — the permission set is a frozen literal, and a test asserts that nothing reachable from that module can mint a posting token.
The signing key is never in process memory
The GitHub App private key lives in a hardware-backed key store. Tokens are minted by signing a JWT through the key service, so a compromise of an application process does not yield a key that could be replayed against every installation.
Instructions come from people, not from text
Bot commands are honoured only from a comment written by someone with write access, checked against the permission API at the moment of use. A command sitting in a pull-request description, a code comment, or the diff itself is inert no matter how it is phrased.
Both directions are sanitized
Untrusted repository content is stripped of invisible and tag-smuggled characters and structurally delimited before a model sees it. Everything we post is stripped of image channels, raw HTML, and foreign links, so a review comment cannot become an exfiltration channel.
No training on customer code
Customer code is used to produce your review and nothing else. It is not used to train or fine-tune any model, and cross-customer quality work uses metadata about our own output — which rule fired, whether it was addressed — never code.
The engineering detail behind each of these — permission scopes, the sanitization rules, the threat model — is in the security documentation.
Compliance status
| Item | Status | Detail |
|---|---|---|
| SOC 2 | In progress | Type I is targeted before general availability, with the Type II observation window opening immediately after. No report exists today, and we will not describe the programme as "SOC 2 compliant" until an auditor has issued one. |
| Zero data retention (model providers) | In progress | Zero-retention amendments with both model providers are targeted before beta. Until each is executed, this page names the provider and its published default rather than implying an agreement we do not have. |
| Zero-retention mode (our systems) | In progress | An enterprise-tier flag that suppresses evidence-snippet storage and cross-repository learnings, so nothing derived from your code outlives the review. The entitlement exists in code; the enforcement path is being completed alongside the enterprise tier. |
| GDPR | In progress | Data processing agreement drafted and available for signature; standard contractual clauses attached for transfers outside the EEA. Subject-access and erasure requests run through the same tenant-erasure pipeline as an uninstall. |
| Penetration test | Not started | An external test of the sandbox boundary and the token broker is scheduled before general availability. The summary letter will be linked here when it exists. |
| Training on customer code | N/A | We do not train models. We do not fine-tune on customer code, and we do not send customer code to a provider under terms that permit training on it. |
Data handling and retention
| Data | Where it lives | Retention | Under zero-retention mode |
|---|---|---|---|
| Repository checkout (working copy) | Sandbox instance | Destroyed with the sandbox at the end of the review | Same |
| Git bundle used to seed a sandbox | Object storage, encrypted per installation | 7 days, then swept | Not written |
| Finding evidence snippets | Postgres | Life of the finding — they are what lets us re-anchor a comment after a force-push without re-reading the old commit | Not stored; findings degrade to file-level anchors after a force-push |
| Review and pull-request metadata | Postgres | 13 months, for usage history and billing disputes | Same — no code content is involved |
| Learnings (embedded team preferences) | Postgres (vector index) | Until deleted by the org, or on uninstall | Disabled |
| Prompts and completions | Model provider | Provider default until a zero-retention amendment is executed | Zero retention once the amendment is in force |
| Everything, on uninstall | All stores | Deleted within 30 days through a single audited erasure pipeline | Same |
Zero retention, stated precisely
“ZDR” is used loosely in this market to mean two different things, and the difference matters:
- At the model provider — whether prompts are retained by the provider after the response. This requires an executed amendment with each provider. Ours are targeted before beta and are not in force today. Until they are, treat provider-side retention as that provider’s published default.
- In our systems — whether we store anything derived from your code after the review. This is an enterprise-tier mode that suppresses evidence-snippet storage and cross-repository learnings. The entitlement exists in code; the enforcement path ships with the enterprise tier.
Both are marked in progress in the table above. Neither is a checkbox we have already ticked, and a vendor telling you it has both today, pre-beta, is worth a follow-up question.
Deletion
Uninstalling the GitHub App starts an audited erasure of everything belonging to that installation — reviews, findings, evidence snippets, learnings, bundles — within 30 days. Subject-access and erasure requests under GDPR run through the same pipeline, so there is one code path to verify rather than two. Write to privacy@superdiffs.com.
Subprocessors
Everything that could touch customer data, whether or not it does today. The status column is not decoration: a list that quietly mixes vendors we use with vendors we plan to use is the kind of small dishonesty that makes the rest of a trust page worthless.
| Subprocessor | Status | Purpose | What reaches them | Region |
|---|---|---|---|---|
| Anthropic | Planned | Primary model provider for review passes and verification. | Diff content, file excerpts needed for context, and repository instruction files. Never credentials — secrets are redacted before a prompt is built.Zero-retention amendment targeted before beta. Until it is executed and named here, treat provider-side retention as the provider’s published default. | United States |
| OpenAI | Planned | Secondary model lane and the offline evaluation judge. | Same class of content as the primary lane when the secondary lane is selected; benchmark datasets during evaluation runs.Zero-retention amendment targeted before beta. | United States |
| Amazon Web Services | In use | Control plane: application hosting, Postgres, object storage, key management. | Review records, findings and their stored evidence snippets, repository and pull-request metadata, encrypted git bundles. | eu-central-1 (primary) |
| Hetzner | In use | Sandbox fleet — the isolated machines that check out code and run analysers. | A working checkout of the repository under review, for the lifetime of the review only.Sandbox instances are destroyed after each review. Nodes hold no platform secrets — only the pass-through one-hour repository token. | Germany / Finland |
| Temporal Cloud | Planned | Durable orchestration of review workflows. | Workflow state: identifiers, commit SHAs, and stage status. No file contents. | European Union |
| Stripe | Planned | Payments and subscription management. | Billing contact, organisation name, payment method held by Stripe. | United States / Ireland |
| PostHog | Planned | Product analytics for the web application. | Account identifiers and in-app events. No repository content, no diff content, no finding text. | European Union |
| Sentry | Planned | Error and performance monitoring. | Stack traces and request metadata. Code content is scrubbed before an event is sent. | European Union |
| Vanta | Planned | Compliance automation and continuous control monitoring. | Employee and infrastructure metadata. No customer content. | United States |
Material changes to this list are announced 30 days before they take effect, to the billing contact and in the changelog. Customers on a signed DPA may object within that window.
Egress addresses
Static egress addresses are assigned when the production fleet is finalised, ahead of beta. They will be published here and in a machine-readable file at /.well-known/egress.json, with 30 days notice before any change.
Machine-readable location: /.well-known/egress.json. It currently lists no ranges, because we would rather publish nothing than publish an address that turns out to be wrong in your firewall.
If your GitHub is behind an allow-list and you need addresses before we finalise them, say so — knowing that is what decides whether the fleet needs static addressing at all.
Availability and incidents
- Status and incident history: https://status.superdiffs.com.
- We do not publish an uptime SLA yet. Publishing one before we have operated at load would be a number invented for a procurement form. Enterprise agreements carry a contractual commitment.
- A review that fails is retried; a review that cannot complete reports a failed check run rather than posting a partial review. Silence and half a review are the two worst outcomes and both are designed out.
- Security incidents affecting customer data are notified without undue delay, and in any case within 72 hours of confirmation, per the DPA.
Reporting a vulnerability
Email security@superdiffs.com. Acknowledgement within 48 hours, triage within 5 working days. Machine-readable contact: /.well-known/security.txt.
Safe harbour
Test only against repositories you own. Do not access another customer’s data, do not degrade the service for others, and give us a reasonable window to fix what you find. Stay inside that and we will not pursue legal action for the research.
For your questionnaire
Most security questionnaires are answered by this page plus the security documentation. For the rest — a completed CAIQ, an architecture walkthrough, or the DPA signed — write to security@superdiffs.com and you will get a person, not a portal.
- Terms of Service · Privacy Policy · Data Processing Addendum
- Subprocessor list · Acceptable use
- Benchmark methodology — how we intend to prove the quality claims rather than assert them.