Paridity Open-Source & Supply-Chain Posture¶

Verified data. Trusted outcomes.

CDC-Aware Reconciliation Platform

Prepared for: General distribution (third-party-risk review) Version: v0.1 · Date: 2026-10-29

Executive summary¶

Paridity is built exclusively on permissively licensed open-source components - MIT, Apache 2.0, and BSD-family licenses (e.g. the PostgreSQL License). No GPL, AGPL, or SSPL component is used anywhere in the platform. This is a deliberate, enforced engineering rule, not an after-the-fact scan result: components with restrictive or source-available licenses (HashiCorp Vault under BSL 1.1, Confluent Platform under the Confluent Community License) were evaluated and excluded by design before they entered the stack. Every shipped Python and JavaScript component is pinned, with exact versions and integrity hashes, in two committed lockfiles that serve as the component manifests of record, and CI gates every change against known-vulnerability databases (pip-audit against the exact pinned Python lockfile; npm audit with a high/critical merge gate on production JavaScript dependencies) plus static analysis (Semgrep) and a full-history secret scan (Gitleaks). Production images are scanned (Trivy) for fixable HIGH/CRITICAL vulnerabilities before every release, and the latest release's images are re-scanned weekly. Since release v1.1.1 (2026-08-17), every release also ships a machine-generated SPDX SBOM per container image, generated (syft) from the published image digests - attached to the GitHub Release and pushed as a cosign in-toto attestation verifiable against the release's signing identity (cosign verify-attestation --type spdxjson) - and every released image and the Helm chart are cosign keyless-signed. The most recent release, v1.4.0 (2026-10-28), carries all of these.

One structural point matters for how you weigh all of this: in Paridity's current shipping model, the entire platform deploys inside your cloud account/VPC. The software supply chain described here is the supply chain of software you run. The one Paridity-operated service, the licence service, runs none of its code in your environment: it returns a signed licence token that your installation verifies against public keys built into the release image. From the first release after v1.4.0 those keys are written into the image at build time by the release pipeline - a source constant in the image, never read from the network, a file, an environment variable, or the database at runtime - and the image gates check the built image's licence mode before it is pushed. This document exists so you can review that supply chain directly.

Problem¶

A third-party-risk review of any data-adjacent platform has to answer three supply-chain questions:

License risk - does any component's license (GPL/AGPL/SSPL, source-available licenses) create copyleft exposure, redistribution constraints, or commercial-use restrictions for the customer deploying the product?
Component transparency - can the vendor say exactly which components, at exactly which versions, ship in the product?
Vulnerability posture - is the dependency set continuously checked against known-vulnerability databases, and does a vulnerable dependency block a release?

Because Paridity deploys into the customer's own environment, these questions are sharper than for a hosted SaaS: the customer's own security tooling will scan the running containers, and any discrepancy between what the vendor claims and what ships is immediately visible. Paridity's posture is written for that level of scrutiny.

Approach: permissive-only by rule, excluded-by-design¶

The license rule¶

The platform's engineering standard, binding on all code changes, states the rule verbatim: "All libraries are MIT or Apache 2.0 licensed. No GPL. No AGPL. No SSPL. This is a commercial product - every dependency must be commercially safe." The full dependency/license inventory is maintained in the platform's technology-stack register, which records for every component its license and commercial suitability; per that register, every dependency was verified in April 2026.

The core stack and its licenses:

Component	Technology	License
Workflow orchestration	Temporal (self-hosted; Python SDK `temporalio`)	MIT
Control-plane API	FastAPI, Pydantic v2, SQLAlchemy 2.x	MIT
In-memory diff engine	DuckDB	MIT (Foundation-protected)
Data interchange	Apache Arrow / PyArrow	Apache 2.0
Evidence + metadata store	PostgreSQL	PostgreSQL License (BSD-style)
Lake SQL access	Trino	Apache 2.0 (Trino Software Foundation)
CDC signals (optional)	Apache Kafka - core only	Apache 2.0
Secrets (self-hosted option)	Infisical	MIT
Secrets (cloud)	AWS Secrets Manager / Azure Key Vault / GCP Secret Manager	Cloud-provider TOS (service, not a bundled library)
Observability	OpenTelemetry SDKs	Apache 2.0 (CNCF-governed)
Frontend	React 18, Vite, TanStack Query/Table/Router, Tailwind CSS, shadcn/ui, Zustand	MIT
Container orchestration	Kubernetes / containerd	Apache 2.0 (CNCF-governed)

Several components were deliberately chosen for governance durability, not just current license text: DuckDB is foundation-protected (MIT in perpetuity), PostgreSQL has no corporate owner able to relicense it, and Trino, Kubernetes, containerd, and OpenTelemetry sit under vendor-neutral foundations. This insulates the stack from the single-vendor relicensing events (BSL, SSPL conversions) that have hit other infrastructure projects.

Excluded by design - proactive supply-chain hygiene¶

The more telling half of the posture is what Paridity refused. These exclusions are recorded in the technology-stack register ("Explicitly Excluded") and enforced as binding engineering rules:

Excluded component	License issue	Paridity's position
HashiCorp Vault (as a default)	BSL 1.1 since August 2023; IBM-owned	Never a default or required dependency. Supported only as an optional fifth secrets adapter for customers who already operate Vault. The default secrets backends are the customer's cloud-native service (AWS SM / Azure KV / GCP SM) or MIT-licensed Infisical.
Confluent Platform components (Schema Registry, ksqlDB, REST Proxy)	Confluent Community License bars competing SaaS offerings	Excluded entirely. Where Kafka is used (optional CDC readiness signals), it is Apache Kafka core only, under Apache 2.0.
Docker Desktop (production)	Paid license required for organizations > 250 employees	Development use only; production runs containerd.
Any GPL / AGPL / SSPL library	Copyleft / source-available restrictions incompatible with commercial distribution	Barred by standing rule at the engineering-standard level.

The pattern to note for risk assessment: these were excluded before adoption, not carved around after an audit finding. License review is an input to component selection, not a remediation activity.

Component manifests of record (pinned dependencies)¶

Paridity does not ask reviewers to trust a hand-maintained list. Two committed, machine-generated lockfiles are the authoritative manifests of exactly what ships, at exactly which versions:

Manifest	Ecosystem	Contents (as of 2026-10-29)
`requirements-ci.lock`	Python (backend: API, workers, connectors, services)	209 exactly pinned packages (`pkg==x.y.z`), each with SHA-256 integrity hashes. Machine-generated from the resolved dependency graph and marked "GENERATED, do not edit by hand". Four native database-driver packages (`ibm-db`, `pyodbc`, `python3-saml`, `xmlsec`) are excluded from this CI manifest because slim CI runners lack their system libraries - see the audit-scope note below.
`frontend/package-lock.json`	JavaScript (React SPA)	npm lockfile v3; 635 resolved package entries (production + development dependencies) with integrity hashes.

Discipline around these manifests is itself an engineering rule: any backend dependency change must regenerate the project's dependency-declaration, resolution, and CI-audit lockfiles together, in one commit, using a pinned resolver version - so the manifest CI audits can never drift from the manifest developers resolve against.

What this means for your review: the exact component inventory is available on request as the two lockfiles themselves (or auditable in-repo under a source-review arrangement). This document intentionally does not transcribe hundreds of package names - the lockfiles are the source of truth, and any transcription would be a staleness risk.

Dependency updates arrive both as Dependabot pull requests (configured for pip, npm, cargo, GitHub Actions, and Docker, weekly) and through this disciplined lockfile-regeneration process, and are reviewed like any other code change. A CI gate fails the build when the three Python dependency files disagree, so a Dependabot update cannot merge with a stale CI lockfile.

Dependency-scanning and static-analysis gates (verified in CI)¶

The following gates exist in the repository's CI pipeline and were re-verified against that pipeline on 2026-10-29. They run on every code change (a documentation-only change skips them); a failure fails the required CI check and blocks merge.

Python: `pip-audit` against the exact pinned lockfile¶

The dependency-audit CI job audits requirements-ci.lock - the exact pinned versions, including all transitive dependencies - against the PyPI advisory database using pip-audit. Auditing the exact pinned lockfile means the audit covers precisely what ships, not what might resolve.

Two scope notes, stated for transparency rather than hidden:

Documented, time-boxed advisory exceptions. An advisory is accepted only explicitly, one advisory id at a time, never by a blanket suppression. Each acceptance is annotated inline in the CI configuration with its rationale and a removal condition, and the more recent acceptances also carry a reachability note (whether the platform reaches the affected code, checked against the source and stated as reachability, not as an exploitability judgement); where the same advisory affects the container-image scan, its .trivyignore entry is removed together with it. As of 2026-10-29 the accepted advisories sit in four packages: python-jose, its ecdsa dependency, and pyjwt, for which no fixed release exists upstream (for the python-jose algorithm-confusion advisory, both of the platform's token-verification paths accept asymmetric algorithms only, so an HMAC-signed token is never accepted and that path is not reached); and filelock, where a fix exists only in a major version the pinned Snowflake driver does not yet accept (the affected lock classes are not used by the platform, or need a second local user that the single-user image does not have; removal is tied to the Snowflake driver upgrade). Exceptions are retired, not left to become permanent: the thrift, anyio, and oauthlib acceptances were each removed when an upgrade made the fixed version resolvable.
Native-driver packages outside the pip-audit job. The four native driver packages excluded from the CI lockfile (ibm-db, pyodbc, python3-saml, xmlsec) are outside this job's scope; the CI configuration documents that they are to be audited separately on a driver-provisioned host, and no recurring, evidenced separate audit is in place. They are installed in the shipped backend image (they appear in its release SBOM), so the Trivy image scan below covers them for fixable HIGH/CRITICAL vulnerabilities; they are not covered by pip-audit's advisory database.

JavaScript: `npm audit` with a production high/critical merge gate¶

The same CI job runs npm audit twice over the frontend:

Informational pass - surfaces all advisories (including dev/test tooling) in the CI log without failing the build, so nothing is invisible.
Merge gate - npm audit --audit-level=high --omit=dev fails the build on any high or critical vulnerability in production (shipping) dependencies. Development-only tooling advisories do not block merge (they do not ship) and are upgraded on their own cadence.

Static analysis and container linting¶

Semgrep SAST (sast CI job): scans the application source with the p/python, p/security-audit, and p/owasp-top-ten open-source rulesets; any finding fails the build (--error). A project-specific blocking rule additionally polices dynamic SQL construction (SQLAlchemy text() usage requires an explicit, justified suppression with all user values bound as parameters).
Hadolint: the fast-gates CI job lints the development Dockerfiles on every code change, and the production-image gate (below) lints the three production Dockerfiles (backend, UI, docs); container images are built from in-repo Dockerfiles rather than pulled as opaque third-party application images.
Secret scan - Gitleaks (a step of the fast-gates CI job): scans every commit a pull request adds for committed secrets; a finding fails the build.
Configuration scan - Trivy (a step of the fast-gates CI job): scans the Dockerfiles, compose files, and the in-repo Terraform modules for HIGH/CRITICAL security misconfigurations; a finding fails the build.

Container images: Trivy vulnerability scan, before release and weekly after¶

Production-image gate. The same gate runs on every pull request that changes the image packaging or the Python dependency manifests, and in the release pipeline before anything is pushed: it builds the three production images (backend/workers, UI, docs) and fails on any fixable HIGH or CRITICAL vulnerability Trivy finds in them (OS and language packages). The pushed release artifact is the exact image that passed the gate, never a rebuild.
Standing re-scan. Every Monday, the images of the latest release are pulled by digest and re-scanned against the current vulnerability feed, so a vulnerability published after release day turns the scan red rather than sitting unseen in the registry. Container-scan acceptances live in one policy file (.trivyignore), read by both the release gate and the weekly re-scan, under the same one-id-at-a-time, removal-condition rule as above.

Running stack: weekly dynamic scan (OWASP ZAP)¶

What runs. Every Monday (and on any change to the scan itself) CI builds the current code into a throwaway stack - the real API with real sign-in, the production UI image - on a network sealed off from everything else, and runs OWASP ZAP against it: a passive baseline scan of the UI, and an authenticated, active scan of the API driven by the API's own OpenAPI document.
What fails it. 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); a scan error; or an API scan that cannot be shown to have run authenticated (enough protected endpoints must have answered 2xx). Every rule's verdict, and the reason for every ignored rule, is in one file (scripts/dast/zap-rules.tsv).
What it is not. 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. ZAP (Apache-2.0) runs only in CI and is not part of any shipped image.

Status honesty: what is verified, what is roadmap¶

Per Paridity's positioning standard, an unverified claim is not stated as fact.

License posture - Verified. The permissive-only rule (MIT / Apache 2.0 / BSD-family; no GPL, AGPL, or SSPL) is documented as a binding engineering standard, enforced at component selection, and recorded per-component in the technology-stack register (dependencies verified April 2026 per that register).
Formal SBOM artifact - Verified (since v1.1.1, 2026-08-17). Every release publishes a machine-generated SPDX JSON SBOM per container image (backend/workers, UI, docs), generated by syft from the published image digests - never a local rebuild - so the SBOM describes exactly what customers pull. Delivered two ways per release: as sbom-paridity-{api,ui,docs}-vX.Y.Z.spdx.json assets on the GitHub Release (sbom-dataalign-... for v1.3.1 and earlier, released under the product's former name; most recently v1.4.0, 2026-10-28), and as cosign in-toto attestations on the image digests, verifiable against the release's pinned signing identity (cosign verify-attestation --type spdxjson). The release pipeline fails if SBOM generation degenerates (≤10 packages) or if a wrong-identity attestation verify would pass - both proven can-fail on the live v1.1.1 run. The pinned lockfiles above remain the source-level manifests of record; the SBOM is the shipped-artifact-level manifest.

Limitations & roadmap¶

Capability	Status	Notes
Permissive-license-only dependency posture (no GPL/AGPL/SSPL)	Verified	Binding engineering rule; per-component inventory in the technology-stack register (verified April 2026 per that register).
Restrictive-license components excluded by design (Vault BSL optional-only; Confluent excluded, Kafka core only)	Verified	Recorded in the technology-stack register and enforced as standing rules.
Pinned component manifests with integrity hashes (Python + JS lockfiles)	Verified	`requirements-ci.lock` (209 pinned packages as of 2026-10-29, SHA-256 hashes) + `frontend/package-lock.json` (lockfile v3, 635 resolved entries). Counts move with routine dependency updates; the lockfiles themselves are the always-current record.
Python dependency vulnerability gate (`pip-audit` on exact pins incl. transitives)	Verified	CI `dependency-audit` job; explicit, per-advisory exceptions only, each with a rationale and a removal condition (see above).
JavaScript dependency vulnerability gate (`npm audit --audit-level=high --omit=dev`)	Verified	CI merge gate on production dependencies; all advisories surfaced informationally.
SAST (Semgrep: python / security-audit / owasp-top-ten) + Dockerfile lint (Hadolint)	Verified	CI `sast` job; Hadolint on the development Dockerfiles in the `fast-gates` job and on the production Dockerfiles in the image gate; findings fail the build.
Secret scan (Gitleaks, every commit a pull request adds) + configuration scan (Trivy config)	Verified	`fast-gates` CI job on every code change; findings fail the build.
Container-image vulnerability scan (Trivy, fixable HIGH/CRITICAL)	Verified	Production-image gate before every release push (and on image-packaging pull requests), plus a weekly re-scan of the latest release's images by digest.
Dynamic scan (OWASP ZAP: UI baseline + authenticated API scan, weekly)	Verified	Weekly CI job against a stack built from the current code; FAIL-level findings, scan errors and an unproven-authentication scan fail the job; reports kept as run artifacts. Automated scanning, not a penetration test.
Machine-generated SBOM (SPDX, per image, per release)	Verified (v1.1.1, 2026-08-17)	syft from the published digests; Release assets + cosign in-toto attestations; can-fail proven live.
Automated license-compliance scanning in CI (e.g. license-classifier gate)	Verified	Per-build license gate across all three ecosystems: a Python license check over the exact pins (with a `--prove-can-fail` mode), `license-checker` over production npm dependencies, and `cargo deny` over the Rust crate - each fails the build on a disallowed (GPL/AGPL/SSPL) license. Component-selection review and the technology-stack register still apply on top.
Automated dependency-update automation (Dependabot/Renovate)	Verified	Dependabot is configured for pip, npm, cargo, GitHub Actions, and Docker (weekly); updates arrive as PRs reviewed like any code change, alongside the disciplined lockfile-regeneration process.
Vulnerability audit of the four CI-excluded native driver packages	Roadmap	Outside the `pip-audit` job; prescribed as an out-of-band audit on a driver-provisioned host, with no recurring evidenced process yet. Covered only by the Trivy image scan of the shipped backend image (fixable HIGH/CRITICAL).
Published coordinated vulnerability-disclosure policy	Supported	A coordinated disclosure policy ships as `SECURITY.md` - private reporting via GitHub Security Advisories, plus the account-contact channel for customers. A dedicated monitored `security@` mailbox is a pre-GA operational item, called out in the policy itself.
Formal SLSA build-provenance predicate	Roadmap	cosign keyless signing of every released image and the Helm chart, plus an SPDX-JSON SBOM in-toto attestation per image, ship since v1.1.1 (2026-08-17) - see the Verified SBOM/signing entry above. A formal SLSA provenance predicate on top of that signed-and-attested baseline is not yet generated.

Appendix¶

The full dependency/license inventory and exclusion register (the source of truth for the license posture), the pinned Python and JavaScript component manifests of record (exact pins with SHA-256 integrity hashes), and the CI dependency-audit, SAST, and Dockerfile-lint job definitions cited above are available to reviewers on request through your Paridity account contact.
Security Whitepaper - the broader control set this posture sits within (access control, secrets, data protection).
Trust Center index - the curated entry point for VRM review.
Follow-up questions: route through your Paridity account contact.