Securing Deployment Pipelines with Signed Evidence

Artifact Analysis (opens in a new tab) is the Google Cloud family of services that scans container images for vulnerabilities, stores security metadata, and feeds deployment decisions. Artifact Registry (opens in a new tab) provides built-in detection points where images are scanned on push and continuously monitored afterward. Together they connect detection in the registry to enforcement in the pipeline and visibility in operations.

1.1Automatic Scanning and Continuous Analysis in Artifact Registry

Automatic scanning in Artifact Registry scans a new image when the image is pushed to a Docker repository and then keeps findings current through continuous analysis. The on-push scan extracts operating system and language packages, identifies dependencies and licenses, checks for malicious packages from the OpenSSF Malicious Packages Repository, and produces a vulnerability result that collects all occurrences for that image. Malicious packages are reported as CRITICAL severity vulnerabilities, and automatic scans can also detect exposed secrets such as API keys and service account keys in public preview.

Automatic scanning is keyed to image digest, so an image is scanned only once and adding or changing tags never triggers a new scan. Continuous analysis ingests new vulnerability data multiple times each day and then updates existing occurrences, creates new occurrences, or deletes occurrences that are no longer valid. Findings stay updated only while the image has been pulled within the last 30 days; after 30 days without a pull the metadata becomes stale and is no longer updated, and after more than 90 days stale it becomes archived and can be evaluated only by API. Pulling a stale or archived image refreshes metadata within up to 24 hours, and scanning applies only to Linux-based images, prefers the Linux amd64 image in a manifest list, and does not support Windows Server containers.

1.2On-Demand Scanning for Early Build Gates

On-demand scanning is a manual scan started with the gcloud command-line interface (CLI) against a local image or a registry image without first pushing to Artifact Registry. Container scanning (opens in a new tab) in this mode gives a Cloud Build step control over timing, so the pipeline can build an image, scan it immediately, and block the upload or fail the build when findings exceed a severity threshold. Results are available for up to 48 hours after completion and are never updated afterward.

The two scanning types (opens in a new tab) differ in trigger, freshness, and pipeline role, so teams commonly combine them:

Because on-demand scanning is point-in-time and automatic scanning is continuous, on-demand scanning blocks risky images early in Cloud Build while automatic scanning catches newly disclosed vulnerabilities in images already stored in Artifact Registry.

1.3Metadata Storage and Deployment Policy Enforcement

Artifact Analysis metadata management stores structured metadata that describes what happened to an artifact across source, build, storage, deployment, and runtime environments. People or automated systems attach metadata such as passed integration tests or passed vulnerability scans, and Binary Authorization reads that metadata to allow or deny deployment. A Binary Authorization policy can require only compliant images from trusted registries, require signed attestations of compliance with a vulnerability scan policy, or use a vulnerability allowlist built from Artifact Analysis findings.

Artifact Analysis links metadata to images through notes and occurrences, where a note defines a type of metadata and an occurrence records an instance of that note on a specific image. The Artifact Analysis API supports gRPC and REST/JSON, client libraries, and authenticated OAuth2 access for creating custom notes and occurrences and for querying vulnerability occurrences. The Google Cloud console surfaces the same findings in Artifact Registry, and the gcloud CLI can list vulnerabilities and image metadata for automation and auditing.

1.4Centralized Visibility and Event-Driven Remediation

Centralized visibility aggregates Artifact Analysis findings so new scan completions and newly discovered vulnerabilities become actionable events. Security Command Center aggregates Artifact Registry scan findings across projects, shows container image vulnerabilities in running workloads alongside other risks, and supports export to BigQuery for long-term analysis. Cloud Deploy security insights expose SLSA level, vulnerabilities by severity with fixes and VEX status, Software Bill of Materials (SBOM) inventories generated for Cloud Build images pushed to Artifact Registry, and build details including logs, builder name, timestamp, and JSON build provenance.

When continuous analysis creates or updates an occurrence, that change signals downstream automation to rebuild the image, revoke an attestation, block promotion, or notify owners. Package scanning (opens in a new tab) covers Go, Java, Node.js, PHP, Python, Ruby, Rust, and .NET language packages plus many operating system families, but only publicly monitored packages are detected. To investigate an unfamiliar transitive dependency, trace the finding to its file path with this workflow:

1. Open vulnerabilities: In the Google Cloud console, open the vulnerability list for the artifact in Artifact Registry.
2. Open fix details: For the target vulnerability, click VIEW FIX to open the fix pane.
3. Show file location: Click SHOW MORE INFO and read the File location field for the path to the vulnerable package.

This flow connects detection to ownership because the scan identifies the vulnerable file, the SBOM and provenance identify how it entered the build, and Binary Authorization and Security Command Center determine whether the image can continue to run.

Software supply chain security (opens in a new tab) is the practice of proving where artifacts came from, how they were built, and whether they are safe to deploy. Supply-chain Levels for Software Artifacts (SLSA) measures the maturity of the build process, Artifact Analysis provides vulnerability truth, and Binary Authorization enforces admission based on signed evidence. Together they move trust from mutable tags to immutable digests with verifiable provenance.

2.1SLSA Framework and Secure Builds with Cloud Build

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 alongside vulnerability data, build provenance, and SBOM dependency lists.

A secure build platform is the foundation for a higher SLSA level because the platform that runs the build must resist tampering. Cloud Build 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 cannot leak into the next build. Cloud Build supports SLSA Level 3 builds for container images and can generate authenticated and non-falsifiable provenance that includes image digests, input source locations, toolchain, build steps, and duration.

2.2Vulnerability Scanning and Software Composition Analysis

Vulnerability scanning and software composition analysis (SCA) embed automated checks for known vulnerabilities and third-party components directly into the CI/CD pipeline. Artifact Analysis scans container images and language packages stored in Artifact Registry at push time and then continuously re-evaluates stored metadata as new vulnerability data arrives. SCA inventories direct and transitive dependencies, tracks SBOMs and Vulnerability Exploitability eXchange (VEX) statements, and uses lock files to determine exactly what a build depends on.

Artifact Registry remote repositories 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 scanning if scanning is enabled. Virtual repositories consolidate repositories of the same format behind a single endpoint and let teams control search order to prioritize private packages, which reduces dependency confusion attacks. On-Demand Scanning shifts detection left by finding operating system, Go, and Java issues in a local image before push, while automated scanning shifts protection right by keeping stored images under continuous evaluation after push.

2.3Binary Authorization Policy Enforcement at Deploy Time

Binary Authorization is the deploy-time control that admits only images whose attestations satisfy policy before they become running resources on Google Kubernetes Engine (GKE), Cloud Run, or App Engine. Deployment-time enforcement matters because a supply chain attack compromises source code, libraries, or base images before the pipeline runs, which is different from pipeline poisoning that compromises the pipeline itself. Because a managed resource can only be as secure as its pipeline, configuration, infrastructure, and inputs, a check at admission is needed even when builds and registries are secured.

The ordered gate workflow preserves the chain from evidence to admission:

1. Scan: Artifact Analysis scans the image in Artifact Registry and stores vulnerability occurrences for that digest.
2. Verify and sign: An authorized attester checks the scan result and any vulnerability allowlist, then creates a cryptographically signed attestation linked to the immutable SHA-256 digest.
3. Enforce: The GKE or Cloud Run admission controller sends the deploy request to Binary Authorization, which verifies required signatures before the Pod is created and denies images without them.
4. Monitor: Binary Authorization Continuous Validation continues to watch active Pods and generates alerts in Logging if running containers become non-compliant.

Enforcing by digest rather than mutable tag prevents tag-mutation bypass, and policies apply at cluster level so development, staging, and production can require different attesters. A policy can require proof of an approved builder such as Cloud Build, compliance with a vulnerability threshold with an allowlist for non-applicable findings, or promotion criteria for the next environment.

2.4Promotion Gates, Continuous Validation, and Visibility

Promotion gates add human and process control on top of attestation checks as artifacts move toward production. Cloud Deploy enforces gated promotion with required approvals between target environments in a defined sequence to GKE, GKE Enterprise, and Cloud Run. Progressive attestation hardens the path by collecting build and scan attestations first, then QA or security-review attestations, with the production cluster requiring the full set while earlier clusters require fewer.

Continuous Validation extends the gate past admission by watching already-running Pods when new vulnerabilities are disclosed or policy changes. If a new CRITICAL finding maps to a running image, the control plane flags the workload in Logging even though admission previously succeeded. For emergencies, breakglass deployment bypasses admission, but alerting on breakglass audit events notifies security operations so every bypass is tracked. Security insights (opens in a new tab) in Cloud Build, Cloud Deploy, and Cloud Run, the safeguard builds (opens in a new tab) controls, the GKE security posture dashboard, and Web Security Scanner together show SLSA status, provenance, SBOMs, and runtime risks so teams can trace an artifact from source commit through builder and digest to deployment target.

Identity and Access Management (IAM) (opens in a new tab) based on environment controls who can act on development, testing, and production by combining resource hierarchy, role choice, and runtime conditions. IAM allow policies set high in the hierarchy flow downward to every child, while environment folders add only the narrow bindings each tier needs. Production therefore stays strict with approved identities and secure contexts, while development and staging stay flexible without risking production.

3.1Isolate Environments with Folders and Separate Organizations

Environment isolation in Google Cloud uses folders inside one organization to host development, testing, and production workloads for the same application. IAM allow policies set at the organization or a common parent folder inherit to every child project and resource, so shared viewer, logging, or security policies stay consistent without repetition. Policies set on an environment folder apply only to projects under that folder, which lets production stay strict while development and testing keep enough parity that a release validated in test behaves the same in production.

A separate staging organization tests organization-wide change, not daily development work. The staging organization mirrors the production folder structure with only a small number of projects and carries either the current production IAM and organization policies or the next version intended for production. Dedicated test users and groups mirror production groups, so hierarchy and policy changes can be validated without impacting existing users. A separate experiment organization provides an unencumbered sandbox with automation to delete resources after a set lifetime.

3.2Scale Privilege to Environment Risk

Least privilege scales with environment risk by changing role breadth, scope, and trust boundaries. In production, basic roles such as Owner (roles/owner) are avoided because they include thousands of permissions across services and allow almost all resource and allow-policy changes. In test or development projects, basic roles may be acceptable when broader flexibility helps velocity, but production uses the most limited predefined roles or custom roles that meet the task.

Each application component forms its own trust boundary with its own service account granted only the permissions that component needs. Roles are granted at the smallest scope possible, for example Publisher on a single Pub/Sub topic rather than on the whole project, and a role needed across many projects is granted once on their shared folder rather than repeated per project. Control over impersonation is equally scoped, because users with the Service Account User role on a service account can access everything that service account can access. Administrative power is split so Project IAM Admin and Folder IAM Admin can modify allow policies without granting direct data access, while Owner is reserved for near-universal access and at least two principals retain Owner on every project.

3.3Control Delivery Pipelines with Resource-Level Bindings and Conditions

Cloud Deploy delivery controls restrict pipeline actions by resource, action type, and runtime context rather than by project-wide grants. An IAM policy binds a role such as roles/clouddeploy.developer or roles/clouddeploy.operator, or specific clouddeploy.deliveryPipelines.* permissions, to users, groups, or service accounts, and the binding is applied with setIamPolicy to a single delivery pipeline or target. Project-level grants affect all pipelines or targets in that project, so environment separation depends on applying narrow bindings at the pipeline or target resource inside the correct environment folder.

Fine-grained Cloud Deploy access separates who can build, release, promote, and approve across environments:

• Grant access to create, modify, and delete a specific delivery pipeline
• Grant access to configure a specific target, such as development versus production clusters
• Grant permission to promote a release to a specific target
• Grant permission to approve rollouts to a specific target
• Grant permission to promote a release only during a specific time window
• Grant permission to approve rollouts only during a specific time window

IAM Conditions enforce the secure context by evaluating request attributes at runtime, such as resource name or time of day, before a binding takes effect. Resource Manager tags extend the same idea by conditionally allowing IAM based on whether a resource carries a tag such as env=prod. Separation of duties is preserved by granting promote rights and approve rights to different principals on the production target, so no single identity can both ship and self-approve a production rollout.

3.4Enforce Network Context and Harden Pipeline Identity

Default IAM decisions do not consider geolocation, source IP address, or origin Google Cloud project, so a stolen token is usable from anywhere. VPC Service Controls adds the missing network boundary by placing projects inside a perimeter that denies access to restricted services from traffic originating outside it. An ingress rule creates a narrow exception that allows only the pipeline's expected path back into the perimeter for only the services it needs.

The correct ingress design depends on where the deployment pipeline runs:

A deployment pipeline acts through its service account regardless of which developer authored the change, which creates a confused deputy risk. Each pipeline must therefore use a dedicated service account whose email includes the pipeline name or ID with access only to resources that pipeline needs. Pipeline identities must avoid roles that include any *.setIamPolicy permission and avoid basic roles Editor and Owner, and must use Workload Identity Federation with short-lived OpenID Connect tokens instead of long-lived keys when running in GitHub Actions or GitLab. Preventive organization policy constraints including Domain restricted sharing (iam.allowedPolicyMemberDomains) limit members to approved domains and block creation of service account keys.

3.5Audit and Right-Size Access with Policy Intelligence

Auditing and right-sizing access is the controlled lifecycle that moves a permission change from proposal through impact analysis to deployment and audit. Cloud Audit Logs record every setIamPolicy() call, so creation or modification of any environment binding can be traced to caller, time, and resource. Viewing inherited policy requires resourcemanager.organizations.getIamPolicy, resourcemanager.folders.getIamPolicy, or resourcemanager.projects.getIamPolicy on the parent, which reinforces that folder and organization grants must be reviewed as part of any environment audit.

Policy Intelligence (opens in a new tab) tools predict whether a least-privilege change is safe before it reaches production:

Core lifecycle controls include defining minimum permissions per task, granting roles to administrator groups rather than individuals, requiring multi-factor authentication, using conditional and temporary elevated access that expires automatically, and automating enforcement with Deployment Manager or Terraform so environment IAM is validated before deployment and reapplied consistently.

Key Facts

• Artifact Analysis scans once per image digest on push to Artifact Registry, so tag changes never trigger a new scan, while continuous analysis updates findings multiple times daily only while the image was pulled within 30 days.
• Scan metadata becomes stale after 30 days without a pull and archived after more than 90 days stale, with refresh within 24 hours after a new pull, while on-demand scan results are point-in-time for 48 hours.
• Binary Authorization enforces deployment by verifying required cryptographically signed attestations for the exact image digest before Pod creation, not by evaluating CVE severity at admission.
• Cloud Build supports SLSA Level 3 builds and generates authenticated, non-falsifiable provenance that links image digests to source, toolchain, and build steps.
• Environment isolation uses folders for development, testing, and production inside one organization with inherited IAM policies, while VPC Service Controls enforces network context that IAM ignores by default and Cloud Audit Logs records all setIamPolicy calls.