GCP's serverless platforms have converged on buildpacks as the default packaging path: you push source, the platform runs Cloud Build with the Google Cloud buildpacks, and a few minutes later you have a container image deployed to Cloud Run or to a Cloud Functions 2nd gen service. The experience is genuinely smooth, and for teams that do not want to maintain Dockerfiles it removes a real chore. But the smoothness obscures a fact that matters for supply chain security: buildpacks fetch dependencies from public registries at build time, the build runs as a service account with broader permissions than most teams realize, and the resulting image carries layers you did not write.
This post is about the 2026 controls for the buildpack and Cloud Build path. We assume you have services running on Cloud Functions 2nd gen or Cloud Run that were built this way and you are evaluating where the supply chain risk sits and how to reduce it without giving up the developer experience entirely.
What does the buildpack actually pull in at build time?
The Google Cloud buildpacks for Node.js, Python, Go, Java, and the other supported runtimes execute the language's native dependency resolver during the build phase. For Node.js that is npm or yarn against the public registry, for Python it is pip against PyPI, for Java it is Maven Central. Each of these resolves the full transitive dependency closure described by your manifest, fetches the artifacts, and stages them into the image. The base image itself is pulled from gcr.io and adds the operating system layer, the runtime, and a set of system packages that come along for the ride.
The trust implication is that every build is a fresh resolution of your dependency graph against whatever the public registry currently serves, which means a typo-squat published yesterday or a maintainer takeover from last week can land in your image without anything in your source code changing. The image you deployed last month and the image you deploy today from the exact same source revision can be different in ways that matter, and unless your build pipeline produces an SBOM and you diff SBOMs across builds, you will not see it.
How does Cloud Build's default service account amplify the blast radius?
Cloud Build, when invoked by gcloud functions deploy or by Cloud Run source deploy, runs by default as the Cloud Build service account in the project, which has Project Editor permissions in many older projects and a more restricted but still broad role in newer ones. That service account can read source repositories, push images to Artifact Registry, and trigger deployments. A buildpack that runs a malicious postinstall script during dependency resolution is running inside that service account's blast radius.
The concrete attack we have seen modeled in research and in at least one published incident is: a malicious npm package executes a postinstall that uses the build environment's metadata server credentials to push a backdoored image to the project's Artifact Registry under the name of a different service, and then to trigger a Cloud Run deployment of that service. Because the service account has the permissions, the operation succeeds, and the malicious change propagates without ever touching a developer's machine or a code review. The blast radius is the union of everything Cloud Build can do, not just the build of the current function.
What does a hardened buildpack pipeline look like in 2026?
The first hardening step is to stop using the default Cloud Build service account. Create a per-service-or-team build service account with permissions scoped to the artifact registry path it writes to and the deployment surface it triggers, and configure gcloud and Cloud Build triggers to use it. That alone bounds the blast radius of a compromised build to the surface that build is supposed to touch.
The second hardening step is to break the implicit registry trust. Configure Artifact Registry remote repositories or a virtual repository that pulls from a curated set of upstream registries with a deny list of known-bad packages and a freshness floor that rejects too-new versions to reduce zero-day typosquat exposure. Tie the buildpack to the virtual repository through the environment configuration so that the public registry is never reached directly. The third hardening step is to require image attestations: configure Binary Authorization on Cloud Run and Cloud Functions 2nd gen to require an attestation produced by your hardened build pipeline, signed by a key that is not accessible from the build environment itself. An image without the attestation cannot be deployed.
How do you keep the buildpack and base image fleet current?
The base images that Google ships under gcr.io/buildpacks update on their own schedule, and a function or service that was built six months ago is running a base image that almost certainly has CVEs the latest base would not. Cloud Run supports a notion of automatic base image updates that rebuilds the image against the latest base on a schedule, and turning that on is a meaningful improvement; without it, every service drifts and the drift compounds across the fleet.
The harder problem is the application layer. A rebuild against the latest base image only refreshes the operating system and runtime layers; the dependencies that the buildpack resolved at the original build time are still pinned in package-lock.json or requirements.txt. Driving the rebuild cadence for the application layer requires a separate process that bumps dependencies on a schedule, runs the build against the bumped manifest, runs your tests, and deploys if green. Without that process, the buildpack convenience produces a fleet of services with stale dependency trees that nobody is rebuilding.
What runtime defenses help when prevention fails?
Cloud Run and Cloud Functions 2nd gen both support VPC egress controls, which is the highest-value runtime defense. Constraining the function or service to a VPC connector with egress rules that allowlist the destinations it legitimately reaches denies the most common malicious behavior, which is an outbound callback to an attacker-controlled host. The deny event is logged and becomes the signal that something has gone wrong inside the workload.
The complementary defense is per-revision service account scoping. Each Cloud Run revision and each Cloud Functions deployment can be configured to run as a service account whose role bindings are scoped to the resources the workload actually needs. The frequent failure mode is sharing a single service account across many revisions for convenience, which means a compromise of any of them has the union of permissions across all of them. Per-revision identity, combined with VPC egress allowlisting and Binary Authorization, is the runtime baseline that bounds the impact of a buildpack supply chain incident.
How Safeguard Helps
Safeguard treats every Cloud Run service and Cloud Functions 2nd gen function as a deployable with an SBOM, a provenance attestation, and a reachability profile tied to the buildpack-produced image. Griffin AI correlates the dependencies pulled in by your buildpack builds against TPRM supplier scores and recent compromise indicators, and surfaces the cases where a transitive dependency is the actual blast-radius driver behind a service's risk profile. Policy gates plug into Binary Authorization so that an image without a valid Safeguard attestation cannot be deployed, and our reachability engine isolates the CVEs that your buildpack-pulled dependency tree actually exercises at runtime so that triage focuses on the findings that matter. The combination gives platform teams the service-by-service and dependency-by-dependency visibility that the GCP console alone does not produce.