Security
Compliance security should be mechanical: isolate tenants, preserve lineage, hash the evidence, and make verification possible without asking anyone to believe the UI.
These statements describe controls verified in source and pre-production staging. Production validation requires a release-evidence record bound to the deployed frontend and backend commits.
Verifier output
Sample · illustrative
$ python verify_chain.py --export fsma_package.json
verified: 430 records
failed: 0 records
manifest: hash matched
result: evidence package intact
Bundle
fsma_package.json
Export package selected by the customer workflow.
Manifest
SHA-256
Integrity check for records after ingest, not upstream entry proof.
Review path
Outside the UI
A supported bundle can be checked independently.
PostgreSQL row-level policies and authenticated tenant context are designed and tested to restrict cross-tenant access on core PostgreSQL-backed paths. Identity-resolution and graph-layer hardening is in active rollout; details available under NDA.
Committed compliance records are append-oriented after ingest, and corrections preserve lineage rather than mutating prior records.
Export bundles ship with a SHA-256 manifest so records can be checked outside the product UI. Legacy Kafka-compatible signing exists only for opt-in deployments.
CI includes secrets, SAST, and dependency checks. DAST, SBOM, and container scans run when configured or on scheduled/main-branch workflows.
Control surface
| Encryption | Encrypted transport in transit; encryption at rest provided by managed database and storage providers (see subprocessors) |
| Identity | JWT sessions, API keys, CSRF protection |
| Isolation | Tenant-scoped database access via PostgreSQL row-level policies on core PostgreSQL-backed paths |
| Audit | Tamper-evident export manifests covering records after ingest; upstream entry is not cryptographically attested |
| Verification | Open verifier script for export-bundle chain checks |
| Disclosure | security.txt and vulnerability intake |