SLSA Provenance and Binary Authorization Enforcement

Supply-chain Levels for Software Artifacts (SLSA) (opens in a new tab) is a security framework that improves the integrity of software artifacts and prevents tampering across the software delivery pipeline. SLSA describes supply chain threats with matching mitigations and groups requirements into levels so teams can prioritize and strengthen protection step by step. SLSA focuses mainly on the build and delivery pipeline, so it is used together with broader frameworks such as the NIST Secure Software Development Framework (SSDF) and Cybersecurity Assessment Framework (CAF).

1.1SLSA Framework and Build Integrity

The SLSA framework defines increasing levels of protection where higher levels give stronger integrity guarantees for built artifacts. SLSA was inspired by Google's internal Binary Authorization for Borg, which is a mandatory enforcement check for production workloads. Google Cloud builds SLSA best practices into its build and deploy services and shows the SLSA build level for each build in console dashboards. The SLSA build level identifies the maturity of the software build process under the SLSA specification and sits alongside vulnerability data, build provenance, and Software Bill of Materials (SBOM) dependency lists.

1.2Securing the Build Platform with Cloud Build

A secure build platform is the foundation for a higher SLSA level because the platform that runs the build must resist tampering and unauthorized access. Cloud Build (opens in a new tab) runs builds on Google Cloud infrastructure with granular Identity and Access Management (IAM) permissions, VPC Service Controls perimeters, and isolated and ephemeral build environments. Each build environment is provisioned for one build and then discarded, so leftover state from one build cannot leak into the next build. Cloud Build supports SLSA Level 3 builds for container images, which means container image builds can inherit hardened platform guarantees without the team operating its own builders.

1.3Generating Verifiable Build Provenance

Build provenance is a collection of verifiable metadata about how an artifact was produced, and it is the main evidence that links an artifact back to its trusted source and build. Cloud Build can generate authenticated and non-falsifiable provenance for containerized applications, so consumers can verify that the artifact was built by the expected builder from the expected inputs. Provenance includes the digests of the built images, the input source locations, the build toolchain, the build steps, and the build duration. Because provenance flows from the builder to artifact storage and then to deployment policy checks, any substitution of source, toolchain, or output breaks the chain of trust that downstream verification depends on.

1.4Viewing Security Insights for Builds and Deployments

Security insights make SLSA status actionable by showing build level, provenance, and vulnerabilities in the same view as the artifact. Cloud Deploy (opens in a new tab) displays security insights as applications move through a defined sequence of target environments to Google Kubernetes Engine, GKE Enterprise, and Cloud Run, while Cloud Build provides security insights for built applications. Console dashboards provide details across sources, builds, artifacts, deployments, and runtimes, including vulnerabilities in build artifacts detected by Artifact Analysis and SBOM dependency lists. This flow lets a team trace an artifact from its source commit through its builder and image digest to its deployment target before approving promotion.

1.5Implementing SLSA Controls to Reach a Target Level

Reaching a target SLSA level requires assessing the current build pipeline against SLSA requirements and then closing gaps in source, build, provenance, and deployment controls. Implementation follows an ordered progression where each stage depends on the previous decision:

1. Understand SLSA levels: Learn the requirements for each level, where higher levels provide greater artifact integrity.
2. Assess current level: Evaluate current source, build, and deployment practices against the SLSA framework to find gaps.
3. Set target level: Choose a target based on risk tolerance, security requirements, and criticality of the system.
4. Implement required controls: Apply the source, build, provenance, signing, scanning, and deployment controls for the target level.
5. Continuously improve: Monitor for new threats and vulnerabilities and raise the level over time.

The controls applied at the implement stage span the full path from code to runtime:

• Source control: Track code and configuration changes in a version control system such as Git to preserve history and review.
• Build process: Run scripted or automated builds on a secured builder such as Cloud Build with least-privilege service accounts and isolated execution.
• Provenance generation: Emit provenance metadata that captures the build process, source code, and dependencies for later verification.
• Artifact signing: Sign artifacts produced by approved build processes to verify authenticity and integrity at deployment time.
• Vulnerability management: Scan artifacts and dependencies regularly with Artifact Analysis and maintain approved library versions in Artifact Registry.
• Deployment security: Enforce deployment practices so only verified artifacts reach production, including Binary Authorization policies that allow deployment only when required attestations and security checks pass.

Integrate Vulnerability Scanning and Software Composition Analysis means embedding automated checks for known vulnerabilities and third-party components directly into the CI/CD pipeline. Artifact Analysis (opens in a new tab) scans container images and language packages stored in Artifact Registry (opens in a new tab), while software composition analysis (SCA) tracks dependencies, software bills of materials (SBOMs), and exploitability to decide whether an artifact is safe to promote. Binary Authorization and Cloud Deploy then enforce those decisions as policy gates so only verified artifacts reach development, test, or production environments.

2.1Automated Image Scanning in Artifact Registry

Artifact Analysis is the automated scanning service for container images pushed to Artifact Registry. When a new image is uploaded, Artifact Analysis extracts information about system packages in the container and creates initial vulnerability findings from current vulnerability sources. This scan happens at push time, so every artifact entering the registry gets a consistent baseline without a manual step. Enable automated scanning on the registry or repository to make this check a mandatory part of the build-to-store flow from Cloud Build to Artifact Registry.

Scanning coverage extends beyond base operating system packages when scanning is configured. Artifact Analysis supports integrated automated and on-demand scanning for base container images and language packages in containers, plus SBOM generation and Vulnerability Exploitability eXchange (VEX) statements for images in Artifact Registry. Remote repositories in Artifact Registry cache artifacts from preset external sources such as Docker Hub, Maven Central, Python Package Index (PyPI), Debian, or CentOS as well as user-defined sources, and cached artifacts include vulnerability scanning if scanning is enabled. Virtual repositories consolidate repositories of the same format behind a single endpoint and let teams control search order across upstream repositories to prioritize private packages, which reduces dependency confusion attacks.

The two scanning modes cover different points in the artifact lifecycle:

On-Demand Scanning shifts detection left by finding OS, Go, and Java issues before the image is stored in Artifact Registry. Automated scanning shifts protection right by keeping stored images under continuous evaluation after they are pushed.

2.2Continuous Monitoring and Finding Lifecycle

Continuous monitoring means a clean scan at push time does not stay clean forever. After the initial scan, Artifact Analysis continuously monitors the metadata of scanned images in Artifact Registry for new vulnerabilities, for up to 30 days after the image is pushed. When Artifact Analysis receives new and updated vulnerability information from vulnerability sources, data flows from the sources to the stored image metadata.

That update follows an ordered lifecycle:

1. Update metadata: Artifact Analysis refreshes the metadata of scanned images to keep findings current.
2. Create occurrences: Artifact Analysis creates new vulnerability occurrences for new notes that now apply.
3. Delete stale occurrences: Artifact Analysis deletes vulnerability occurrences that are no longer valid.

Because findings change over time, deployment policy must evaluate current occurrences at deploy time and runtime dashboards must surface new critical risks, not just the original build-time result.

2.3Software Composition Analysis for Dependencies

Software Composition Analysis is the practice of inventorying direct and transitive dependencies to identify known vulnerabilities, risky licenses, and unused components. Vulnerability scanning tools consume lock files to determine exactly what artifacts a build depends on and notify teams when new vulnerabilities surface, sometimes with suggested upgrade paths. Open Source Insights (opens in a new tab) provides dependency graphs, known vulnerabilities, and license data, also available as a BigQuery public dataset for analysis, while Scorecards identifies risky supply-chain practices in GitHub projects and Allstar continuously monitors repositories for policy adherence.

Dependency hygiene in the pipeline also means removing what is not needed. Each dependency adds code outside direct control, so linting and testing stages should audit requirements files to determine whether dependencies are actually imported. Language tools such as the Maven Dependency Plugin help analyze Java dependencies, and Artifact Registry remote and virtual repositories help ensure builds resolve to trusted, cached copies instead of mutable public tags or version ranges that enable dependency confusion or non-reproducible builds.

2.4Policy Gates That Block Risky Artifacts

Binary Authorization is the deploy-time policy engine that enforces a chain of trust for Google Kubernetes Engine (GKE) and Cloud Run. Binary Authorization collects attestations, which are configurable signatures or digital documents certifying that a required process completed for a container image. At deployment time, policy flows from Binary Authorization to the admission control of GKE or Cloud Run, and only images whose attestations satisfy the policy are admitted.

A Binary Authorization policy can require different proofs for different environments:

• Verify that a specific build system or CI pipeline, such as Cloud Build, created the container image.
• Validate that the image is compliant with a vulnerability signing policy that blocks severity above a threshold, with an allowlist for specific vulnerabilities that do not apply.
• Verify that the image passes promotion criteria for the next environment, such as from development to QA.

Cloud Deploy adds human and process gating on top of attestation checks by supporting gated promotion with required approvals between target environments in a defined sequence. Together, Cloud Build generates provenance and security insights, Artifact Analysis generates vulnerability verdicts, Binary Authorization enforces attestation policy, and Cloud Deploy enforces promotion order and approvals.

2.5Analyzing Results Across Build, Deploy, and Runtime

Security insights follow the artifact from build through production so critical risks can be triaged in context. Cloud Build surfaces SLSA build level, vulnerabilities in build artifacts, and build provenance including image digests, source locations, toolchain, build steps, and duration. Cloud Deploy displays security insights for deployed applications, and runtime views show whether a running workload is now vulnerable even if it passed at build time.

The GKE security posture dashboard checks each deployed workload against best practices such as Pod Security Standards, rates severity, and returns actionable recommendations with an auditable trail in Cloud Logging. Cloud Run provides a security panel with SLSA compliance, build provenance, and vulnerabilities found in running services. Web Security Scanner, part of Security Command Center, complements image scanning by crawling App Engine, Compute Engine, and GKE web applications to exercise inputs and detect cross-site scripting, code injection, mixed content, and outdated or insecure libraries without excessive false positives.

Binary Authorization (opens in a new tab) is the deployment-time control that validates artifact provenance and integrity before an artifact is allowed to become a running resource. Artifacts flow from source code and container images into a deployment pipeline, and the pipeline turns them into resources such as applications on Google Kubernetes Engine (GKE), Cloud Run, or App Engine. Binary Authorization sits at the deploy step and enforces an organizational policy that only admits images that pass required security checks.

3.1Why Deployment-Time Enforcement Matters

Deployment-time enforcement addresses supply chain attacks that target pipeline inputs rather than the pipeline itself. In a supply chain attack, a bad actor compromises or replaces source code, libraries, base images, or container images before the pipeline runs, so the pipeline faithfully deploys malicious content. This is different from pipeline poisoning, where a bad actor compromises the pipeline, its configuration, or its underlying infrastructure and uses the pipeline's access to perform malicious actions on Google Cloud resources. Because a managed resource can only be as secure as its pipeline, configuration, infrastructure, and inputs, a check at deployment time is needed even when builds and registries are secured.

3.2How Binary Authorization Validates Provenance and Integrity

Binary Authorization validates provenance and integrity by allowing deployment only if the container image passes the security checks defined in policy. The policy applies to images built by the organization's approved processes, and the pipeline depends on signed evidence that the image came from those processes. To create that evidence, teams create a digital signature for packages and containers produced during approved builds, store vetted dependencies and custom packages in a private Artifact Registry (opens in a new tab) repository, and use Artifact Analysis with Artifact Registry to detect known vulnerabilities in open-source libraries. When the deployment request reaches the target environment, Binary Authorization checks the image against policy and blocks images that lack valid provenance or fail integrity checks.

3.3Integrating Binary Authorization with Pipelines and Registries

Integration with pipelines and registries connects Cloud Build, Artifact Registry, Artifact Analysis, and Binary Authorization into one enforced path from source to runtime. The end-to-end flow moves in order:

1. Build: Cloud Build builds container images from source in the CI/CD pipeline.
2. Store: The pipeline uploads the images to Artifact Registry, including a private repository for approved and vetted dependencies.
3. Scan: Artifact Analysis scans the stored images and libraries for known vulnerabilities.
4. Enforce: Binary Authorization evaluates the image against deployment policy before release.
5. Deploy: Only images that pass policy are deployed as new versions to GKE, Cloud Run, or App Engine.

This sequence makes the registry the single source of deployable artifacts and makes the deployment target depend on the policy decision. Google's internal Binary Authorization for Borg (BAB) follows the same principle at larger scale, starting at code review, creating an audit trail of code and configuration deployed to production, and admitting only changes that meet integrity criteria.

3.4Using Supply Chain Visibility and SLSA to Strengthen Policy

Supply chain visibility gives teams the provenance and vulnerability data that deployment policies depend on. Google Cloud console dashboards provide security information about sources, builds, artifacts, deployments, and runtimes:

• sources that produced the code and dependencies
• builds that transformed source into artifacts
• artifacts stored in registries, including vulnerability findings
• deployments that promoted artifacts to environments
• runtimes where artifacts are running, with build provenance and Software Bill of Materials (SBOM) dependency lists

The Supply-chain Levels for Software Artifacts (SLSA) framework uses that provenance to assess the maturity of software supply chain security. Stronger SLSA maturity means stronger guarantees about where an artifact came from and how it was built, which lets organizations write stricter Binary Authorization policies with confidence.

Key Facts

• Cloud Build supports SLSA Level 3 builds for container images and can generate authenticated, non-falsifiable provenance that includes image digests, source locations, toolchain, build steps, and duration.
• Artifact Analysis scans images pushed to Artifact Registry at push time and continuously monitors stored image metadata for new vulnerabilities for up to 30 days after push.
• On-Demand Scanning finds OS, Go, and Java vulnerabilities in a local image before push, while automated scanning evaluates OS and configured language packages in stored images.
• Binary Authorization enforces deploy-time policy for Google Kubernetes Engine and Cloud Run by admitting only images whose attestations satisfy the policy, such as proof of approved builder, vulnerability threshold compliance, or promotion criteria.
• Cloud Deploy enforces gated promotion with required approvals between target environments in a defined sequence to Google Kubernetes Engine, GKE Enterprise, and Cloud Run.