Stay organized with collections
Save and categorize content based on your preferences.
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.
Restricting Google Cloud administrative access to
customer resources for contractual support purposes, with
Access Transparency and
Access Approval,
and logging all such access.
Producing authentic SLSA provenance, 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.
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.
Providing Google with environmental details when requested for troubleshooting
purposes.
What's next
Read more
about the Google Cloud shared responsibility model.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-09-03 UTC."],[],[],null,["# Statement of shared responsibility for security\n\nRunning business-critical workloads on Cloud Build requires that multiple\nparties assume different responsibilities. The shared responsibility model\ndescribed in this document clarifies that Google Cloud is\naccountable for the security of the Cloud Build service itself and\nits underlying infrastructure, while you, the customer, are responsible for\nsecurity in how Cloud Build is used, including your specific builds,\nconfigurations, data, and the container images you execute using\nCloud Build.\n\nWhile not an exhaustive list, this page lists the respective responsibilities of\nGoogle Cloud and the customer.\n\nGoogle Cloud Responsibilities\n-----------------------------\n\n- Protecting the underlying infrastructure, including hardware, firmware,\n kernel, operating system, storage, and network.\n\n This includes the following:\n - Protecting the physical security of data centers, default encryption of data at rest and in transit, and secure network components.\n - Providing network protection using VPC Service Controls.\n - Following secure software development practices.\n - Managing and securing the Cloud Build service control plane (API, backend, schedulers, etc.), including patching and hardening.\n - Providing ephemeral, isolated build environments for each build invocation.\n- Providing Google Cloud integrations for\n [Identity and Access Management](/iam) (IAM),\n [Cloud Audit Logs](/logging/docs/audit), [Cloud Key Management Service](/kms/docs), and others.\n\n- Restricting Google Cloud administrative access to\n customer resources for contractual support purposes, with\n [Access Transparency](/assured-workloads/access-transparency/docs) and\n [Access Approval](/assured-workloads/access-approval/docs/overview),\n and logging all such access.\n\n- Producing authentic [SLSA provenance](https://slsa.dev/), when configured to\n do so.\n\nThe Customer's Responsibilities\n-------------------------------\n\n- Securing your application source code, build configuration files, and all\n container images used in your builds.\n\n This includes evaluating image suitability for your security standards,\n leveraging the latest supported image versions, and following best practices\n for open source components and overall build configuration.\n\n For scenarios demanding the highest degree of security, consider bringing your\n own hardened images for running builds.\n- Ensuring any 3rd-party integration tokens (such as those provided to establish\n a repository link) are appropriately safeguarded.\n\n- Configuring IAM for all users, groups, and service accounts\n interacting with Cloud Build, in accordance with the\n [principle of least privilege](/iam/docs/using-iam-securely).\n\n We recommend you use dedicated, user-specified service accounts for builds\n instead of default ones.\n\n Ensure that your build scripts make appropriate use of the provided build\n credentials, 3P integration tokens, and secrets that are made available to the\n build, and guard against exfiltration.\n- Enabling and acting on vulnerability scanning for build artifacts (for\n example, using Artifact Analysis), generating build provenance data,\n and implementing deployment policies (for example, using Binary Authorization) to\n ensure only authorized and verified images are deployed.\n\n- Providing Google with environmental details when requested for troubleshooting\n purposes.\n\nWhat's next\n-----------\n\n- [Read more](/architecture/framework/security/shared-responsibility-shared-fate) about the Google Cloud shared responsibility model."]]
