Running business-critical workloads on Cloud Build requires that multiple
parties assume different responsibilities. The shared responsibility model
described in this document clarifies that Google Cloud is
accountable for the security of the Cloud Build service itself and
its underlying infrastructure, while you, the customer, are responsible for
security in how Cloud Build is used, including your specific builds,
configurations, data, and the container images you execute using
Cloud Build.

While not an exhaustive list, this page lists the respective responsibilities of
Google Cloud and the customer.

## Google Cloud Responsibilities

- Protecting the underlying infrastructure, including hardware, firmware,
  kernel, operating system, storage, and network.

  This includes the following:
  - Protecting the physical security of data centers, default encryption of data at rest and in transit, and secure network components.
  - Providing network protection using VPC Service Controls.
  - Following secure software development practices.
  - Managing and securing the Cloud Build service control plane (API, backend, schedulers, etc.), including patching and hardening.
  - Providing ephemeral, isolated build environments for each build invocation.
- Providing Google Cloud integrations for
  [Identity and Access Management](https://docs.cloud.google.com/iam) (IAM),
  [Cloud Audit Logs](https://docs.cloud.google.com/logging/docs/audit), [Cloud Key Management Service](https://docs.cloud.google.com/kms/docs), and others.

- Restricting Google Cloud administrative access to
  customer resources for contractual support purposes, with
  [Access Transparency](https://docs.cloud.google.com/assured-workloads/access-transparency/docs) and
  [Access Approval](https://docs.cloud.google.com/assured-workloads/access-approval/docs/overview),
  and logging all such access.

- Producing authentic [SLSA provenance](https://slsa.dev/), when configured to
  do so.

## The Customer's Responsibilities

- Securing your application source code, build configuration files, and all
  container images used in your builds.

  This includes evaluating image suitability for your security standards,
  leveraging the latest supported image versions, and following best practices
  for open source components and overall build configuration.

  For scenarios demanding the highest degree of security, consider bringing your
  own hardened images for running builds.
- Ensuring any 3rd-party integration tokens (such as those provided to establish
  a repository link) are appropriately safeguarded.

- Configuring IAM for all users, groups, and service accounts
  interacting with Cloud Build, in accordance with the
  [principle of least privilege](https://docs.cloud.google.com/iam/docs/using-iam-securely).

  We recommend you use dedicated, user-specified service accounts for builds
  instead of default ones.

  Ensure that your build scripts make appropriate use of the provided build
  credentials, 3P integration tokens, and secrets that are made available to the
  build, and guard against exfiltration.
- Enabling and acting on vulnerability scanning for build artifacts (for
  example, using Artifact Analysis), generating build provenance data,
  and implementing deployment policies (for example, using Binary Authorization) to
  ensure only authorized and verified images are deployed.

- Choosing a [release channel](https://docs.cloud.google.com/build/docs/release-channels) that matches your
  security posture and tolerance for change.

- Providing Google with environmental details when requested for troubleshooting
  purposes.

## What's next

- [Read more](https://docs.cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate) about the Google Cloud shared responsibility model.