CerynixIT products & services

Security & trust

Controls you can inspect. Boundaries we state plainly.

Cerynix is an IT company, and our GRC & Compliance Platform is a GRC platform, so we hold ourselves to the evidentiary standard we help you meet. Every claim below reflects what is implemented today — where something is planned rather than shipped, we say so. As new products launch, their security details will be linked from here too.

No third-party certifications — yet. You will not find a SOC 2 or ISO/IEC 27001 badge on this page, because we have not completed those audits, and we won't display badges we haven't earned. The product's own control library is aligned to ISO/IEC 27001:2022 and NIS2, and formal certification is on the roadmap. If a certification matters for your procurement, talk to us — we will show you the underlying controls and evidence directly instead of a logo.

Four claims, stated plainly

What actually protects your data today.

Tenant isolation

Every tenant-scoped query is authorized at the application layer and enforced again by PostgreSQL row-level security, forced on every tenant table as defense-in-depth and verified in CI as a non-superuser database role — not an admin bypass.

Tamper-evident ledger

Logins, permission changes, control status changes, evidence upload/deletion/export, risk acceptance and management approvals are recorded in an append-only, SHA-256 hash-chained audit ledger. A verification endpoint recomputes the chain on demand to confirm integrity.

Signed releases

Every released container image (api, web, proxy, control-plane, hq) is cosign-signed keyless via GitHub OIDC identity, with build provenance and an SBOM attestation. The self-hosted on-prem bundle is minisign-signed, ships its own SBOM (syft SPDX-JSON), a SHA256SUMS file and a signed release manifest.

Offline licensing

License keys are Ed25519-signed by us and verified locally by your instance's Control Plane. There is no license server and no mandatory phone-home — an optional control-plane check-in (license validation, update notices) only activates if you configure it.

How it's enforced, concretely

The mechanism behind each claim.

These are engineering controls we can point to in the codebase and CI, not marketing language.

Row-level security
Migration-applied RLS with FORCE ROW LEVEL SECURITY on every tenant table; a CI job runs the test suite against a real PostgreSQL as the same non-superuser role the application uses in production, to prove isolation holds — not just that policies exist.
Hash-chained audit ledger
Each entry is SHA-256 hash-chained to the previous entry per organization; /audit-logs/verify recomputes the chain to confirm no entry was altered or removed.
cosign + SBOM (managed images)
Images published to GHCR are signed keyless by digest via GitHub's OIDC identity — no signing keys to leak — with build-provenance and SBOM attestations attached to each image.
minisign + SBOM (on-prem bundle)
The on-prem release bundle is generated with an SBOM, signed with a minisign key pair, and published with SHA256SUMS and a signed release manifest recording the exact component versions.
Offline Ed25519 licensing
License keys are signed offline by the vendor and verified locally by your deployment; self-hosted installs run without any required phone-home.

Go deeper, or ask us directly

Read the full technical reference, or talk to us.

The complete technical write-up — encryption and secrets handling, authentication and access control, transport security, backups and resilience, sub-processors and responsible disclosure — lives on our support portal.

Read the full Trust & Security reference
Ask a security question