FAQ
Questions, answered
The things security and compliance teams ask us most. Still stuck? support@cvet.dev.
What is CVET, in one sentence?
The evidence layer between your security scanners and your auditors — it turns raw findings into continuous, framework-mapped, audit-ready proof.
How is it deployed?
As a single Go binary plus PostgreSQL, on your own infrastructure. It runs self-hosted or fully air-gapped, so your evidence never leaves your walls — a strong fit for EU data-residency requirements.
Which frameworks does it cover?
Each finding is mapped once to the controls it satisfies across ISO/IEC 27001, NIS2, the Cyber Resilience Act (CRA) and SOC 2. DORA mapping is on the roadmap.
How does CVET access our code?
Through named credentials you enter once. They’re encrypted at rest (AES-256-GCM), never shown again, and every use is written to a tamper-evident, hash-chained access log — so you can prove exactly when a credential touched your code. See the Services page for detail.
Which scanners does it use?
It bundles Trivy and Semgrep and runs them for you, and it can also ingest output from scanners you already run. Everything normalises into one system of record.
What's the difference between Detector and Resolver?
Detector finds and maps every issue across your frameworks. Resolver adds the proof that risks get fixed — remediation traceability (found → fixed → scan-verified), a tamper-evident evidence log, and auditor export packs. See Pricing.
Is our data isolated from other customers?
Yes — because you run your own instance. There’s no shared multi-tenant database; your evidence lives on infrastructure you control.
Can we try it?
Yes. There’s a live demo at demo.cvet.dev, or join the waitlist for early access.
Is it production-ready today?
CVET is an early-stage product under active development. Treat the demo as an evaluation environment, and talk to us about a pilot before relying on it for a live audit.