Skip to content
superdiffs

Security

Vulnerability disclosure policy

If you have found a way to read code you should not be able to read, escape the sandbox, or make the reviewer act on text it should have ignored, this page is how to tell us and what happens next.

This is the policy referenced by /.well-known/security.txt.

How to report

Email security@superdiffs.com. One report per issue. Plain text, or a PDF if you have screenshots — please do not file it as a public GitHub issue or a pull request comment, for the obvious reason.

What we commit to

Response commitments
StageWithin
Acknowledgement that a human has it48 hours
Triage decision — accepted, duplicate, or not a vulnerability, with reasoning5 working days
A remediation plan with a date, for accepted reports10 working days
Notification when the fix shipsOn deploy

We do not run a paid bounty programme yet, and we will not imply one by calling a credit a reward. What you get is a fast human response, credit in the changelog if you want it, and a straight answer if we disagree.

In scope

  • https://superdiffs.com and its API, including the dashboard and the authentication flow.
  • The GitHub App: permission scoping, token minting, and webhook verification.
  • The sandbox boundary — anything that gets code or a process out of a review instance, or reaches a network destination the egress policy should have denied.
  • Tenant isolation — any path by which one installation’s data, findings, or learnings become visible to another.
  • The outbound sanitizer — a comment we would post that carries an image reference, raw HTML, or a link to a host outside the allow-list.
  • Prompt injection with a real consequence: making the reviewer post something it should not, leak content from outside the pull request, or act on a command from unprivileged text.

Out of scope

  • Missing security headers, cookie flags, or TLS configuration with no demonstrated impact.
  • Rate limiting and volumetric denial of service. Please do not load-test production.
  • Reports produced solely by a scanner, with no analysis of whether the finding is reachable.
  • Social engineering of our staff or our vendors, and physical attacks of any kind.
  • Self-XSS, clickjacking on pages with no state-changing action, and issues requiring a compromised device.
  • The reviewer being wrong about your code. That is a quality bug and we want it — send it to support@superdiffs.com — but it is not a vulnerability.

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.

Concretely: if you stay within this policy, we will not pursue or support legal action against you for the research, and we will say so in writing if a third party asks. If you are unsure whether something is in bounds, ask first — an email costs you nothing and the answer is usually yes.

What to include

  1. A description of the issue and what an attacker gains from it.
  2. Exact reproduction steps, including the repository you tested against.
  3. Affected URL, endpoint, or component.
  4. Any proof-of-concept code or requests. Please redact tokens and other people’s data from anything you send us.
  5. Whether you want credit, and under what name.

Disclosure

We aim to fix and ship, then publish. Our default is coordinated disclosure 90 days after the report or on the day the fix is deployed, whichever is sooner; if a fix will take longer, we will tell you why rather than let the clock run out quietly. Issues that affected customer data are notified to affected customers regardless of whether they are disclosed publicly.

Background on the design these reports are testing: security documentation and the trust centre.