Trust model // launch disclosure
SSX360 trust model
A plain-language view of what runs locally, what the hosted portal stores, and where the security roadmap is still open.
SSX360 trust model
Ed25519
commit envelopes
offline-verifiable proof
local-only
CLI & HOOKS
repo never uploaded
Scroll Gate
PR enforcement
signed vs unsigned
SSX360
control plane
identity · billing · audit
SSX360 trust model · local signing, hosted control plane
Commit envelopes stay on your machine through the Matrix Scroll SDK. SSX360 proves access, stores policy and audit metadata, and releases evidence packs — not private source code.
What runs locally
Commit envelopes
Signed provenance artifacts are created and verified via the Matrix Scroll CLI and Git hooks.
Editor integration
The MCP server exposes provenance verbs in-loop — create envelope, verify, and publish notes.
What the portal stores
Identity & billing
Email magic links, Stripe checkout, subscription state, and the customer billing portal.
Policy & audit
Team policy registry, queryable audit history, evidence-pack export, and entitlement lifecycle.
What leaves your machine · stays local
- ✓Commit envelopes are created and verified via the local CLI and hooks.
- ✓Repo contents and local scan results never leave the machine.
- ✓Emulated Ed25519 software signing ships today — not hardware-backed signing.
What leaves your machine · hosted
- →Identity, billing, and org membership.
- →Team policy registry and queryable audit history.
- →Hosted verification metering and evidence-pack export.
Privacy architecture
Local-first: everything that touches your repository stays on developer machines. Code is never uploaded to our servers — only envelope metadata, policy telemetry, and MCP baselines cross the hard firewall boundary.
You can export ssx360.evidence-pack.v1 JSON and verify it entirely offline. You own the proof; you do not rent it.
Unauthorized MCP surface drift exits with code 2 and fails the CI build — halting deployment with zero cloud dependency.
Dogfood SOC 2 readiness
SSX360 runs the same signing and gating workflow on our own repos. SOC 2 Type I is targeted Q3–Q4 2026 — readiness program underway, not a completed report. Never "SOC 2 certified."
Cryptography scope
Matrix Scroll SDK uses RFC 8032 Ed25519 commit envelopes. USB, NFC, and SE050 hardware signers remain Ed25519-only. Software signers may attach an optional FIPS 204/205 post-quantum overlay via matrixscroll[pqc] — never required for hardware envelopes.
Emulated software keys ship by default for full workflow evaluation; the SE050 secure-element path passed its first PoC milestone (bench-validated, Jul 2026) and remains an optional preview trust upgrade — same offline verifier contract — until productized. The on-chip Ed25519 key is non-exportable (generated on first boot, never leaves the chip) and every signature verifies in both the browser verifier and the CLI — see the enterprise hardware pilot brief.
Hypothesis-verified security properties (sign–verify roundtrip, tamper detection, wrong-key rejection) are documented in the SECURITY_PROPERTIES matrix. TLA+ models ship in formal/tla/ (Scroll Gate, dual-signature policy, canonical bytes) with TLC in CI.
Post-quantum timeline (POC 2)
Ed25519 is fast and correct on classical computers. A cryptographically relevant quantum computer breaks it via Shor's algorithm — same discrete-log math as secp256k1, not a Curve25519 special case.
Today: Ed25519 required on every envelope. Software signers may attach ML-DSA or SLH-DSA overlays (matrixscroll[pqc]). Hardware stays Ed25519 until firmware supports lattice signatures.
Migration: Team policy will require dual-verify (Ed25519 + PQC) before the estimated CRQC window. Full roadmap: CRYPTO_ROADMAP.md.
Security contact
Send security reports through the security contact form or email mission@ssx360.com.
A machine-readable disclosure file is available at/.well-known/security.txt.
Privacy stance
The customer promise is local-first commit provenance. Hosted systems are for authentication, checkout, license state, activation, and downloads. Any product telemetry must be explicit, documented, and separate from source upload.
Installer release gate
Desktop installers publish through a pilot or staging release gate. Verify every binary against SHA256SUMS.txt from the tagged GitHub Release before installation — checksum verification is required even after entitlement unlocks the download page.
Release gate status, installer readiness, and checksum reachability are exposed on the account-gated download page.
Open work
Third-party security audit and public threat model (POC 2 checklist in CRYPTO_ROADMAP / POC2_AUDIT).
Software bill of materials for release artifacts.
Dedicated vulnerability disclosure policy and security inbox.
Detached signature publishing for release artifacts.
npm @ssx360/verify browser/Node verifier package.
Trust center status
SSX360 is building toward SOC 2 Type I, then a Type II observation window. Procurement should treat this page, the sample evidence pack, and completed security questionnaires as the current attestation surface — not a completed SOC 2 report.
Operator runbooks for deploy, staging QA, and compliance mappings live in the compliance hub. Procurement questionnaires and the sample evidence pack on this site are the buyer-facing attestation surface — not a completed SOC 2 report.
Subprocessors and data handling
Hosted services may use Vercel (application hosting), Stripe (billing), Supabase (auth/account metadata), and GitHub (source and release automation). Commit envelopes and private source code remain local unless you explicitly export evidence.
Penetration testing is planned before enterprise procurement at scale. Vulnerability reports go to mission@ssx360.com.
Ready to prove it in your pipeline?
Start with an Authorization Pilot on protected branches, or evaluate agent commerce mandates with bounded spend and offline verification.