Container security is not solved by scanning an image once, and it is not solved by blocking unsigned images without knowing what the signature means. Google Cloud separates two important supply-chain functions. Artifact Analysis records and produces metadata about software artifacts, including vulnerability information and trusted metadata used by authorization workflows. Binary Authorization evaluates deployment policy and can prevent a container image from being deployed when the required conditions are not met.

For the Professional Cloud Security Engineer, the useful mental model is evidence plus enforcement. Artifact Analysis helps produce or store evidence about an image. Binary Authorization turns selected evidence into a deployment decision for supported platforms such as GKE and Cloud Run.

Start with immutable image identity

Container tags are convenient labels, but they can be changed to point to different image content. Security decisions therefore need the image digest, which identifies the exact artifact bytes. An approval for one digest should not silently authorize a different build merely because both were tagged production.

This is a broader software-supply-chain principle. The object that passed build, test, vulnerability, and review gates should be the same object that reaches production. If a pipeline rebuilds between stages or resolves a mutable tag at deploy time, the evidence chain can break even though every individual tool reports success.

Store artifacts in controlled registries, use digest references for high-assurance promotion, and make provenance and attestation processes operate on the immutable identifier.

Artifact Analysis provides vulnerability and metadata services

Artifact Analysis can scan supported container images and packages for known vulnerabilities and maintain metadata as vulnerabilities are discovered or updated. That matters because an image that was considered clean on build day can become risky later when a new CVE is published.

Artifact Analysis also stores notes and occurrences used by Binary Authorization attestation workflows. A note represents trusted metadata such as an attestor’s authority, while an occurrence records metadata associated with a particular artifact. Binary Authorization can query that metadata when evaluating whether an image has the required attestation.

Scanning and attestation should remain conceptually separate. A vulnerability scan answers what known security findings exist. An attestation says a defined process or authority approved this exact image. One can inform the other, but they are not interchangeable.

Binary Authorization converts policy into a deployment gate

Binary Authorization evaluates a policy when an image is deployed to a supported container platform. The policy can allow trusted images and require evidence such as attestations before deployment. If the image does not satisfy the rule, the deployment is blocked and the enforcement event is recorded.

This is valuable because it moves supply-chain policy out of individual CI scripts and into the deployment path. A compromised or bypassed build pipeline cannot simply skip its own final security check if the production platform independently enforces that only authorized artifacts may run.

Supported environments include Google Kubernetes Engine, Cloud Run, Google Distributed Cloud, and Cloud Service Mesh scenarios. The exact policy capabilities depend on the platform, so architects should validate the enforcement point instead of assuming every container runtime behaves identically.

Attestations should represent real independent controls

An attestation is a signed statement tied to an image digest. It can represent a successful build from an approved builder, completion of integration testing, a security review, a vulnerability policy check, or another required stage. Binary Authorization uses an attestor’s trusted public key to verify that the expected signer produced the statement.

The signature is only as meaningful as the process behind it. If the same highly privileged CI identity can build arbitrary code, bypass tests, and generate every required attestation, the policy may create the appearance of separation without actually constraining an attacker.

Use separate identities, projects, keys, or administrative responsibilities where the risk justifies it. Production policy should trust a limited set of attestors whose signing authority is protected independently from application developer permissions.

Vulnerability scanning becomes stronger when promotion policy uses it

Teams often enable vulnerability scanning but leave the result as a dashboard that nobody owns. A stronger design defines what severity, exploitability, fix availability, or exception criteria block promotion. That rule can be implemented in CI, an attestation service, Binary Authorization continuous validation where appropriate, or a combination of controls.

Binary Authorization continuous validation includes checks that can use Artifact Analysis vulnerability data to identify running images that no longer meet configured vulnerability criteria. Because continuous validation is a monitoring control rather than a magic rollback mechanism, teams still need an incident process for deciding whether to patch, redeploy, isolate, or accept the finding.

A real-world software-supply-chain incident such as the XZ Utils backdoor illustrates why build provenance and dependency trust matter alongside CVE severity. A secure pipeline needs evidence about where software came from, not only a vulnerability score.

Kubernetes admission is one layer in a larger workload-security model

On GKE, Binary Authorization controls whether an image may be admitted under policy, but it does not replace Kubernetes authorization, pod security controls, workload identity, network policy, runtime detection, or secrets management. An approved image can still be deployed with dangerous privileges if the rest of the cluster policy allows it.

Likewise, blocking an unapproved image does not prove that an approved image is safe. The organization must define what its approvals mean and continue to monitor runtime behavior after deployment. Readers who are new to the platform should understand the normal Kubernetes workload lifecycle before treating admission control as the whole security architecture.

Supply-chain security protects the path into production. Runtime security protects what the workload does after it arrives. Mature environments make both controls visible to the same incident and governance processes.

Software bills of materials can strengthen that shared view by listing packages and dependencies associated with a released artifact. They help responders answer whether a newly disclosed library exists in deployed images and which versions are affected. An SBOM is still evidence, not enforcement: it must be connected to vulnerability analysis, ownership, and a patch or exception workflow before it changes production risk.

Break-glass access must be exceptional and observable

Production systems occasionally need an emergency deployment before the normal evidence chain is complete. Binary Authorization supports break-glass patterns on supported platforms so teams can recover service, but the exception should be highly visible and followed by review.

Do not make break glass the normal path for teams frustrated by policy. Every override should identify who used it, which image was deployed, why the normal attestation failed, how long the exception may remain, and what follow-up action restores compliance.

Test the emergency path before an outage. A control that can technically be bypassed only by a person who is unavailable during an incident can turn a security feature into a reliability failure. Conversely, an override that every developer can use without alerting is not meaningful enforcement.

Promotion pipelines should create an evidence chain

A robust flow might build an image in Cloud Build, store it in Artifact Registry, scan it with Artifact Analysis, run tests, produce provenance, create one or more attestations, promote the exact digest, and let Binary Authorization enforce the production deployment policy. Each stage should write evidence that can be tied back to the same artifact.

Do not rebuild from source separately for staging and production if the security requirement is to promote a tested artifact. Rebuilding can produce different dependencies or compiler output and breaks the simple statement that “the image in production is the image that passed staging.”

Policy should also distinguish trusted sources. Third-party images may need a different validation path from first-party builds. Base images should be pinned and refreshed deliberately. An SBOM can improve investigation, but it does not replace provenance or runtime inventory.

Artifact promotion should preserve separation between build and deploy authority. A production cluster or Cloud Run service should not need permission to rebuild software, and a build project should not automatically have permission to change production admission policy. Keeping registry write, attestation signing, policy administration, and workload deployment as separate capabilities reduces the chance that one compromised credential can create an image, approve it, weaken the policy, and deploy it without an independent control noticing.

Use enforcement to make secure delivery the easy path

Binary Authorization is most effective when developers do not have to become experts in attestation internals to release a normal build. CI should automatically generate the evidence that policy expects, show clear reasons when a deployment is rejected, and provide a documented process for legitimate exceptions.

Artifact Analysis should feed actionable decisions rather than simply increasing finding counts. Define who owns vulnerability exceptions, how long they last, what constitutes a blocking issue, and how newly discovered vulnerabilities in running workloads are escalated.

The objective is a supply chain in which trusted builds move quickly because evidence is produced automatically, while untrusted or unexplained artifacts stop before production. Security comes from preserving the identity and evidence of the artifact all the way from build to runtime—not from adding one more scanning dashboard at the end.