Snapshot 227073
Normalized text
Scripts and page chrome removed; this is what change detection compares.
Skip to main content Bytebase Security Details General practices Access to all internal systems is protected by multi-factor authentication. Access is restricted to those who require it to perform their job, and is regularly reviewed and revoked upon termination or when no longer needed. The entire codebase is open-sourced on GitHub. Code reviews are mandatory for all code changes. Dependencies are updated automatically through Renovate and Dependabot, and the software components are monitored for CVEs. 3rd party conducts penetration tests annually. We don't copy production data to external devices such as personal laptops. Bytebase overall architecture Backend is written in Go. Frontend is written in TypeScript and React. Metadata is stored in PostgreSQL. The Bytebase release is a single Go binary that uses Go embedding to embed the frontend assets as well as the PostgreSQL binary. In other words, one can start Bytebase simply by ./bytebase. For production, the metadata is stored in an external PostgreSQL instance (configured via PG_URL) instead of the embedded one. Bytebase runs with or without Kubernetes: a single container, a VM, or a Helm chart on an existing cluster. Bytebase Cloud All infrastructure is hosted on Google Cloud Platform us-central region. Each customer Bytebase workspace is running inside a separate container managed by Google Container Engine (GKE). The metadata is stored in a shared pool of Google Cloud SQL PostgreSQL instances. User authentication with Bytebase Cloud is via Auth0. Product usage analytics are sent to PostHog (listed on our subprocessors page). They never include schema, SQL, or query data. Collection can be disabled upon request in our Enterprise plan. The customer Bytebase workspace will be deactivated automatically if there is no traffic in 48 hours. The data will be purged in 60 days after deactivation. Bytebase self-hosted The architecture is similar to Bytebase Cloud. You can run Bytebase inside docker or on bare-metal. Anonymous usage metrics are sent to Bytebase's own telemetry endpoint (hub.bytebase.com), not to a third-party analytics vendor. They never include schema, SQL, or query data. Collection can be disabled in the workspace settings. Shared practices between Bytebase Cloud and self-hosted The registered email and name of the first member is sent to Bytebase. We use this to contact regarding sales opportunity, security updates, policy updates, and product updates. User/password authentication is enabled by default. SSO with the Bytebase workspace is configurable via OAuth 2.0, OIDC, or LDAP. 2FA and Sign-in restriction can be further enforced in the Enterprise plan. Repeated failed sign-in attempts lock the identity out temporarily; a successful sign-in resets the counter. AI data handling Bytebase does not use customer data to train or fine-tune AI models. Requests go from your Bytebase server straight to the provider you configure, using your own API key and endpoint. Nothing passes through or is stored on Bytebase services. A workspace has one provider and one endpoint. What each feature sends is listed in the AI Assistant docs. AI features are off until a Workspace Admin turns them on. In Bytebase Cloud, Bytebase configures the provider on your behalf. The built-in MCP server lets an AI assistant act as the signed-in user, under the same roles, masking, and audit log, and sends data only to that assistant. A Workspace Admin can restrict it or turn it off. Security controls in the product Bytebase sits between people and databases, so most of its security surface is the product itself. Identity and sign-in SSO via OAuth 2.0, OIDC, or LDAP, with optional enforcement: disallow password sign-in, restrict sign-up to approved email domains, and require 2FA for every member. SCIM directory sync provisions and deprovisions users and groups from Okta or Microsoft Entra ID. Password restrictions, configurable session and access-token lifetimes, and an idle-session timeout. Automation authenticates with its own identity: a service account or a workload identity that exchanges a short-lived GitHub Actions, GitLab CI, or generic OIDC token instead of holding a long-lived secret. Database credentials and connectivity Bytebase holds the database credentials; engineers never receive them. Access is granted through Bytebase roles, so there is no personal credential to leak. Credentials can be pulled at connection time from HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager, or Azure Key Vault instead of being stored in Bytebase. Cloud IAM authentication is supported where the database offers it. Connections support TLS/SSL with CA verification and SSH tunnels, and can use a separate read-only data source for queries. Access and data protection Fine-grained permissions are checked per statement. Standing access comes from roles; temporary access comes from approved, expiring access grants. Dynamic data masking masks sensitive columns in query results, and refuses queries whose conditions would probe a masked column. Query results can be limited, export can be restricted to a permission or an approved grant, and copying results can be disabled. Watermarks showing the viewer's identity can be rendered across the console. Auditability Every change and every query goes through a reviewable workflow, and the audit log records who did what, when, and from where, with secrets redacted from the recorded payloads. Audit logs can be streamed to stdout as structured JSON for ingestion by a SIEM or log aggregator. FAQ Which certifications does Bytebase have? SOC 2 Type II and HIPAA. Which data does Bytebase store? Bytebase stores the following data in its metadata database: Database connection info, or a reference to the external secret manager that holds the credential. Database schema metadata. Change history, query history, and audit logs. Bytebase does not store copies of your table data. Query results pass through to the SQL Editor and are not persisted. This includes the pre-change snapshot used for 1-click data rollback: Bytebase writes it to a bbdataarchive database or schema on the same instance as the changed table, never to its own metadata store, and you control its retention and cleanup. How do I report a potential vulnerability or security concern? Please reach out via our contact form. We'll get back to you ASAP. Explore the standard for database governance Cloud Self-host Ask ChatGPT about Bytebase Get an independent take on whether Bytebase fits your team. Ask ChatGPT