Security
Orch8 runs code, stores workflow state, and may hold credentials. This page describes implemented controls and operator responsibilities. It is not a certification or a substitute for reviewing the version you deploy.
The server supports API-key authentication and tenant-scoped access. Cross-tenant storage lookups carry tenant identity in their signatures. Operators remain responsible for key distribution, rotation, network exposure, and database access.
With a 256-bit key configured, the storage wrapper uses AES-256-GCM for credentials, workflow context, block outputs, worker parameters, signals, checkpoints, step logs, and other protected state. The server refuses to start without a key unless an explicit insecure-storage flag is supplied.
Workflows reference stored secrets through credentials:// identifiers. Provider tokens, idempotency, TLS trust, and the behavior of third-party handlers are still part of your application threat model.
The engine repository includes dependency policy configuration, locked dependencies, security tests, and release tooling for checksums, SBOM evidence, and provenance attestations. Verify the evidence attached to the exact artifact you deploy.
The latest internal review remains a historical engineering record, not an external audit. It identifies open design work around scheduler tenant scoping, a synchronous gRPC authentication path, DNS-rebinding windows in outbound URL validation, expression-depth limits, and CDN endpoint enforcement. Do not market a deployment as confidential or sovereign without an independent review of its complete threat model.
Read the audit notes in the repository →Do not open a public issue. Email security@orch8.io. We aim to acknowledge receipt within 48 hours and provide an initial assessment within seven days.