In April 2022, Google Cloud introduced Software Delivery Shield as a fully managed answer to a problem that had become impossible to ignore: the average enterprise pipeline pulls in code, containers, and dependencies from dozens of untrusted sources before anything reaches production. The 2020 SolarWinds compromise and the December 2021 Log4Shell vulnerability had already shown how a single tainted build step or unvetted open-source package can cascade into thousands of breached organizations. Software Delivery Shield stitches together Cloud Build, Artifact Registry, Artifact Analysis, Binary Authorization, and Cloud Deploy into one workflow that attests, scans, and gates software as it moves from commit to runtime. For teams building on Google Cloud, it's the closest thing to a default-secure software factory. This post breaks down what it actually does, where GCP SLSA compliance fits in, how Software Delivery Shield SBOM generation works, and where teams still need to fill gaps themselves.
What Is Software Delivery Shield?
Software Delivery Shield is Google Cloud's managed, end-to-end software supply chain security offering, built by wiring together five existing GCP services rather than shipping a brand-new product. Those five are Cloud Build for CI, Artifact Registry for storage, Artifact Analysis (the successor to On-Demand Scanning and Container Analysis) for vulnerability and metadata scanning, Binary Authorization for deploy-time policy enforcement, and Cloud Deploy for continuous delivery to GKE, Cloud Run, and Anthos. Google also folds in Assured Open Source Software (Assured OSS), a curated set of popular OSS packages that Google fuzzes, scans, and patches before mirroring them into a private, vetted registry. The pitch is straightforward: instead of bolting a scanner onto one stage of the pipeline, Software Delivery Shield instruments every stage — build, store, scan, deploy — so a vulnerability or a tampered artifact can be caught before it ever reaches a cluster. Google organizes the offering into three maturity tiers (basic security insights, deployment risk visibility, and full runtime protection), so teams can adopt incrementally rather than re-architecting their pipeline overnight.
How Does Software Delivery Shield Help With GCP SLSA Compliance?
Software Delivery Shield helps teams reach GCP SLSA compliance by generating verifiable build provenance automatically inside Cloud Build, without requiring engineers to hand-write attestation logic. SLSA (Supply-chain Levels for Software Artifacts) is the framework Google open-sourced in 2021 and later handed to the OpenSSF, defining escalating levels of build integrity — from SLSA Build Level 1, which just requires a documented build process, up through Level 3, which requires a hardened, tamper-resistant build platform that produces cryptographically signed provenance. When you build a container image through Cloud Build within Software Delivery Shield, it can automatically produce SLSA Build Level 3 provenance: a signed statement recording exactly which source commit, which builder, and which build steps produced that specific artifact. That provenance is stored alongside the image in Artifact Registry and can be checked at deploy time. This matters well beyond Google's own ecosystem — U.S. Executive Order 14028 (May 2021) and the resulting NIST Secure Software Development Framework both push federal vendors toward SLSA-style provenance, so GCP-native SLSA attestation has become a practical shortcut for vendors selling into regulated markets rather than a nice-to-have.
What Role Does Software Delivery Shield SBOM Generation Play?
Software Delivery Shield SBOM generation gives teams a machine-readable inventory of every package inside a container image, which is what makes rapid response to incidents like the March 2024 XZ Utils backdoor (CVE-2024-3094) actually feasible. When Artifact Analysis scans an image built or stored through Software Delivery Shield, it can emit a Software Bill of Materials in SPDX format, listing OS-level packages and language-level dependencies (Go modules, Python packages, Java JARs, Node packages) down to specific versions. That SBOM is attached to the image as metadata in Artifact Registry, so when a new CVE drops, a team can query across every deployed image for a single compromised package version instead of manually auditing each service. This is also increasingly a contractual requirement, not just a best practice: the same 2021 executive order that pushed SLSA adoption also directs federal agencies to require SBOMs from software vendors, and many enterprise procurement teams have copied that language into their own vendor security questionnaires. Generating the SBOM automatically at build time, rather than reconstructing it after the fact, is the difference between an answer in minutes and one in days.
How Does Binary Authorization Stop Unverified Artifacts From Deploying?
Binary Authorization stops unverified artifacts by refusing to let GKE, Cloud Run, or Anthos pull an image unless it carries specific cryptographic attestations that match a policy you define. In practice, a policy might require that every image deployed to a production cluster has (1) passed a vulnerability scan with no critical CVEs, (2) been built by the approved Cloud Build pipeline with valid SLSA provenance, and (3) been signed off by a QA or security gate. If any attestation is missing — say, someone tries to deploy an image built on a laptop rather than through CI — the admission controller blocks the deployment outright, and the attempt is logged. This closes the exact gap that let the SolarWinds attackers succeed: a build system producing artifacts that downstream systems trusted implicitly, with no cryptographic proof of how they were made. Binary Authorization can also be configured in "dry-run" mode first, so teams can see what would have been blocked before flipping enforcement on, which is the realistic on-ramp for any team with an existing pipeline full of legacy images that wouldn't pass a strict policy on day one.
Where Are the Gaps in Software Delivery Shield's Coverage?
The main gap is that Software Delivery Shield is scoped to Google Cloud's own pipeline components, so it has limited visibility into anything upstream or outside that boundary — a developer's laptop, a GitHub Actions runner, a third-party SaaS integration, or a vendor's build system. Its vulnerability scanning also focuses on known-CVE matching against packages and OS layers, which means it's strong at catching disclosed vulnerabilities but doesn't natively address supply chain security GCP teams increasingly worry about, like malicious package behavior, typosquatted dependencies, or compromised maintainer accounts that don't show up as a CVE at all. Assured OSS narrows this gap for the packages it covers, but it covers a curated subset of the open-source ecosystem, not everything a given codebase pulls in. Multi-cloud and hybrid organizations run into a second gap: Software Delivery Shield's provenance and attestation chain is strongest when the entire build-to-deploy path stays inside GCP, so teams that build on GitHub Actions and deploy across AWS, Azure, and GCP simultaneously end up needing a layer that can normalize attestations and policy enforcement across all three rather than relying on any single cloud's native tooling.
How Safeguard Helps
Safeguard is built to sit in exactly the gaps that a single-cloud offering like Software Delivery Shield can't close on its own. Where Software Delivery Shield's provenance and scanning stop at the edge of GCP's own services, Safeguard tracks build and deployment integrity across whatever mix of CI systems, clouds, and registries a team actually runs — GitHub Actions, GitLab CI, Jenkins, and cloud-native pipelines alike — so a SLSA attestation generated in one environment can be verified consistently alongside artifacts built somewhere else entirely. Safeguard also goes beyond CVE-matching: it evaluates dependency behavior and provenance signals to flag the kind of compromise that doesn't yet have a CVE assigned, which is exactly the pattern seen in incidents like the XZ Utils backdoor before it was publicly disclosed. For teams already invested in Software Delivery Shield, Safeguard consumes the SBOMs and provenance it generates and correlates them against runtime deployments, open vulnerability intelligence, and policy violations in one place, so security and platform teams get a single view of supply chain risk instead of stitching together dashboards from each cloud they operate in. The result is the same outcome Software Delivery Shield aims for — verified builds, complete SBOMs, and gated deployments — extended to cover the full, messy, multi-cloud reality most engineering organizations actually live in.