Skip to main content

Security and Trust Platform

VeloDB embeds security management across the software development and delivery lifecycle, including continuous vulnerability scanning and penetration testing, strict internal access control, and a secure development process. We believe that openness and transparency are how trust is earned, so we document how we operate and work closely with customers and partners on their security requirements. The VeloDB platform holds SOC 2 Type I and Type II reports.

Vulnerability Management​

Software vendors carry primary responsibility for losses caused by vulnerabilities in their software, so finding and remediating vulnerabilities quickly is one of our highest priorities.

We run automated code scanning for vulnerability analysis, and code cannot be merged until identified vulnerabilities are fixed. Before a software package is promoted to production, automated vulnerability detection tools scan the package, its third-party dependencies, and the deployment environment daily, so that vulnerabilities surface as early as possible. Each year we engage a third-party specialist team to independently assess potential risks in our software operating environment.

We also track newly disclosed vulnerabilities through open source communities, social media, and public vulnerability databases, ahead of coverage by detection tools, to reduce exposure to security attacks. The public vulnerability databases we monitor include CNNVD, CVE Trends, and Open CVDB.

Penetration Testing​

The VeloDB security team works with professional penetration testing providers on a systematic testing program that evaluates platform integrity and application security across the code, application, and system layers. We run penetration tests when major versions ship, when new service components launch, and when security-sensitive features are released. High-risk findings are typically resolved within a week.

VeloDB conducts one external third-party penetration test annually to help identify potential security risks. As part of our commitment to transparency, customers can request a third-party penetration test report for the VeloDB platform.

Internal Access Control​

VeloDB employees access internal systems and the production environment under the principles of least privilege and separation of duties, enforced through documented access controls and security policies.

Corporate Network​

VeloDB operates a standardized corporate network. All access to internal systems goes through the VPN and requires single sign-on. The network is divided into three segments for production, testing, and office use. Each segment runs on dedicated physical resources and VPCs, isolated from one another and tightly controlled.

Cloud Resource Management​

The VeloDB internal environment runs on cloud resources from public cloud providers. For production cloud resources, only designated security team members hold management permissions, and those accounts require multi-factor authentication (MFA) to prevent privilege abuse. Scanning and security policies keep plaintext credentials such as passwords and API keys out of the environment, and credentials are rotated on a regular schedule.

Operating System Access​

Day-to-day production operations run through an internal operations platform. The platform integrates with single sign-on and applies role-based access control (RBAC) to govern what each role can do. It provides the aggregated data, dashboards, and change deployment capabilities that daily operations require, which reduces the need to operate directly against production.

Production Environment Access​

VeloDB employees can request access to live production systems only under specific circumstances, such as recovering from an outage. Access is brokered by a bastion host that satisfies strict authentication, authorization, accounting, and auditing requirements. Production access uses STS-based authorization with least-privilege enforcement to prevent privilege abuse and operator error. All production activity is recorded as replayable sessions, which supports security auditing, root cause analysis, and incident investigation.

Secure Software Development​

VeloDB applies explicit security requirements across the full development lifecycle, covering design, development, testing, and release, and follows ISO/IEC 20000:2018 Information Technology Service Management System requirements.

Software Design​

Security and privacy considerations are part of the software design process. Designs for key functionality go through an additional review by the company security team. Designs that carry high security risk are not approved.

Software Development​

VeloDB source code is managed in a commercial source control system that supports multi-factor authentication and blocks password-based credential access. All developers complete secure development training during onboarding and annually thereafter. Merge requests must pass automated code scanning, functional acceptance testing, and peer review by at least two engineers before they can be merged.

Software Testing​

VeloDB runs extensive testing at every stage of the development lifecycle, with a total suite of millions of test cases. High-coverage unit tests verify fine-grained code logic. Integration, stress, chaos, and compatibility tests strengthen overall system robustness. Scheduled performance tests track how the latest code affects performance and catch unintended regressions. Scenario-based tests for common solution patterns simulate and validate behavior under production-like conditions.

Release and Change Management​

VeloDB follows a defined release and change process, and has built continuous delivery and deployment (CD) capabilities on top of it:

  • Software must pass the full regression suite before release. Once tests pass, the image is built and stored automatically.
  • Deployments follow a staged rollout, reaching the sandbox environment before production, with rollout granularity by region, by customer, and by other dimensions. If a problem appears mid-release, the automated pipeline can be halted at any point.
  • After a release, teams verify that the change achieved its objective and passes smoke tests.

Under separation of duties, only full-time members of the operations team can execute release changes, and every change goes through an approval workflow. For emergency changes, operators can obtain approval through an out-of-band channel such as a phone call, and record the change after it is applied.