Securing your data in Continuous Delivery

The Continuous Delivery service encrypts customer-owned sensitive data before it stores it in databases that are used internally by the service.

IBM Cloud® Continuous Delivery hosts your databases in a highly available and secure environment:

Data is encrypted at rest (GPFS, LUKS, and built-in disk) and in transit (HTTPS and SSH) by using encryption keys that are internal to the Continuous Delivery service, or the services and infrastructure that it depends on.
Client and system credentials are stored on encrypted disks.
Configuration data for tool integrations and Delivery Pipeline property values might include sensitive information. This data is encrypted by using encryption keys that are internal to the Continuous Delivery service because it is stored in databases that are internal to the service.
The application and data are configured for high availability.
Access to data is limited to only those users who require the data to support and maintain the service.

Continuous Delivery does not support encryption that uses customer-provided keys.

Protecting your sensitive data in Continuous Delivery

Sensitive data includes third-party tool integration configuration data and Delivery Pipeline property values. Data is encrypted by using encryption keys that are internal to the Continuous Delivery service.

DevOps processes often require various types of credentials (such as usernames and passwords, API keys, service keys, and SSH keys) to interact with other systems to build, test, and deploy applications. You are responsible for ensuring that these credentials aren't inadvertently shared outside of their intended audience. Access to these credentials by malicious actors might disrupt your IT operations, cause unexpected costs, or use your resources to start attacks. IBM is not responsible for protecting and maintaining the security of your credentials.

To keep your credentials secure, make sure that you follow this guidance:

Do not store credentials in Git repos. Depending on the repo settings, files within a repo might be visible to other members of your organization, other IBM Cloud users, or the public internet.
Do not include user credentials in Delivery Pipeline definitions because they might be visible to other users. Specifically, do not place user credentials within Delivery Pipeline Classic job definition scripts, Delivery Pipeline Tekton yaml files, or scripts that are started by delivery pipelines.
Do not publish user credentials in log files that are created when a pipeline runs because these files might be shared.

IBM Cloud provides several options that you can use for secure key storage and secrets.

For more information about secure DevOps best practices, see DevOps Security.

Protecting your data when you use third-party tool integrations

When you configure a tool integration for a toolchain, you explicitly enable data sharing between the Continuous Delivery service and the tool integration. The kind of data that is shared, and whether data is sent to the tool, received from the tool, or both, varies depending on the type of tool integration.

Before you configure a tool integration, make sure you understand what data is shared. If you work with regulated data or sensitive data, ensure that the third-party tools and any data that might be shared with it do not compromise the confidentiality, integrity, or availability of your resources, or otherwise violate regulatory controls.

To learn more about tool integrations, see Configuring tool integrations.

Protecting your data when you use Git Repos and Issue Tracking

Git Repos and Issue Tracking is an IBM-hosted component of the Continuous Delivery service. All of the data that you provide to Git Repos and Issue Tracking, including but not limited to source files, issues, pull requests, and project configuration properties, is managed securely within Continuous Delivery. However, Git Repos and Issue Tracking supports various mechanisms for exporting, sending, or otherwise sharing data to users and third parties.

The ability of Git Repos and Issue Tracking to share information is typical of many social coding platforms. However, such sharing might conflict with regulatory controls that might apply to your business. After you create a project in Git Repos and Issue Tracking, but before you entrust any files, issues, records, or other data with the project, review the project settings and change any settings that are necessary to protect your data. Settings to review include visibility levels, email notifications, integrations, web hooks, access tokens, deploy tokens, and deploy keys.

Project visibility levels

Git Repos and Issue Tracking projects can have one of the following visibility levels: private, internal, or public.

Private projects are visible only to project members. This setting is the default visibility level for new projects, and is the most secure visibility level for your data.
Internal projects are visible to all users that are logged in to IBM Cloud.
Public projects are visible to anyone.

To limit project access to only project members, complete the following steps:

From the project sidebar, click Settings > General.
On the General Settings page, click Visibility > project features > permissions.
Locate the Project visibility setting.
Select Private, if it is not already selected.
Click Save changes.

Project email settings

By default, Git Repos and Issue Tracking notifies project members by way of email about project activities. These emails typically include customer-owned data that was provided to Git Repos and Issue Tracking by users. For example, if a user posts a comment to an issue, Git Repos and Issue Tracking sends an email to all subscribers. The email includes information such as a copy of the comment, the user who posted it, and when the comment was posted. To turn off all email notifications for your project, complete the following steps:

From the project sidebar, click Settings > General.
On the **General Settings **page, click Visibility > project features > permissions.
Select the Disable email notifications checkbox.
Click Save changes.

Project integrations and webhooks

Git Repos and Issue Tracking projects might also be configured with integrations or webhooks to other systems, or equipped with access tokens, deploy tokens, and deploy keys. To review or change the integrations, webhooks, tokens, and keys that might be configured with your project, from the project sidebar, complete the following steps:

From the project sidebar, click Settings.
Click Integrations to work with your project's integrations with other applications.
Click Webhooks to work with your project's webhooks to other systems.
Click Access Tokens to work with access tokens that might grant access to your project.
Expand Deploy Tokens to work with the deploy tokens that might grant access to your project.
Expand Deploy Keys to work with deploy keys that might grant access to your project.

To learn more about working with Git Repos and Issue Tracking, see Git Repos and Issue Tracking.

Protecting your data when you use Delivery Pipelines

Continuous Delivery pipelines run the jobs and steps that you provide. The Continuous Delivery service securely manages the log output and build artifacts that are produced by your pipeline runs. However, Continuous Delivery does not limit or manage the function of your pipeline job or step scripts.

When you develop and configure your pipeline job and step scripts, ensure that your scripts do not run actions that might compromise the confidentiality, integrity, or availability of your resources, or otherwise violate regulatory controls.

To learn more about Delivery Pipelines, see and Working with pipelines and Working with Tekton pipelines.

Deleting your data from Continuous Delivery

When you delete a Continuous Delivery service instance, the related toolchains, tool integrations, tools, and data (including personal data) are not deleted. For more information about how to manage and delete data that is stored with toolchains, tool integrations, and tools, see Modifying, exploring, and deleting personal data.