Security processes and secure data management

CloudBees SDM is a preview, with early access for select preview members. Product features and documentation are frequently updated. If you find an issue or have a suggestion, please contact CloudBees Support. Learn more about the preview program.

CloudBees has a dedicated operations team that manages the CloudBees production environment and other environments within the CloudBees infrastructure.

Production data and infrastructure access

Production data and infrastructure for CloudBees SDM are housed in a production environment accessible only to operational team members and lead CloudBees SDM product engineers. This is a very small, core group.

Code deployments and quality checks

All commits to the CloudBees SDM codebase have to go through a pull request review by at least one other team member before being merged into the master branch.

Deployments are done automatically by the continuous integration system. Only the CI system has the credentials to deploy to the staging and production environments.

Data retention policy

At present, data is stored in perpetuity. A CloudBees Operations engineer with the correct permissions can purge data as a manual action on request.

Data deletion policy

At present, no data is deleted. You can request data removal by contacting CloudBees.

Passwords and secrets

No passwords or security credentials are stored in the source code. All credentials are securely stored in a secrets management system, either Vault or as Kubernetes secrets. The production infrastructure reads these credentials dynamically at startup. Only the production infrastructure has the credentials to read this data from Vault; engineers do not.

Multi-tenancy environments and record-level isolation

CloudBees SDM has been architected to support a multi-tenancy environment that uses record-level isolation so that data in each row is specific to a user profile in the database. Other customers cannot search or view your data. Customers do not have direct access to their data and can only view their own information via the CloudBees SDM user interface. Customer-specific integration data such as GitHub Enterprise credentials are stored in a separate configuration store/database and encrypted at rest in the same manner as other services (see below).

For details about CloudBees' data privacy policy and security policy, review the CloudBees Support and maintenance terms & conditions.

Automated security scanning practices

CloudBees product teams use SonarQube to perform routine static analysis security scanning. SonarQube is used to scan the front-end JavaScript repository.

This is done on each merge to the master branch of the CloudBees SDM front-end repository. The SonarQube quality profiles and gates have been tuned for each project to help separate the signal from the noise.

CloudBees SDM also uses WhiteSource and Anchore to scan every deployment to detect and prioritize work on security issues found in open source components, as well as keep our Software Bill of Materials up to date.

How the CloudBees SDM service is hosted

The CloudBees SDM service is hosted in a Virtual Private Cloud in Google Cloud Platform (GCP) from one of Google’s data centers in the United States, currently in us-central1.

Data is stored in PostgreSQL and encrypted at rest.

How data is encrypted in transit and at rest

All information and requests are transmitted over HTTPS. Data in transit uses Transport Layer Security 1.2 (TLS1.2). Data is also encrypted at rest and in transit. All data is encrypted in transit between the end-user and the CloudBees SDM; and between third-party systems, such as GitHub and Jira, and CloudBees SDM.

We specify current strong cipher suites, and continue to monitor industry trends and best practices via external monitoring to ensure we’re up to date with our cipher suite listing.

Data is scoped at the organization profile level, and data identifiers are prefixed with an organization’s unique id, created when the user profile is generated.