How DVSentry protects your code, your scans and your data.

Isolation of scans and code

• No container control for the app. Neither the API nor any worker is given the Docker socket. Only one dedicated scanner-runtime service starts containers, and only after an authenticated request it validates itself.
• A fresh sandbox per scanner job. Each scanner runs in its own short-lived container under the gVisor sandbox (runsc), so it does not share the host's kernel. Production refuses to start the scanner runtime without a sandboxing runtime.
• No network, no privileges. Scanner containers run with no network, as a non-root user, with every Linux capability dropped, no privilege escalation, a read-only file system and your code mounted read-only. All of them share one bounded CPU and memory slice on the host.
• Signed scanner images only. A scanner image runs only by its exact digest, after its Sigstore signature and SLSA build provenance are checked offline against the release built and signed by DVSentry's own build workflow.
• Workers without database access. The repository, web, cloud and AI workers hold no database credential and no platform secret. They claim and finish work through an internal job service over mutual TLS, which checks their results as untrusted input.
• Clones in their own service. Repositories are cloned by a separate fetcher with no database and no platform secrets. A token you give for one scan stays in memory for that scan and is never written to the database.
• Tenant isolation. Every request is checked against your organization's membership. PostgreSQL row-level security adds a second check on sensitive tables, so a request admitted to one organization sees only that organization's rows.
• Scans only what you own. Web and network testing starts only after you prove ownership of the domain with a DNS record, and outbound scan requests refuse private and internal addresses.

More detail: documentation.

Data handling and retention

• Accounts. Passwords are hashed with Argon2. Sessions and access tokens are stored only as hashes. Multi-factor authentication with an authenticator app is available, and passkeys where enabled.
• Secrets you save. Credentials you choose to keep are stored encrypted until you delete them. Secret scanners report where a secret is, with its value redacted.
• Data we cannot read. Secure share and the password vault are encrypted in your browser. Their keys never reach DVSentry, so we cannot read or recover them.
• AI features. Only when you use them, the finding details needed to answer are sent with secrets removed. Your repositories are not sent to AI providers.
• How long we keep it. Reports for the period your organization sets (default 90 days, 30 to 365), with their findings and evidence. Audit events up to 365 days. Sign-in records and security events one year. Repository copies are deleted when the scan ends. Exports 72 hours.
• Audit trail. Organization audit events are append-only in the database and sealed into a hash chain, so a changed or removed event shows.

The full list is in the Data Retention Disclosure and the Privacy Policy.

Backups and recovery

• Continuous backups. The database is dumped daily and its write-ahead log is archived continuously, so it can be restored to a point in time.
• Encrypted, off the server. Backups are encrypted before they leave the server and are kept in a separate Google Cloud Storage bucket in Mumbai with a locked 30-day retention policy: nobody, including us, can delete a backup before it is 30 days old.
• Restore drills. A restore is rehearsed at least monthly on a throwaway machine, and an alert fires if no drill has been recorded for 35 days.
• Deleted data. Backups roll off within 35 days, so deleted data can remain in them until then. They are used only to restore the service.

Reporting a vulnerability

• Write to us. Send reports to security@dvsentry.com. Our contact details are also in security.txt.
• Safe harbour. The Vulnerability Disclosure Policy describes what is in scope and our safe harbour for good-faith research.
• Personal data breach. If a breach affects your personal data, we tell you without delay and report it to the Data Protection Board of India and to CERT-In where the law requires, as the Privacy Policy describes.
• Browser code you can check. The hashes of the vault and Secure share code are published at client hashes and in a release-signed manifest.