We ask founders to hand us the most sensitive asset they own. This page states exactly what we take, what happens to it, and what survives the scan — in enough detail that you can hold us to it.
We ask for read access because a scanner that can write to your repository is a scanner that can be turned against you. The narrower permission is also the one we would tell you to demand of any vendor, including us.
During early access, every scan is run by hand by a senior engineer on a machine kept for that purpose. Your repository is cloned to it, analysed, and the working copy deleted when your report is delivered. Nothing is shared between customers, and no repository sits on it between engagements.
The tools we run are open-source static analysers — gitleaks for committed secrets, osv-scanner for dependency vulnerabilities, and Semgrep for code patterns, alongside checks we wrote ourselves. They parse your source; they do not execute it. We also never install your dependencies, because installing a package runs whatever that package's author decided should run. That costs us some coverage on repositories with no lockfile, and we would rather say so than execute untrusted code.
We name the tools deliberately. You can look up exactly what they do and what they miss, which is a better basis for trusting a report than taking our word for its coverage.
By default, nothing. Your repository is destroyed with the scan container, and when your report is delivered we purge our copy of it — findings, code snippets and all. Retaining anything beyond that is something you opt into, not something you opt out of.
| What | Retained |
|---|---|
| Your repository | Never. The working copy exists on the scanning machine for the duration of the engagement and is deleted when your report is delivered. |
| Finding snippets | The specific lines attached to a finding. Held while your report is being produced and delivered, then purged. Kept longer only if you ask us to — typically because you want a re-scan or a remediation sprint that carries them forward. |
| Repository metadata | Name and the commit SHA scanned, so a re-scan can tell you what changed. Purged with everything else unless you opt in. |
| Your report | Yours to keep, permanently. Our copy is deleted 30 days after delivery — enough time to download it again or pass it round internally, and no longer. Kept beyond that only if you ask us to. |
| Scan logs | Structured events only: rule identifiers, severities, file paths, line numbers. Source lines and secret values are stripped before anything is written to a log, by the scanner itself rather than by policy. |
We are deliberate about the second row. Plenty of vendors say "we never store your code" while quietly keeping exactly this. We would rather draw the line where it actually is — and then default to the safer side of it.
If you do want us to keep your findings, say so and we will. Working through a remediation sprint is much easier when we still have the report. But that is your decision to make, and it is recorded against the scan.
Deop Inc. is a Canadian company based in Vaughan, Ontario, and a Microsoft Solutions Partner for Cloud & AI Platforms and Security. During early access your repository is scanned in Canada, and your report is written and delivered from here. As the product moves onto its own infrastructure, that infrastructure is Microsoft Azure's Canada Central region.
Three qualifications we would rather state than bury. This website is served through Cloudflare, whose network is global, so web traffic in transit may be handled outside Canada. Enterprise engagements are sometimes scoped to a different region entirely, at the customer's request. And model assistance runs its inference outside Canada — your code does not go with it, and the section below says exactly what does. If you have a residency requirement, tell us and we will write it into the engagement rather than ask you to trust a default.
A model drafts a first pass at each failing finding, from that finding's metadata only — rule identifier, category, severity, file path, line numbers. Your repository contents are never sent, and neither are the code snippets behind a finding.
That boundary is an allow-list of the fields we send, not a list of things we strip out. A list of things to strip is a list somebody has to keep complete. Your code is not used to train anything, by us or by anyone else.
Every draft is marked as a draft until an engineer has read it, and a report cannot be delivered with unreviewed drafts in it unless somebody says so deliberately. The judgement you are paying for is a person's — the model shortens the blank page, not the read.
That drafting runs in Azure OpenAI, and inference runs outside Canada. Azure no longer offers a pay-per-token model that stays in the country — the in-region option is reserved capacity at roughly a thousand times the cost, which we are not buying at this volume. So the precise claim is that your code never leaves Canada, while the metadata used to draft a finding is processed elsewhere. Those are different sentences and we would rather write both than blur them into one.
A VibeXray report is a professional opinion on production readiness, based on automated analysis of a specific commit and the judgement of a senior engineer. It is not a certification, an audit, a penetration test, or a guarantee that your application is secure. No assessment finds everything. A clean report reduces your risk; it does not eliminate it, and it does not transfer liability to us.
If you believe you have found a vulnerability in VibeXray itself, tell us through our security contact form. We will acknowledge within two business days and keep you updated until it is resolved. We will not pursue you for good-faith research, and we will credit you if you want the credit.
We audit other people's production readiness for a living. Holding ourselves to a lower standard would be indefensible.