Network, Data and Information Security

Technology Stack

The platform runs on Google Cloud Platform (GCP) and MongoDB Atlas. Application services are containerized and orchestrated on Kubernetes (Google Kubernetes Engine, Autopilot mode). PostgreSQL runs in-cluster as a StatefulSet on persistent storage; MongoDB Atlas serves as the data lake and file storage layer. The frontend is built with ReactJS and the backend with Node.js.

Network Architecture

The system runs inside a Google Cloud Virtual Private Cloud in a single region, with the Kubernetes cluster spread across three availability zones for high availability. All application workloads run in a single Kubernetes namespace.

Public subnet — the only internet-facing addresses. Exactly three addresses sit at the network edge, and only two of them accept inbound traffic:

• Gateway load balancer — the sole HTTPS entry point (port 443), provisioned by a Kubernetes Gateway resource and terminating TLS with a Google-managed certificate

• MQTT load balancer — a dedicated LoadBalancer Service exposing TCP 8883 for tooling clients, gated by authentication at the application layer

• Cloud NAT gateway — outbound egress only, from a static address; it is not reachable from the internet

Private subnet — application workloads. The Kubernetes nodes carry no external IP addresses. Inbound HTTPS traffic is handed to a single internal nginx Service, whose pods apply security headers and route each request to the appropriate cluster-internal Service. Every application Service — the API services, the web front-ends and the code analysis services — is exposed only within the cluster, never directly to the internet. Access to Google APIs uses Private Google Access, so those calls do not traverse the public internet.

Stateful services — PostgreSQL, HashiCorp Vault and the MQTT broker each run as a StatefulSet with its own persistent volume and are reachable only from inside the cluster.

External data services — MongoDB Atlas is reached over a private, peered network path, and Google Vertex AI over Private Google Access.

Application secrets (API keys, service credentials, signing keys) are held in an in-cluster HashiCorp Vault and injected into services at runtime; file-based credentials are delivered as Kubernetes Secrets mounted into the pods that need them. No secret material is stored in application code or container images.

Data Flow

Integrated product data reaches the platform by one of two paths, which differ in whether anything is kept:

Retained path. Integrations that are synced on a schedule are pulled by the Data Loader, a Deployment in the application namespace. It authenticates using integration tokens issued from the in-cluster Vault, and writes the extracted content to the Data Lake (MongoDB Atlas), where collections are partitioned per tenant and Voyage AI embeddings are generated in place. The Data Loader writes only to the data lake. This path covers three integration categories:

• Planning — Jira Software, Jira Software Data Center, ADO Boards

• Requirements Management — Confluence, Figma, Google Drive, OneDrive

• Customer Feedback — Jira Service Management, Jira Software for Support, Freshdesk, Zendesk

Transient path. Code integrations — GitHub, Bitbucket, GitLab — are read at request time by the Context Engine and are never written to the data lake. Source content pulled this way is parsed in memory by the code analysis pods and is not persisted.

Serving path. Requests from platform users arrive over HTTPS and are handled by the Context Engine — the API pods in the application namespace, entered through the Gateway and the nginx reverse proxy. The Context Engine reads retained context from the data lake, reads and writes user and application metadata in the in-cluster PostgreSQL StatefulSet, and sends the prompt together with the retrieved context to Google Vertex AI for inference. Tenant-scoped access control is enforced on every request, and no request may be read across tenants.

Data transfer security uses private network peering, TLS, or inter-service encryption depending on context. Data is encrypted at rest in both stores.

Information Security Measures

• Information Security Officer oversight

• Incident Management and Response Policy

• Vulnerability Management processes

• Multi-level data encryption using GCP-managed services

• Regular backup capability, up to the last 1-hour state

• Endpoint security including antivirus and disk encryption

Software Development Lifecycle

The organization follows agile methodology with specialized squads handling design, platform development, application development, deployment, and testing. Code management includes GitHub branches, mandatory peer reviews, unit testing, static analysis via Sonarqube, and automated build and deployment via Jenkins, with container images deployed to Kubernetes.

Compliance

The platform maintains SSAE 18 SOC 2 Type 1 certification and ISO/IEC 27001:2022 assessment.

For any further information (on SOC/ISO) or to request an abridged version of our SSAE 18 SOC 2 report, please contact us at info@cubyts.com