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 and what we hold. Every control listed here is implemented today, in the product or the pipeline that builds and ships it, and the full depth ships as a gated security pack during procurement.
LAST REVIEWED · 15 AUGUST 2026 · EVERY CLAIM RE-VERIFIED AGAINST SHIPPING CODE
What we can see, and what we cannot.
A local-first product still makes a handful of outbound connections, so here is the whole boundary on one screen: every category of data that crosses it on the left, and the data that has no path across it on the right. Each row is restated in full, with destinations, in section 04.
Crosses the boundary
Licensing and public-feed traffic. Never your security data.
Never leaves your network
The sensitive dataset. In the default install, no code path sends it anywhere.
The main destinations are itemized in 04 · Network egress. A fully enumerated egress specification, built for packet capture verification, ships in the security pack.
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; no asset names, hostnames or addresses are ever part of licensing traffic.
- 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.
SOC 2 audited infrastructure, end to end.
The product keeps your security data on your hardware, which keeps most frameworks' scope on your side of the boundary. The narrow slice we do process runs entirely on audited infrastructure, and our own certification program is in motion.
| Framework | Status | Detail |
|---|---|---|
| GDPR | Supported | A data processing agreement is executed during procurement. For the desktop product, data residency is determined entirely by where you run the application, and we process only minimal licensing and billing data. |
| SOC 2 | Audited stack | Every subprocessor that touches our licensing and billing data (Netlify, Neon, Cloudflare, Stripe, Resend) holds a current SOC 2 attestation, so that data lives on SOC 2 audited infrastructure end to end. Our own Type II attestation program runs on top of that foundation. |
| HIPAA | Supported | PHI adjacent scan data stays on your hardware and never enters our processing, which keeps CVEasy outside most BAA scope by architecture. HIPAA alignment documentation is available for your assessment. |
| ISO 27001 | In progress | Certification work on the information security management standard is underway. |
| ISO/IEC 42001 | Coming soon | The AI management systems standard, following 27001 on the same program. A natural fit for a product whose AI runs on your hardware. |
| PCI DSS | Not applicable | We do not store, process or transmit cardholder data. Payment processing is handled by our payment provider. |
Certification artifacts and audit reports are delivered under NDA as they complete. Ask during procurement for the current status of any framework your review needs.
Twenty-six controls, grouped the way a reviewer reads them.
Each item describes behavior implemented in the shipping product or its build pipeline, re-verified against the code on the review date above. The control limitations register, the part a formal review digs into, ships in the security pack.
Product & 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 are restricted to same origin with inline execution disabled, object embedding is disabled, base URI is pinned, and network destinations are limited to same origin plus loopback. Inline style declarations are permitted for rendering; inline scripts are not.
- 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.
- Report rendering under the application policy. Generated reports are served under the same Content Security Policy as the application, which blocks inline scripts and object embedding.
- 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, connector credentials, ticketing tokens, patch provider secrets, and SSO client secrets.
- Credentials are decrypted in memory only at the point of use. For the encrypted stores above, plaintext is never written to disk and no endpoint returns a stored secret; status endpoints return has-a-key booleans only.
- 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.
- Data at rest layers with your platform. Field level encryption protects stored credentials, and the database sits on your own disk under your operating system's full disk encryption, such as FileVault, and filesystem permissions.
- Passwords, where local accounts are used, are hashed with a unique random salt per user: scrypt with constant time verification for operator and viewer accounts, bcrypt for team accounts.
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
- Licensing enforcement is cryptographic. License validity is verified with asymmetric signatures inside the compiled binary, so inspecting the application does not yield the ability to forge a license.
- Licensing fails closed. An install that cannot confirm its license stops the engine rather than degrading silently, with no fallback path. If your environment cannot make outbound connections at all, raise it during procurement.
- Threat intelligence bundles are signed and verified against a pinned key, with payload digests independently recomputed, 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,400 JavaScript and TypeScript test cases run on every pull request and every push to main and feature branches, alongside strict type checking. The Rust shell carries a small unit test set and a full compilation check verified per release.
- Release integrity. Installers are delivered through single use download links tied to your purchase, and the SHA-256 digest of any release is available on request.
- Software bill of materials. A CycloneDX SBOM covering the JavaScript dependency tree is available on request; the Rust tree is being added to the same pipeline.
- 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.
What leaves your machine, and what never does.
Rather than assert that nothing leaves your machine, here is what does, by destination and payload. The fully enumerated egress specification, built for packet capture verification, ships in the security pack.
| Destination | Purpose | What is sent |
|---|---|---|
| cveasyai.com | Licensing, version checks and the signed threat intelligence bundle | Account and license information required to activate and maintain your license. Version and intel requests carry nothing identifying, and the bundle is downloaded, not uploaded to. Never an asset name, hostname, address or finding. |
| 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. |
| Google OSV | Open source advisory enrichment | The CVE and advisory identifiers being looked up. Same disclosure shape as EPSS: which vulnerabilities, never which assets. |
| Security news feeds | Live headlines on the threat board | Standard RSS requests to six public outlets (KrebsOnSecurity, SANS ISC, BleepingComputer, SecurityWeek, The Hacker News via FeedBurner, Microsoft). Nothing about your environment. |
| huggingface.co | Model catalog metadata | The name of the AI model in use. A model name is the only thing sent, never anything about your environment. |
| 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. |
| Your AI assistant over MCP | Optional, only if you connect one | The MCP server itself runs locally against the local API. Whatever your assistant queries is carried to that assistant's vendor, such as Anthropic for Claude, under your own account. |
The deep cut ships under NDA.
This page is the summary. The working detail a formal security review runs on is packaged for procurement, delivered under NDA, and kept current against the shipping code.
- The enumerated egress specification. Every outbound destination with its exact payload fields, written so your network team can verify it with a packet capture.
- The control limitations register. Where each control's edges are, stated the way an auditor would find them, with the remediation queue attached.
- The compliance program detail. Current status, timelines, and artifacts for the SOC 2, ISO 27001, and ISO/IEC 42001 work, plus HIPAA alignment documentation.
- Assessment artifacts as they complete. Audit reports and the third party penetration test land here first, under NDA.
Seven documents, available on request.
Available on request without an NDA. Each request is routed to a human rather than a form that returns nothing.
- Security architecture overview
- Data handling summary
- Vulnerability disclosure policy
- AI safety and usage statement
- Compliance posture statement
- Support and SLA summary
- CycloneDX software bill of materialsJavaScript dependency tree; Rust tree being added
Tell us which documents your review needs and we will send them directly.
During procurement we also execute a data processing agreement, complete your security questionnaires, SIG Lite, CAIQ or custom, and deliver the security pack in 06 under NDA.
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.
We are a security company. A researcher who finds something and tells us is doing us a favor, and we will treat them accordingly.
The full vulnerability disclosure policy is one of the documents available on request in 06 · Documents.
- Report to
- support@cveasyai.com, subject line starting with SECURITY
- Acknowledgement
- We acknowledge reports within 5 business days
- Timing
- Please give us reasonable time to remediate before public disclosure
- Scope
- Do not access, modify or destroy data that is not yours, and do not test against other customers