Security

OrionHub is a multi-tenant DevSecOps platform that holds credentials, source-control tokens, and audit data for its customers. This page documents the technical and organizational measures we use to protect that data and how to report suspected vulnerabilities.

1. Report a vulnerability

2. Coordinated disclosure policy

• We follow a 90-day coordinated disclosure window. We’ll work with the reporter to ship a fix; once the fix is deployed (or 90 days elapse, whichever comes first), we coordinate public disclosure.
• Safe harbor: Nexagen will not pursue legal action against researchers who:
  • Test only against their own tenant or accounts.
  • Do not access, modify, or delete data belonging to other tenants.
  • Do not disrupt service for other users (no DoS, no automated scanners running at high volume).
  • Report findings via the channel above before disclosure.
• Bounty awards may be offered on a per-finding basis at our discretion. Reach out at the address above; we do not run a public bounty program.

3. Out of scope

• Findings on third-party services we depend on (report to that vendor).
• Best-practice recommendations without a demonstrated exploit (header settings, cookie flags) — happy to receive, but lower priority.
• Vulnerabilities requiring physical access to a user’s device.
• Volumetric DoS / DDoS.
• Social engineering of Nexagen employees or customers.

4. Technical controls

Identity

• Keycloak OIDC authentication; SSO supported via SAML / OIDC federation.
• Five-role RBAC: platform_admin > owner > maintainer > developer > reader.
• Optional enforced MFA at the Keycloak realm level for enterprise customers.

Cryptography

• TLS 1.2 minimum on all public endpoints; HSTS enforced; modern cipher suites only.
• Secrets at rest: HashiCorp Vault Transit (AES-256-GCM). Plaintext values never persist in our primary database.
• RDS storage encryption with customer-managed KMS keys (AES-256).
• S3 server-side encryption (SSE-KMS) on every bucket.
• Cross-region backup keys are distinct from the primary region keys.

Tenant isolation

• Postgres Row-Level Security (RLS) policies on every tenant-scoped table. A SQL bug in application code cannot leak across tenants.
• Cross-tenant routes (admin endpoints) are gated by a separate platform-admin role and explicitly disable RLS for the read; they cannot decrypt secret values.

Audit logging

• Every state-changing API call writes an audit row.
• Rows include actor (user_id), tenant_id, action, resource_type, resource_id, and a structured detail payload.
• Retention: 395 days minimum (1 year + 30-day buffer).
• Write-only application role; reads require a separate query-only role to prevent app-bug tampering.

Network & infrastructure

• VPC isolation; application + database in private subnets; only ALB / CloudFront in public subnets.
• AWS WAF managed rule sets (Core, Known Bad Inputs, SQLi) on the public ingress.
• CloudTrail enabled in all regions with logs to a write-protected, separately-keyed S3 bucket.
• GuardDuty enabled across the account.
• Principle-of-least-privilege IAM with no long-lived access keys for service principals.

Software supply chain

• SBOMs generated for every release via CycloneDX.
• Dependency scanning on every PR (SCA + license).
• Container image scanning; signed images via Cosign.
• Reproducible builds using locked dependency manifests.

5. Compliance posture

• AWS Marketplace: published per Data Handling Disclosure and the AWS Marketplace SaaS guidelines.
• GDPR + CCPA: see the Privacy Policy. Standard Contractual Clauses available for EU/UK personal data.
• U.S. Government: AWS GovCloud deployment supported for IL5 use cases under separate engagement. IL6 / SIPR is not in scope at this time.
• SOC 2 Type II: in progress — observation period scheduled for 2026 calendar year.

6. Incident notification

If we identify a security incident that affects customer data, we will notify affected tenant Owners and Platform Administrators within 72 hours of discovery, via the email on file plus an in-product banner. Notification includes: the nature of the incident, data classes affected, customer-specific impact (where known), the remediation taken, and recommended customer actions.

7. Status

Real-time platform status: status.orionhub.io (placeholder — live status page deployment is part of operational rollout).