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. |
| 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.
Two 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. And enterprise engagements are sometimes scoped to a different region entirely, at the customer's request. If you have a residency requirement, tell us and we will write it into the engagement rather than ask you to trust a default.
During early access there is no AI in the pipeline at all. Your report is written by the engineer who read the findings. Your code is not sent to any inference service, and neither are your findings.
When we do introduce model assistance, it will draft from findings metadata only — rule identifiers, categories, severities, file paths, line numbers — and never your repository contents. That boundary is a design decision rather than a setting, and this page will say so before it ships, not after. Your code is not used to train anything, by us or by anyone else.
A VibeXray report is a professional opinion on production readiness, based on automated analysis of a specific commit and the judgment 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 at security@vibexray.com. 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.