SOC 2 Security Posture & Compliance Roadmap

SOC 2 Security Posture & Compliance Roadmap

Tessara is engineered with a security-first, metadata-only architecture. This document outlines our current security posture and the strategic roadmap for achieving SOC 2 Type I compliance.

1. Security Posture Overview

Tessara’s security model eliminates the primary attack surface by design: we never store customer PHI or PII. The product reads only publicly available FHIR API metadata, compares it against regulatory specifications, and produces cryptographically signed conformance evidence.

1.1 Metadata-Only Architecture

  • Metadata-Only Analysis: Tessara probes the target API’s /metadata endpoint (CapabilityStatement) — a structural document containing no patient data, no claims data, and no PII
  • Local-First Processing: All analysis runs locally on the customer’s infrastructure. No data is transmitted to external services
  • No Persistent Customer Data: The only data Tessara stores is structural hashes and signed compliance verdicts in a local SQLite database

1.2 Cryptographic Integrity

  • Tamper-Evident Evidence Chains: All compliance verdicts are cryptographically signed using Ed25519 digital signatures
  • Hash-Linked Audit Trails: Each verdict contains a SHA-256 link to the previous verdict, creating an immutable chain. Any retroactive alteration is immediately detectable
  • Canonical Serialization: Structural metadata is canonicalized via RFC 8785 JCS before hashing, ensuring deterministic and reproducible digests
  • TLS Communication: All HTTP probes to target APIs use TLS. The dashboard API supports configurable TLS certificates

2. SOC 2 Trust Services Criteria Alignment

CriteriaTessara Control Implementation
SecurityLocal-first deployment; JWT + API key authentication; configurable TLS; SSRF defense (3-layer: URL validation, DNS resolution check, IP block list)
ConfidentialityZero customer data access — reads only public CapabilityStatement endpoints. No PHI/PII/PCI data ever enters the system
Integrity4-level Merkle hash tree validation (SHA-256); Ed25519-signed verdicts; hash-linked evidence chain with write verification
AvailabilitySingle-binary Go deployment with no external dependencies. SQLite storage requires no database administration
PrivacyNot applicable — Tessara does not process personal data of any kind

3. Compliance Roadmap (2026)

  • Q1 2026 (Completed): Core pipeline implementation — 10 components, 81% test coverage, Ed25519 evidence chain with tamper detection
  • Q2 2026 (In Progress): External security audit of the Structural Contract Model (SCM) and Merkle hashing engine. SSRF defense hardened (3-layer). Rate limiting and body size limits on API endpoints
  • Q3 2026 (Target): Type I engagement begins with first pilot revenue (target Q3 2026). Covering Security and Confidentiality Trust Services Criteria.
  • Post-Type I: Type II observation period begins immediately after Type I report issuance.

4. Technical Security Controls

4.1 Input Validation

  • All API probe targets are validated through a 3-layer SSRF defense: URL parsing, DNS resolution checking, and a custom HTTP dialer that blocks private IP ranges
  • Request body size limits prevent resource exhaustion
  • All user-facing endpoints are rate-limited

4.2 Dependency Minimalism

Tessara has only 2 external Go dependencies:

  • github.com/spf13/cobra — CLI framework (Apache 2.0)
  • modernc.org/sqlite — CGo-free SQLite driver (BSD)

This minimal dependency surface drastically reduces supply chain risk. Zero known vulnerabilities as of April 2026 (verified by govulncheck).

4.3 Evidence Chain Integrity

  • Every verdict written to the evidence chain is verified on write: the system re-reads the record immediately after INSERT and byte-compares against the original to detect storage corruption
  • Hash chain links are validated on read — any gap or alteration is flagged

For technical security inquiries or to request a penetration test summary, contact hello@tessara.us.