Paridity Trust & Security - secure by design¶
Verified data. Trusted outcomes. Paridity's strongest security property isn't a certificate - it's the architecture. The platform is built so that whole categories of vendor risk simply don't exist in its design.
Why the design is the security answer¶
Paridity runs entirely inside your own cloud account and stores no customer data or credentials of its own. That single design choice answers most of what a security review is built to probe - structurally, not with a policy promise. The one call an installation makes to Paridity is a licence check to EGMW's own licence service, and it carries licence data only (the licence key, a machine id, an activation id, and the product, platform, and architecture), never customer data - see the Data-Flow Disclosure.
| Design property | What it means | The risk it removes |
|---|---|---|
| No stored customer data | Only hashes, diffs, and metadata are retained - in your Postgres, in your VPC. Source/target row values never persist in a Paridity-controlled store. | No vendor-side data store to breach; no data-residency question; no cross-customer blast radius. |
| No stored credentials | connection_ref is a URI pointer into your own secrets backend (AWS SM / Azure KV / GCP SM / Infisical). The platform resolves it at runtime from your backend; Paridity never holds a secret. |
No credential store to leak; no "who has our DB passwords" exposure. |
| Proper protocols & methods | SSO over SAML 2.0 or OIDC (authorization code + PKCE); bearer-token auth (RS256/ES256, no alg=none; aud/iss/exp enforced), TLS in transit, RBAC least-privilege (4 roles), tenant isolation with PostgreSQL RLS as a defense-in-depth backstop, evidence masking (a tenant+mapping+field AND-chain for raw-value storage, plus per-field display masking). |
No home-grown auth; least-privilege by construction; sensitive values maskable end-to-end. |
| Deterministic & auditable | Correctness is computed (hash_total/row_hash/field_diff), never inferred. Evidence is append-only and immutable; the audit log is hash-chained with signed checkpoints that can be anchored to external WORM storage, an RFC 3161 timestamp authority, and your SIEM; evidence bundles are signed and offline-verifiable with your own key. Evidence retention runs on a built-in, dry-run-first schedule that audits every deletion, and an approval-gated legal hold can freeze evidence from deletion entirely. AI never determines correctness. |
No black-box "trust us"; the record is tamper-evident and independently checkable. |
| Customer-operated | You deploy and run it (Helm/Terraform); Paridity operates nothing in your reconciliation path except the licence service, which releases after v1.4.0 check once a day. | No dependency on a vendor's security operations for your reconciliation, and a bounded one on its uptime: without the licence service the installation runs normally for 7 days, then a paid licence runs proof-only until it is reachable - never a halt. |
Start your review here. The documents below are the detail behind each property.
Two mechanisms worth a closer look¶
A robust, tamper-evident audit log. Paridity's audit trail is engineered so an external auditor can trust it without trusting Paridity:
- Append-only + hash-chained. Each sealed audit row carries
entry_hash = SHA-256(prev_hash + canonical(row)), so altering, deleting, or reordering any entry breaks every hash after it. A full-database rewrite that recomputes every hash still fails against the last signed checkpoint. - Complete by construction. Every terminal run status and every admin action (cancel,
bypass_readiness, retention purge) is written through a single point of enrichment with actor, entity, action, timestamp, and source IP - no code path can omit the guarantees. Even evidence deletion (retention purge) writes an audit record before it removes anything. - Immutable evidence + signed bundles. Evidence is append-only; a run's trail exports as an evidence bundle whose manifest commits to every file's hash and to a previous-bundle-hash chain, sealed with a detached signature over exactly the bytes that ship - verifiable offline with the shipped fail-closed tool and your own signing key (held in your secrets backend; an unsigned or tampered bundle never reports as verified).
Keys stay locked down. Paridity is built to never become a place your keys live:
- No credential custody.
connection_refis a pointer; the platform resolves the real secret from your backend (AWS SM / Azure KV / GCP SM / Infisical) at runtime. Paridity holds a pointer, never a password. Column-decrypt keys (TDE, etc.) resolve the same way and are never persisted. - Signing keys you control. Audit/evidence signing supports HMAC → ECDSA-P256 → cloud KMS (AWS KMS, Azure Key Vault, or GCP KMS), where the private key never leaves the KMS/vault - Paridity asks the KMS to sign; it never sees the key. All three KMS signers are live-verified against a real key in that cloud. The default dev key is insecure by design and must be replaced before production, which the deployment checklist enforces.
- Least-privilege everywhere. OIDC/JWT (RS256/ES256, no
alg=none), four-role RBAC enforced only at the API layer, tenant isolation with RLS as a database-level backstop.
The documents¶
| Document | Answers | Status |
|---|---|---|
| Security Whitepaper | The controls in depth: access, secrets, data protection, OSS posture | In-Review |
| Architecture Technical Brief | Control-plane/data-plane design, vendor-neutral engine model, scale | In-Review |
| Data-Flow & Sub-Processor Disclosure | Where data lives (your VPC), the one licence-data call to EGMW's licence service, and the sub-processor list: none for customer data; Railway (licence service hosting) and Microsoft 365 (support mailbox) for licence and support data | In-Review |
| Accuracy Proof | How correctness is guaranteed - and how to verify it yourself | In-Review |
| Compliance & Audit Proof | Append-only, hash-chained, offline-verifiable audit trail | In-Review |
| Verify It Yourself | Independently confirm accuracy, audit integrity, and speed | In-Review |
| Business Continuity & DR Summary | Backup/PITR, RPO/RTO, restore - and who owns what (customer-hosted) | In-Review |
| Open-Source & Supply-Chain Posture | Permissive-only license posture; pinned lockfiles; CI dependency and image scanning; signed release images with SPDX SBOMs | In-Review |
| Questionnaire responses (SIG/CAIQ reference) | Pre-answers for an inbound SIG/CAIQ - many answers are "N/A: customer-hosted" | In-Review (reference) |
| Accessibility Conformance Posture (on request; not on this site) | WCAG 2.1 AA target, what is enforced vs unverified, the VPAT path | In-Review |
| Security Policy / responsible disclosure (on request; not on this site) | How to report a vulnerability, response SLAs, safe harbor | Active |
Formal certifications¶
EGMW holds no SOC 2 report or ISO 27001 certification, and no such audit is planned now or in the immediate future. This is a statement about applicability, not a gap waiting to be closed: SOC 2 and ISO 27001 attest a service organization's controls over the customer data it hosts or processes. Paridity is software you run in your own environment; EGMW does not host it and does not process your data. The controls that matter for your deployment - access, encryption, backup, network, monitoring - are yours, configured in your own cloud account and covered by your own certifications and audits. Open-source and supply-chain hygiene is documented separately in the OSS & Supply-Chain Posture.
Company-level assurances, stated plainly¶
Evil Genius MindWorks LLC (EGMW), the company behind Paridity, is a small, privately held business. These are the answers a vendor-risk review usually asks for, as they stand today:
| Assurance | Today |
|---|---|
| SOC 2 / ISO 27001 | None held, none planned (see above). |
| Third-party penetration test | None performed and none scheduled. What runs on every code change is automated: Semgrep static analysis, dependency vulnerability audits (pip-audit, npm audit), a full-history Gitleaks secret scan, and a Trivy configuration scan; release images are Trivy-scanned before release and re-scanned weekly. A dynamic scan (DAST) runs weekly in CI: OWASP ZAP against a throwaway stack built from the current code - a passive baseline scan of the production UI image, and an authenticated, active scan of the API driven by the API's own OpenAPI document. The job fails on any finding in a FAIL-level class (injection, cross-site scripting, path traversal, XML external entities, remote code execution, server-file disclosure, open redirect, and the security headers already in place) and when the API scan cannot be shown to have run authenticated. This is automated scanning, not a penetration test: it does not chain findings, test business logic or tenant isolation, or test a real deployment's ingress, TLS or identity provider. Because Paridity runs in your environment, you may test your own deployment with your own tools or testers (Acceptable Use Policy §6.1); testing EGMW-operated systems such as the licence service needs EGMW's written authorization first (§6.2). |
| Internal security review | An internal, AI-assisted code review of the Paridity source (#3357), carried out by EGMW with an AI model in four passes from 2026-10-30 to 2026-11-01. No outside party took part. Scope: tenant isolation and authorization; authentication (bearer tokens, SAML, OIDC, SCIM, API keys); generated SQL; licensing; secrets and logging. Every item in scope was read line by line and either demonstrated as a finding, ruled out with a recorded counter-check, or pinned by a test. A finding required a test, committed to the repository, that failed against the code before the fix. Five findings: three high (#3365, #3369, #3398), one medium (#3383), one low (#3384); all five were fixed by 2026-11-01. This is a secure-development control, not a penetration test and not a third-party assessment: it reviewed source code and a development stack, did not test a customer deployment's ingress, TLS or identity provider, and did not exercise exploit chains against live credentials. The review record (method, coverage, findings, hypotheses not demonstrated, ruled-out items with their counter-checks, follow-ups) is retained by EGMW and available on request. |
| Cyber insurance / certificate of insurance | EGMW holds no cyber-insurance policy and cannot provide a certificate of insurance at this time. If a customer contract requires coverage, EGMW will review the requirement. |
| Company viability | No formal viability statement and no financial statements are published. The mitigant is architectural, and it has a limit: see what happens without EGMW. |
| Formal security program / incident-response plan | Neither is published. EGMW is a small business and has no formal, documented security program or incident-response plan today. What exists is the engineering practice these documents describe, and the coordinated vulnerability-disclosure policy. |
What happens without EGMW¶
Paridity runs entirely in your environment. Its only runtime dependency on EGMW is the licence service. If that service becomes unreachable - an outage, or EGMW ceasing to operate it - an installation keeps running normally for 7 days on its last signed licence token. After that, a paid licence is degraded until a refresh succeeds: runs continue and are never stopped, but they are proof-only (counts and hash totals, no field-level diffs), and bringing new configuration into service (for example, creating or enabling a mapping or schedule) is refused. No data is touched. The honest risk: if the licence service never returns, that degraded state is permanent. There is no source-code escrow, no perpetual-licence fallback, and no offline activation path today.
How to use this with your VRM process¶
- Read the five design properties above - most control questions resolve there.
- Go deeper via the Security Whitepaper + Architecture Brief + Data-Flow disclosure.
- For SOX/ICFR or audit stakeholders, use the Accuracy + Compliance proofs - and actually run the verify-it-yourself steps.
- If you must map a SIG/CAIQ, the questionnaire reference is pre-answered; many rows are "not applicable - customer-hosted, no stored data."
- Route anything unanswered through your Paridity account contact.
Classification: Customer Confidential - a curated index; each linked document carries its own verification date and status. Do not distribute externally without Paridity approval.