Security / Data handling
Your code is read, not kept.
ScanDrix processes pull request diffs in memory for the length of a review, and does not persist repository content as part of that flow. What does persist is a small set of finding metadata — rule IDs, file paths, severities — because history and audit logs are worth nothing without it.
This page describes that boundary in plain terms: what the review flow does not store, what it does, where a provider sits in the path, and how to report a security issue. It describes product behavior — it is not a compliance attestation, and it does not claim one on your behalf.
01Zero retention
The boundary, stated plainly.
“Zero retention” describes repository content. It is not a claim that nothing about a review is kept, and it is not a statement about your Git host, your cloud account, or any provider you have separately contracted.
- Not persisted
- Diff and file content, expanded context, AST output, and prompt payloads. The review flow works on source in memory and does not write repository content to disk or into a database.
- Retained
- Finding metadata — rule ID, file path, severity, and a stable finding ID — so the dashboard can show history and an audit log means something. On a self-hosted install that metadata lives in your database, under your retention policy.
What sits behind that boundary
No training on your code
Customer source, diffs, and comments are not used to train, tune, or evaluate any model — ours or a provider's. That is contractually enforced where providers allow it, and you can remove the variable entirely by supplying your own provider key.
Secrets redacted before prompts
Entropy scanning and token-pattern detection run over the payload before anything reaches a model. Matches such as cloud keys, personal access tokens, and private keys are replaced with stable placeholders, so a finding about a leaked credential is still reported without the literal value leaving the process.
Your own provider key
Add your own LLM provider credentials under Settings → Providers and requests go to that provider account under your commercial relationship. Bring-your-own-key is available on every plan, and pairs with an internal inference endpoint on air-gapped installs.
Scoped access and an audit trail
Role-based access for workspace members — admin, member, viewer. Audit logs record rule changes, suppressions, key creation and rotation, and integration changes. Team keys are scoped to a team, and rotation takes effect on the next request.
A boundary you can operate
Run the stack in your own VPC, on-premises, or in a network without an internet path, with an internal vLLM or Ollama endpoint. That removes the external model provider from the inference path — it does not remove your Git host, or the release process you now own.
Retention windows, backup schedules, and who can read an audit log are yours to set on a self-hosted install. On the hosted plan they follow the subprocessor terms listed with your documentation request.
02Review data flow
Four hops, from event to comment.
This is the whole path a review takes. Nothing here runs on a repository clone, and nothing writes source content back to storage.
- 01
Webhook ingest
Your Git provider delivers a pull request event to the webhook ingress path over encrypted transport. The shared secret is verified against the raw body before the payload is read, and unsigned or mismatched deliveries are rejected. The provider is acknowledged immediately — the analysis is queued, not blocking.
- 02
AST and taint analysis
The diff is widened with surrounding context so a rule can judge intent rather than a changed line. Files are parsed per language, deterministic checks run on the tree, and taint paths are traced across files. Source content stays in memory through this stage.
- 03
Rules and validation
Active Drixy rules, architecture boundaries, and the blocking severities you configured evaluate that result. Prompts are assembled from the analysis, with suspected credentials already replaced by placeholders, and are sent to the model endpoint you selected.
- 04
Review output
Findings are grouped, de-duplicated, and posted as inline review comments with severity badges and patch suggestions. What remains afterwards is the metadata around them — rule ID, file path, severity — plus the check run the provider records.
What holds at every hop
- Encrypted in transit
- No source content written to disk
- Idempotent retries, dead-letter queue
- Secrets redacted before prompts
Providers still sit in this path. Your Git host sees the webhook and the review it stores, and an external model endpoint processes the prompt under its own terms. Pointing the model endpoint at an internal vLLM or Ollama server keeps inference inside your network; it does not mean the review path has no external dependency.
See what runs inside your boundary03Disclosure
Found something? Tell us directly.
Reports go to one address, and they reach the people who can fix the problem rather than a shared support queue.
security@scandrix.devSend a description of the issue, the component it affects, and steps to reproduce it. We acknowledge reports within two business days and coordinate disclosure with you once a fix is released.
- What to include
- A description of the issue, the component or endpoint it affects, and reproduction steps. Include a proof of concept only if you are comfortable sharing it.
- Acknowledgement
- Reports are acknowledged within two business days of reaching the security address below.
- After acknowledgement
- We confirm what we can reproduce, track the fix, and agree disclosure timing with the reporter before anything is published.
If you would rather start with a mutual NDA or a documentation review before sending details, that is a normal part of an enterprise evaluation.
Audit documentation
Security review documentation, the current subprocessor list, and a DPA are available under NDA on request. Ask for what your reviewers need and we will scope it with you.