Security
We read your code. We don’t keep it.
You’re trusting a security product with your source. Here’s exactly what happens to it, what we keep, and who can see what.
- We keep no copy of your code.
- Each Assessment runs in a single-use worker with a short-lived token scoped to your installation, and the clone is deleted when it ends.
- Evidence is a file, a line, a commit and our note. You see the code on GitHub, under your own access.
- What we keep about your App is encrypted, private to your team, and never published.
- This public website holds no code, no keys and no customer data.
During an Assessment
An Assessment checks one Advisory against one App. It runs in an isolated worker created for that Assessment alone.
- The worker gets one short-lived GitHub token, scoped to your installation, from a separate token service. It never holds the GitHub App’s private key.
- It fetches the commit it needs onto its own temporary disk.
- When the Assessment ends, the clone is deleted and the worker is destroyed. That includes Assessments that fail or time out.
- No code goes into our database, logs, caches, backups or error reports. Working transcripts are discarded. Only the final Verdict is stored.
What we keep
We keep understanding, written in our own words, not code.
- Verdicts: the outcome, our reason, and evidence as file, line, commit and a note we write. Notes paraphrase; they never quote your code.
- An App profile: derived facts like the framework and version, which features and packages are in use, where untrusted input enters, the runtime declared in your Dockerfiles, and which packages are dev-only. It lets each Assessment start warm instead of from scratch. It never contains code or secrets.
- Your inventory: package names and installed versions, so we know which Advisories match.
If a worker comes across a secret in your repository, it doesn’t report it and doesn’t store it.
How you see evidence
Every piece of evidence links to a GitHub permalink for that line at that commit. The code is shown by GitHub, under your own GitHub access, not served from our storage. Someone without access to your repository can’t see it through us.
Who can see what
A list of who runs which vulnerable version is a target list, and a Verdict that says where untrusted input reaches vulnerable code is a map. We treat them that way.
- Inventories, App profiles and Verdicts are encrypted at rest and shown only to the App’s owners.
- None of it is ever public. Advisory profiles on this site describe Advisories, never customers, and never say how many Apps match an Advisory.
- Advisory profiles describe the conditions for being affected, never a working exploit.
How it’s built
Four parts, each with its own credentials:
- The public website (this one) and the web app. They never hold code or the GitHub App’s private key.
- The store of inventories, App profiles and Verdicts.
- A token service, the only place the GitHub App’s private key lives. It issues one short-lived, installation-scoped token per Assessment.
- The Assessment workers, the only place your code ever exists, and only for the length of one Assessment.
The GitHub App asks to read code and to write pull requests and checks. Nothing more.
Model providers
Assessments use Anthropic’s Claude models. Code is sent to Anthropic only under a zero data retention agreement. That agreement is in place before we assess any customer’s code, and our terms say so.
Your running systems
Today we read code; we don’t run it. When the Sandbox ships, it will run a copy of your App that we build from source, in isolation, with no outbound network access. We will never attack your staging, preview or production environments.
Questions
If your team needs more detail before connecting an App, ask us through the design partner form. We’ll answer in writing.