We hold our own software to the same standard we help you document. Every claim on this page is backed by a dated report — request the full set below.
Enclave-GAP, Enclave-SSP, and Enclave-AI are coded according to DISA Application Security and Development (ASD) STIGs from initial development, not retrofitted before an audit. Each product tracks every applicable control against its own real source code — a control is only marked compliant against an automated test or a live-verified behavior in the running app, never on the basis that the code merely exists.
A fixed toolchain runs across all three products’ Rust and TypeScript source. Dependency, lint, license-policy, and secret scans all run on every push and pull request in CI and block the build on any finding; the full Semgrep sweep below runs on every release and monthly.
| Tool | Checks |
|---|---|
| cargo audit | Rust dependency CVEs and advisories (RustSec) |
| cargo deny | Dependency advisories, license policy, and banned/duplicate crates |
| npm audit | JavaScript/TypeScript dependency vulnerabilities |
| Semgrep | Static code analysis — OWASP Top Ten, Rust, TypeScript, React rulesets |
| cargo clippy | Rust lint pass — CI-blocking on every push, not just spot-checked |
| ESLint | TypeScript/React lint pass, with dedicated XSS/unsanitized-DOM security rules |
| cargo geiger | Quantifies unsafe Rust pulled in by the dependency tree |
| gitleaks | Scans every push, and the full commit history, for accidentally committed secrets |
| cargo machete / knip | Unused dependencies and dead code, reviewed before removal |
Current result across Enclave-GAP, Enclave-SSP, and Enclave-AI: zero known dependency vulnerabilities, zero Semgrep findings above informational severity, and a clean cargo clippy, ESLint security-rule, and cargo deny pass. A one-time full commit-history secret scan is complete for Enclave-SSP and Enclave-AI (zero real secrets found); Enclave-GAP’s history scan is queued — the CI gate itself is already live on all three.
Enclave-GAP, Enclave-SSP, and Enclave-AI are offline desktop applications. They serve their UI through Tauri’s own custom-protocol asset loader, not a listening web server, and none of the three is granted an HTTP-client capability. A conventional dynamic scanner (OWASP ZAP, Burp Suite) has no network endpoint to point at in production — run against the development server instead, it would test Vite’s own tooling, not the shipped product, so we don’t run one and don’t represent one as having been run.
In its place, every release gets a direct, source-verified review of the four things that actually determine this architecture’s security:
All four checks currently pass, unchanged, across Enclave-GAP, Enclave-SSP, and Enclave-AI.
Every internal error — a database problem, a corrupted file, an unexpected bug — is routed through a single sanitization boundary before anything reaches the screen. You will see a plain description of what failed and a note to contact your administrator if it persists; you will never see a database path, a SQL fragment, a stack trace, or any other internal detail. The real technical detail isn’t discarded — it’s written to a dated log file in a standard machine location for your own administrator to review, separate from whoever is using the application at the time.
If something the application depends on for its own security — its encrypted audit trail, its access controls — isn’t working, the application refuses to proceed rather than run without that protection, even with a correct, valid credential. And if something genuinely unexpected happens, you get a plain restart message instead of a blank or frozen window with nothing to report to support.
All three products share the same architecture, so one diagram applies to all of them. It shows every boundary a threat actor would have to cross — the untrusted UI layer, the IPC bridge, the trusted core, and the local storage and OS-level protections underneath.
The webview is treated as hostile by design: it can only reach the Rust core through the small set of IPC commands each product explicitly registers, and only within the capability grant shown above. No component opens a network socket, listens on a port, or reaches the internet — internal “traffic” here means in-process function calls and local file I/O, never a network hop. Data at rest is protected two ways at once: the database itself is SQLCipher-encrypted, and the key that unlocks it is sealed by the operating system’s own kernel-mediated vault, so a copied database file is useless without also compromising that specific OS account. Member sign-in runs through the platform’s own biometric hardware rather than a password this application ever sees or stores.
What each product does with that shared architecture:
| Product | Applicable controls | Compliant | Open findings |
|---|---|---|---|
| Enclave-GAP | 107 | 106 | 0 High, 2 Medium |
| Enclave-SSP | 146 | 145 | 0 High, 1 Medium |
| Enclave-AI | 151 | 148 | 0 High, 0 Medium |
As of September 13, 2026. Zero open High-severity findings across all three products. Remaining Medium items and their remediation plans are documented in each product’s STIG status tracker, included in the full package on request.
Each product has its own documented incident response plan covering credential compromise, unauthorized data access evidenced in its audit trail, and dependency vulnerabilities — what counts as an incident, how it’s detected, and how it’s handled through containment and recovery. A separate, organization-level plan sits above those three, mapped to the NIST SP 800-53 Rev. 5 Incident Response (IR) control family — policy, training, testing, handling, monitoring, and reporting — including how affected customers are notified and supported in meeting their own reporting obligations. Full plans are included in the security package below.
Found a security issue in Enclave-GAP, Enclave-SSP, Enclave-AI, or this website? Email marc.larouche@gmail.com with what you found and how to reproduce it. We acknowledge every report within 2 business days and investigate it directly — there is no intermediary vendor or third-party support desk in between.
Reported in good faith and without exploiting the finding beyond what’s needed to demonstrate it, your report won’t be met with legal action from us. We ask that you give us a reasonable window to fix a confirmed issue before any public disclosure.
Dated SAST/DAST reports, full STIG control checklists, per-product threat models, the NIST 800-53 IR-mapped incident response plan, and the error handling statement — sent directly, for your own vendor security review.