In this article we cover an overview of the platform's technology stack, the networking and data flow architecture, the information security policies and the internal SDLC processes.
Technology Stack
Infrastructure provider: GCP and Mongo Atlas
Region:
South Asia for production database, app servers and load balancer.
US-central for the AI models end-points.
Database service:
PostgreSQL on Cloud SQL.
MongoDB on Atlas.
Embeddings in Weviate.
Programming stack:
ReactJS for UI.
NodeJS and Python for backend.
Network Architecture
(Network architecture)
The Cubyts network architecture leverages the GCP Virtual Private Cloud (VPC) infrastructure to run the platform in a controlled, private and secure environment. The key characteristics of the architecture are as follows:
Availability zone: The entire infrastructure is on multiple availability zones within an GCP region.
Public subnets: The public subnets are routed using a route table that has a default route to the internet via an internet gateway.
The NAT instance in the public subnet allows the private instances to initiate outbound internet traffic and other managed services workloads leveraged by the Cubyts architecture.
The NAT instance is highly available in a single availability zone.
Private subnets for Cloud VM instances: The private subnet on multiple availability zones contains an infrastructure that is not directly accessible to the internet (this infrastructure has only private IPs). The resources in the private subnet (Cloud VM) gain access to the internet or other services using the NAT instance.
GCP Managed services: The Cubyts architecture leverages managed service resources like Pub/Sub, Cloud Function, Cloud SQL, etc, the scale and configuration from an availability zone is managed by GCP.
MongoDB Atlas Services: MongoDB atlas is our data lake where Cubyts stores the data it consumes from the products with which it integrates.
Weviate Vector DB: Weviate vectorization is used in the Cubyts pattern engine.
Gen AI end points: Cubyts prediction engine uses Gen AI end points (which are configured in the US-central region).
Note: All systems storing data are located in the South Asia region (except the Gen AI end-points as stated earlier).
Data flow
(Data flow)
User and Application Metadata Subsystem: All user and application metadata are stored in Cloud SQL (postgresql) which is inside the VPC. Data is irreversibly encrypted where applicable.
Data Loader Subsystem: The data loader subsystem is located inside the VPC. It fetches the tokens for the respective products from the Cloud SQL (postgresql) and extracts data from them. The extracted data is stored in the data lake subsystem.
Data Lake Subsystem: The data lake subsystem is based on MongoDB (Atlas) and stores all the data Cubyts extracts from the products, with which it integrates (Jira, Figma etc). The integration with the other subsystems located in GCP happens via VPC peering. The data here is massaged to create data points and expose them as raw and processed insights. For this, The Cubroid subsystem is used.
Cubroid Subsystem (Pattern engine): This is the AI/ML based subsystem which helps customers draw insights and make interventions based on the data. It makes use of the services offered by the Weviate vector database.
Products with which Cubyts integrates: There are two kinds of products with which Cubyts integrates:
The first group of products are the ones from where Cubyts extracts and stores data in the data lake - These are products like Jira, Figma, Freshdesk etc.
The second group of products are the ones where Cubyts extracts data on the fly to draw insights but does not store them anywhere. These are products like Github, BitBucket, Jenkins etc.
Data transfer between subsystems: Data transfer between subsystems are secured in three different ways depending on the context:
VPC Peering: There are cases where the subsystems are located inside different VPCs. In these cases, the connection is secured via a private VPC peering.
TLS: There are cases where data exchange between two subsystems happens via REST, in which case TLS is used to secure the data exchange.
Inter-subsystem encryption: There are cases where data exchange between two subsystems does not happen via REST and in such cases, the data is secured via encryption.
Information security policy
Cubyts is committed to safeguarding the data in its possession. Our customers and other stakeholders depend on us to protect their resources. We have taken the following measures and initiatives to make information security as a company wide initiative and a policy at Cubyts, the key aspects are as follows:
Information Security Officer (ISO): The Information Security Officer leads all the information-security efforts of the company. The Information Security Officer is responsible for identifying potential security threats and risks to the organisation, formulating and implementing policies and procedures to combat such threats, and monitoring the efficacy of existing systems.
Incident Management: We have a comprehensive Incident Management and Response Policy that outlines guidelines for reporting and responding to security incidents in an efficient manner.
Vulnerability Management: We have a well defined process of identifying, classifying, prioritising, mitigating, and remediating security vulnerabilities.
Data Classification: The classification of data as public data (that can be shared), Company confidential (that should not be disclosed), Customer confidential (which includes encrypted data in the Cubyts platform including PII data of our users), Personal data (all data that relates to an identified or identifiable individual or person) and it comprehensive management (technology and otherwise) is in place to manage the sanctity of data types.
Data backup:
The data in the platform is periodically backed-up with the ability to restore up to the last 1 hour state is part of the platform back-up policy.
Periodic drills enable us to ensure that the data is restored as quickly as possible to ensure minimal disruption of service.
The implementation of the status page ensures that our customers are aware of any downtime and maintenance schedules.
Data processing: As a GDPR and SOC compliant company, we have a comprehensive data processing policy (documented in our legal policies here).
Data encryption: We apply multiple levels of data encryptions to ensure sufficient protection of data managed by the Cubyts platform:
The database is encryption using state of the art algorithms offered as a service by GCP.
Important data in the database including PII data is further encrypted (second level of data security) using GCP Key management services and cryptography algorithms offered by GCP.
Endpoint security: Whilst the infrastructure is protected, the end point access to the infrastructure is equally protected to ensure protection against unauthorised access to systems and data, the following initiatives ensure endpoint security:
Endpoint hardware use antivirus software to protect themselves and critical systems from Malware attacks.
The hard disk of Endpoint hardware is encrypted e.g. using Filevault on Mac or disc encryption in Windows.
Staff adhere to centrally monitored strong password policy augmented by auto-screen-lock on their systems within a reasonable amount of inactive period.
In addition, data transfer from the end point devices is controlled as per the internal policies.
An Overview of Software Development Life Cycle Policy
The (secure) SDLC Policy at Cubyts as mandated by compliances like SOC, is structured ensure that the product is as built securely as possible, is taken through multiple types of testing & validation, is deployed without the need for human intervention and is continuously scanned for vulnerabilities; the various stages can be explained as follows:
The creation process:
The creation process at Cubyts is divided into multiple stages namely: the design stage, the product definition stage, the build stage and the deployment stage.
Cubyts uses Jira for planning and executing these stages albeit usage of different platforms for producing outcomes e.g. Figma for Design, VS code for build, Jenkins for deployment, Github for code commits and Ghost inspector for automation.
Cubyts follows agile methodology with focussed squads for the aforementioned stages: the design and product definition squad for concept and definition, the platform squad for reusable platform services, the application squad for the Cubyts application, the deployment squad for deployment automation and the test squad for manual and automation validation.
The hand-offs between the squads (in sprints, on the Cubyts platform) ensures seamless transfer of assets between the squads leading to effective creation.
Commit, Monitor and Review process:
The code is committed to GitHub which is used as the Code repository platform.
Github is structured to have multiple branches for development, quality and production systems; the process to move code between repositories is well defined based on roles in GitHub.
(Application/Platform and Test) Engineers at Cubyts are encouraged to make smaller/atomic code changes on their feature/bug branches to ensure faster development, review and subsequent deployment to aid continuous integration.
No code is accepted for merge unless a PR review is raised and the PR is accepted by at least 1 peer (more than 1 in a few special cases). A Tech Lead is involved in the peer review process as per the review standards of the company.
No code is allowed to check-in unless the engineer completes the unit test cases and static code analysis (using Sonarqube) for code quality and security.
Dependobot utility in Github (enabled by Cubyts) is used to track and fix code vulnerabilities on a regular basis (an expectation from a SOC compliant organisation).
Validation at Cubyts is a perfect amalgamation of manual testing (for visual testing, deep workload testing) and automation testing using Ghost inspector (for regression testing).
The entire deployment pipeline at Cubyts is automated using tools like Jenkins (for code automation), Terraform scripts (infrastructure as code) and various GCP automation services for end to end automation with minimal to no human intervention hence reducing the chances of any error.
SSAE 18 SOC2 compliance
The Cubyts platform is SSAE 18 SOC 2 Type 1 compliant as of Jan 1st 2025. We are happy to share an abridged version of the report on Security, Confidentiality and Availability on demand.
Conclusion
Thank you for taking the time to delve into the Network, Data and Information Security aspects of the Cubyts platform. Our commitment to leveraging AI and data to enhance SDLC experience underscores our dedication to improving the efficacy, efficiency and quality of product development for your teams. By unifying insights and streamlining execution, Cubyts not only addresses the complexities of modern product stacks but also empowers teams to make informed decisions and achieve better outcomes.
As we continue to innovate and evolve, we remain steadfast in our mission to provide a secure, scalable, and insightful platform that meets the dynamic needs of today's product leaders. We appreciate your interest and look forward to supporting your journey towards more effective and observable product development.
For any further information or to request an abridged version of our SSAE 18 SOC 2 report, please contact us at [email protected]
About Cubyts
Cubyts is your AI Assistant for Proactive SDLC Governance, Cubyts integrates seamlessly with tools teams use (e.g. Jira, GitHub, Figma, Jenkins, etc.) to build their products; the platform enhances the development process with real-time insights, proactive flagging of potential issues, and data-driven decision-making, that ensures superlative Developer, Engineering and Execution excellence.
Was this article helpful?
That’s Great!
Thank you for your feedback
Sorry! We couldn't be helpful
Thank you for your feedback
Feedback sent
We appreciate your effort and will try to fix the article