Your exposure map never leaves your building.
CVEasy AI is a local-first CTEM platform. Scan results, findings, asset inventories and reports are stored and analyzed entirely on your own hardware. This page documents what the product actually does, what we hold today, and what we are still building. Every control listed here is implemented in shipping code.
Last reviewed 25 July 2026
Local first is an architecture, not a setting
Most exposure management platforms require you to ship your complete vulnerability map to a vendor cloud: every asset, every weakness, every attack path. That map is one of the most sensitive datasets your organization holds, and handing it to a third party is a decision most security teams would rather not make.
CVEasy AI is built the other way around. The application, the database, the analysis engine and the AI model all run on your machine.
- Your security data is never transmitted to us. There is no upload path in the product for scan results, findings, asset inventories or generated reports. None of it reaches CVEasy infrastructure, because no code exists to send it.
- AI analysis runs on your hardware. The cveasy-ai-v1 model and its inference runtime ship inside the application. There is no download step and no cloud inference by default. The engine binds to loopback on your machine.
- No telemetry, analytics or crash reporting. The product contains no such SDK of any kind. No usage data, no behavioral data, no crash reports. Asset counting for licensing is computed locally and never transmitted.
- The interface cannot reach the internet. Content Security Policy restricts the application UI to same origin plus loopback. All network activity originates in the local backend process, where it is enumerable and configurable.
Optional cloud AI, on your key. You can choose a cloud model provider instead of the built-in engine. It is off by default and requires you to supply your own API key, which is encrypted on your own machine. We never hold, proxy or see that key. When a cloud provider is enabled, prompts include hostnames, software versions and finding detail, so the settings screen states this at the point of selection.
Compliance status, stated plainly
We hold no third party certifications today. We would rather say so here than have you discover it in a security review. Below is the real position and the direction of travel.
| Framework | Status | Detail |
|---|---|---|
| GDPR | Supported | Data processing agreement available on request. For the desktop product, data residency is determined entirely by where you run the application. |
| SOC 2 Type II | Readiness underway | Control documentation and evidence collection are in progress, driven internally. An independent CPA firm will be engaged for the attestation. We will publish the report here when it exists, and not before. |
| HIPAA | On request | Because the desktop product stores no customer data on our infrastructure, most obligations sit with you as the covered entity. Talk to us about your specific assessment. |
| ISO 27001 | Roadmap | Planned after SOC 2. No date committed. |
| PCI DSS | Not applicable | We do not store, process or transmit cardholder data. Payment processing is handled by our payment provider. |
If a certification you require is still a target rather than a fact, we will tell you that directly during procurement. A precise answer about where we are closes more reviews than an optimistic one.
Security controls
Grouped the way a reviewer reads them. Each item describes behavior implemented in the shipping product.
Product and application security
- Least privilege native capabilities. The application grants its interface no filesystem access, no HTTP client and no arbitrary command execution. Process spawning is restricted by name to three bundled components.
- Content Security Policy. Scripts and styles are restricted to same origin, object embedding is disabled, base URI is pinned, and network destinations are limited to same origin plus loopback.
- Security response headers on every route: content type options, frame options set to deny, referrer policy, and a permissions policy denying camera, microphone and geolocation.
- Locked down report rendering. Generated reports are rendered under a restrictive policy that blocks active content.
- Bundle integrity check. The application verifies a SHA-256 hash of its bundled interface against a value fixed at build time.
- Parameterized database access. Query construction never concatenates user input, and this is enforced as a project coding standard.
Data protection
- Stored credentials are encrypted with AES-256-GCM using a unique random initialization vector per record, with authenticated encryption. This covers AI provider API keys, scanner and connector credentials, and ticketing integration tokens.
- Credentials are decrypted in memory only at the point of use. Plaintext is never written to disk and is never returned by listing endpoints.
- The encryption key is generated randomly per installation and stored with restrictive file permissions in your own application data directory. It is not hardcoded and it is not shared between installs.
- The database file itself is not encrypted and relies on your operating system disk encryption, such as FileVault, and on filesystem permissions. We state this rather than describing the product as having an encrypted database, because field level encryption and database level encryption are not the same thing.
- Passwords, where local accounts are used, are hashed with scrypt and a unique random salt per user, and verified in constant time.
Access control
- Optional role based access control with two roles: operator, who can run scans and simulations, and viewer, who is read only. It is off by default because the product ships as a single operator desktop tool.
- Account administration requires an operator session as soon as the installation has any account, whether or not enforcement is switched on.
- Sessions are opaque high entropy tokens generated from a cryptographically secure source, stored server side with a fixed expiry.
- The application binds to loopback and refuses requests that do not originate locally when running in its default local mode.
Licensing integrity
- License keys are Ed25519 signed and verified entirely offline against a public key pinned in the application binary. Validation never requires a network connection. Because verification is asymmetric, inspecting the application does not yield the ability to forge a key.
- Signature failure or expiry invalidates a key with no fallback path.
- Threat intelligence bundles are signed and verified against a pinned key before import.
Software supply chain
- Every component builds from a committed lockfile carrying cryptographic integrity hashes, so builds resolve to fixed dependency versions and a change requires a reviewable commit.
- A deliberately small dependency surface. Roughly 38 direct JavaScript dependencies and 5 direct Rust dependencies across the shipping components, which is a fraction of a typical desktop application stack.
- Automated tests on every change. Approximately 2,200 JavaScript and TypeScript test cases and 157 Rust tests run on every push and pull request, alongside strict type checking and a compilation check.
- Release integrity. Each release publishes a SHA-256 digest of the installer in a manifest served over HTTPS so you can verify the download you received.
- Software bill of materials. CycloneDX SBOMs covering both the JavaScript and Rust dependency trees are available on request.
- No credential has ever been committed to the source repository, verified against full repository history. The codebase includes automated tests asserting that connector credentials are redacted from serialized output.
Audit trail
- Attack simulation is audited. Every simulation start, finish and authorization-blocked attempt is recorded, which is how you evidence that no simulated attack ran against an out of scope target.
- Remediation actions are audited, including every ticket, patch schedule, patch push, approval decision, fix verification and access denial, each with its outcome and a machine readable reason.
- Entries are insert only by design. The application contains no code path that updates or deletes an audit row. Because the product is local first, the database sits on your own machine under your own filesystem controls, so we describe this as insert only rather than as tamper proof storage. We are not going to claim a property that your own administrator can defeat.
Network transparency
Rather than assert that nothing leaves your machine, here is the complete list of what does. You can verify all of it with a packet capture, and we would encourage you to.
| Destination | Purpose | What is sent |
|---|---|---|
| cveasyai.com | Version check, license validation and revocation | Your license key and a hashed machine identifier derived from hostname, platform, architecture and CPU model. Never your security data. |
| CVEasy threat feed | Signed threat intelligence and indicator bundles | Your license key, as an authorization token. The bundle is downloaded, not uploaded to. |
| NVD and CISA KEV | Public vulnerability and known exploited catalogs | Nothing about your environment. Catalog and date range requests only. |
| FIRST.org EPSS | Exploit probability scoring | The CVE identifiers being scored, which discloses which vulnerabilities you are tracking. No hostname, IP address or asset name. |
| Your configured integrations | Scanner, cloud, ticketing and notification connectors | Whatever that integration requires, sent to your own account with that vendor, under credentials you supply. These are your relationships, not ours. |
| Your chosen cloud AI provider | Optional, off by default | Prompt content including hostnames, versions and finding detail, sent to your own provider account under your own key. |
The hashed machine identifier is a pseudonymous value used to bind a license to an installation. Hostnames can contain personal information in some environments, which is why we hash it and why we disclose it here rather than describing the product as making no outbound connections at all.
Subprocessors
Third parties that process data on our behalf. The list is short because the product does not send us your data in the first place.
| Subprocessor | Purpose | Data processed |
|---|---|---|
| Netlify | Hosting for cveasyai.com, which serves the update manifest and threat intelligence bundle | IP address and request metadata |
| Cloudflare | Threat feed delivery and release binary hosting | License key as a bearer token, IP address, request metadata |
| Stripe | Payment processing and subscription management | Name, email, billing and payment data |
| Resend | Transactional email, including license delivery | Email address, license key, plan name |
Scanner, cloud, ticketing and notification integrations are not our subprocessors. You configure them into your own accounts with those vendors, using credentials that are encrypted on your machine under a key we never hold.
What we are building
A trust center that only lists strengths is marketing. These are the things a thorough reviewer would ask about that we cannot yet answer with a yes.
- SOC 2 Type II. Readiness work is underway. No auditor engaged yet, and we are not publishing a date we are not confident in.
- Third party penetration test. Commissioning is planned. The report will be available under NDA when it exists.
- Automated dependency scanning in our own pipeline. We build a vulnerability management product, so we hold ourselves to this and we are wiring it in.
- Signed and notarized releases. The release pipeline supports Apple Developer ID signing and notarization; production signing credentials are being put in place.
- Multi user workspaces as a security boundary. Client workspaces today organize findings and reporting within a single operator's installation. They are not a boundary between mutually distrusting users, and we do not describe them as one.
- Single sign on. Not implemented. On the roadmap, not available today.
Documents
Available on request today, with the request routed to a human rather than a form that returns nothing:
- Data processing agreement
- CycloneDX software bill of materials
- Security architecture overview
- Data handling summary
- Vulnerability disclosure policy
- Completed security questionnaires, including SIG Lite and CAIQ formats
As certifications and audit reports become available, they will be delivered through a gated document portal under NDA. We would rather build that when there is something behind it.
Report a vulnerability
If you have found a security issue in CVEasy AI, we want to hear about it, and we will not take legal action against good faith research conducted under our disclosure policy.
- Report to security@cveasyai.com
- We acknowledge reports within 5 business days
- Please give us reasonable time to remediate before public disclosure
- Do not access, modify or destroy data that is not yours, and do not test against other customers
We are a security company. A researcher who finds something and tells us is doing us a favor, and we will treat them accordingly.