How Certus protects your evidence
Security is layered into the product, the platform, and the people who operate it. Below is a condensed view of the control stack we share with auditors and customers.
Encryption
TLS 1.2+ / AES-256
In transit and at rest
Identity
Auth0 SSO
SAML 2.0 + OIDC
Evidence
SHA-256 HMAC
Signed and tamper-evident
Isolation
Org-scoped
Query-layer enforcement
Platform security
- Infrastructure runs in AWS us-east-2 with dedicated VPCs, private subnets, and security groups enforced by AWS Control Tower.
- All workloads require mutual TLS; audit pipeline artefacts are signed with customer-provided KMS keys or Certus-managed HSM.
- Runtime shielding policy blocks unsigned containers. Cosign signatures validated on every deploy.
Authentication & identity
- Auth0 handles all user authentication. Supports enterprise SSO via SAML 2.0 and OIDC for customer identity providers.
- Session tokens are stored in secure, HTTP-only cookies with SameSite=Lax. No tokens are stored in localStorage or client-side JavaScript.
- API keys are hashed with SHA-256 before storage. Timing-safe comparison prevents timing attacks. Keys cannot be recovered — only regenerated.
- Canonical hostname enforcement (www.getcertus.cloud) ensures cookies are scoped to a single origin. Non-canonical requests receive a 308 redirect before any session is established.
Data protection
- Evidence ledger replicated across AZs. QLDB exports mirrored to customer-owned S3 on request.
- At-rest encryption via KMS multi-tenant keys (default) or customer-supplied keys (BYOK).
- Access to evidence bundles gated by attribute-based access control. Immutable trail stored for 7 years.
Audit trail & logging
- Every state-mutating action (scan uploads, org changes, API key regeneration, membership changes) is logged to an immutable audit trail.
- Audit entries include actor identity, action type, resource type/ID, and metadata. Entries cannot be modified or deleted.
- Dashboard administrators can view the full audit log for their organization at /dashboard/audit-log.
Multi-tenancy & isolation
- Each organization's data (repositories, evidence packs, findings, compliance controls) is scoped by org ID. Cross-org data access is prevented at the query layer.
- Users authenticate once and can belong to multiple organizations. Active org selection determines which data is visible. Org switching updates a server-side user record, not a client cookie.
- API keys are org-scoped. A key for Org A cannot access Org B's data.
Operations & monitoring
- 24×5 on-call with 15 minute response SLA; optional 24×7 support for GA customers.
- P0 playbooks include automated evidence rehydration tests and pilot communication cadences.
- Quarterly tabletop exercises covering insider threats, supply chain compromise, and regulator escalations.
How evidence signing works
Every evidence pack produced by Certus is cryptographically signed to guarantee integrity from creation to audit.
Step 1
Collect & hash
Scanner results, control mappings, and metadata are assembled into an evidence pack. A SHA-256 digest is computed over the entire payload.
Step 2
Sign
The digest is signed with HMAC-SHA256 using a per-organization secret. Enterprise customers can use their own KMS key for signing.
Step 3
Verify
On retrieval, the stored signature is recomputed and compared. Any modification to the pack — even a single byte — causes verification to fail.
Found a vulnerability?
We maintain a responsible disclosure program with 24-hour response SLA and researcher credit.