This document outlines the security features and compliance posture of the software system. It is intended to provide customers and stakeholders with a clear understanding of the security mechanisms in place and the standards to which the system adheres.

​
Encryption

In Transit
  • All inter-service communication within the Kubernetes cluster is encrypted using mutual TLS (mTLS) via Istio service mesh.
  • All ingress and egress communication uses TLS 1.2 or higher.
At Rest
  • Data stored in blob storage is encrypted at rest using cloud-native encryption mechanisms (e.g., Azure Storage Service Encryption, AWS S3 Server-Side Encryption).
  • Encryption keys are managed by the underlying cloud provider and rotated according to provider best practices.

​
Secrets management

  • Secrets are securely managed using the CSI (Container Storage Interface) driver with support for:
    • Azure Key Vault
    • AWS Secrets Manager
    • Google Secret Manager
  • Secrets are mounted into pods at runtime and are never stored in plaintext in the cluster.
  • Access to secrets is controlled through fine-grained identity and access management (IAM) policies, tied to the workload identity.
  • Rotation of secrets is handled externally and reflected immediately via CSI mounts.

​
Authentication and authorization

  • End-user authentication is managed through Keycloak, which supports integration with external identity providers such as Azure Active Directory and Google Identity.
  • Authentication follows the OAuth2 and OpenID Connect standards.
  • Role-based access control (RBAC) is applied across the system.
  • Roles and Permissions:
    • Super Admin
    • General Developer
    • Billing

​
CI/CD and software supply chain security

  • Continuous integration and delivery (CI/CD) pipelines include:
    • Static code analysis
    • Automated testing
    • Software Bill of Materials (SBOM) creation
    • Vulnerability scanning using Grype
  • All container images are built from hardened, minimal base images and scanned prior to release.

​
Logging and monitoring

  • Logs are emitted to standard output and error streams (stdout/stderr) following container logging best practices.
  • Logs can be collected by pluggable logging agents (e.g., Elastic Agent) deployed into the Kubernetes cluster.
  • Centralized logging enables customers to integrate with their own observability solutions and meet internal audit requirements.
  • Metrics are emitted to an Otel Collector which can be configured to ship to various observability solutions.

​
Compliance

The system is designed and operated in accordance with industry-recognized security and data protection standards:
  • SOC 2 Type II: Controls are implemented and audited for security, availability, and confidentiality.
  • ISO 27001: Operational processes align with the ISO 27001 framework for information security management.
  • GDPR: Data handling practices conform to the General Data Protection Regulation (GDPR) for protection of personal data.
  • FedRAMP: The system meets the security requirements of the Federal Risk and Authorization Management Program (FedRAMP) for U.S. government systems.

​
Additional protections

  • Each workflow job runs in an isolated, ephemeral Kubernetes namespace to ensure strong runtime separation.
  • Namespaced service isolation within the Kubernetes cluster