Software-supply-chain security becomes operational when a deployment can answer three questions with evidence: what artifact is this, what happened to it, and why is this exact digest permitted to run here?
The release decision
Move from finding vulnerabilities to governing deployable artifacts
Google Cloud Artifact Analysis and Binary Authorization address different parts of the same decision. Artifact Analysis supplies vulnerability and other structured metadata. Binary Authorization evaluates policy and can block a container image that does not satisfy the required conditions.
The products do not decide an organization’s risk tolerance. Teams must still define trusted build paths, required evidence, vulnerability criteria, signer authority, exception handling, and the environments where a policy applies. Without those decisions, scanning can produce information without changing what reaches production.
A scan result is evidence about an artifact. An admission policy determines whether that evidence is sufficient to deploy it.TDG perspective
Product surface
Six capabilities form the practical control chain
Google documents a modular set of services. Agencies can adopt them incrementally, but the evidence must remain connected to an immutable artifact identity.
Artifact Registry
Centralizes supported build artifacts and dependencies so teams can apply access, repository, and retention controls around a known source.
Artifact Analysis
Provides software-composition analysis and structured metadata, including vulnerability information associated with stored artifacts.
Build provenance
Cloud Build can produce verifiable metadata describing the source, build process, toolchain, steps, and resulting image digests.
Attestations
A signer can affirm that a required activity; such as a build, test, or scan decision; was completed for a specific image digest.
Admission policy
Binary Authorization can require trusted attestations or other policy conditions before an image is admitted to a supported runtime.
Runtime validation
Enforcement records policy decisions at deployment; continuous validation can monitor running images for continuing conformance where the feature is supported.
Service availability, platform support, feature stage, scanning coverage, and pricing change over time. Validate the current Google Cloud documentation against the target architecture.
Evidence chain
Bind every decision to the same image digest
Tags are convenient labels and can change. A governed release path uses the immutable digest to connect source, build, analysis, approval, deployment, and runtime evidence.
| Control point | Decision | Evidence bound to the artifact |
|---|---|---|
| Source | Did the change originate from an approved repository, branch, reviewer, and dependency path? | Commit identity, review record, dependency lock or manifest |
| Build | Was the artifact produced by the approved builder with the expected source and configuration? | Provenance, builder identity, inputs, steps, output digest |
| Analyze | What packages, vulnerabilities, secrets, and other material conditions are known? | Artifact Analysis occurrences, SBOM, VEX or remediation context |
| Attest | Which trusted authority determined that the required activity or release condition was satisfied? | Signed attestation, attestor, key identity, policy version, timestamp |
| Admit | Does the exact digest satisfy the policy for this cluster, service, project, or stage? | Binary Authorization evaluation and Cloud Audit Logs event |
| Operate | Does the running artifact remain conformant as policy and vulnerability knowledge change? | Runtime inventory, validation result, new finding, owner response |
Policy design
Translate security intent into explicit release conditions
A useful policy states what must be true, who may assert it, where it applies, and what happens when the normal path cannot be followed.
| Policy question | Weak implementation | Governed implementation |
|---|---|---|
| Trusted build | Permit any image from an internal registry. | Require verifiable provenance from an approved build identity and deploy by digest. |
| Vulnerability decision | Block on severity alone or allow every finding through. | Combine severity with exploitability, reachability, fix availability, workload exposure, mission consequence, and documented exceptions. |
| Attestation authority | Allow the delivery pipeline to sign its own success with broad standing credentials. | Separate build, analysis, approval, and policy-administration duties; protect keys and use narrowly scoped service identities. |
| Environment scope | Apply one rule to development, test, and production without context. | Define stage-specific policies and progressively stronger evidence requirements toward production. |
| Breakglass | Use an undocumented bypass when delivery is urgent. | Require named authority, reason, scope, expiration, audit evidence, compensating controls, and retrospective review. |
| Existing runtime | Assume an admitted image remains acceptable indefinitely. | Monitor running digests, reassess when vulnerability or policy state changes, and connect new risk to an owner and response clock. |
Operating model
Make the secure path easier than the bypass
The platform team should package the evidence chain as a paved path while preserving clear responsibility for product risk and release decisions.
01
Inventory the release paths
Identify repositories, builders, registries, projects, clusters, Cloud Run services, external pipelines, and paths that bypass the standard workflow.
02
Choose representative services
Pilot with workloads that expose different languages, dependencies, risk levels, and deployment targets.
03
Protect the trust roots
Separate attestor and policy administration, constrain service accounts, rotate keys, and monitor changes to the authorization system itself.
04
Stage enforcement
Observe and measure first, resolve missing evidence, then move selected policies from monitoring to blocking with defined support.
05
Connect exceptions
Route failed admission and breakglass events into an owned workflow with disposition authority, deadlines, and reassessment.
06
Measure the outcome
Track trusted-build coverage, digest-based deployment, policy failures, exception age, recurrence, time to evidence, and unauthorized release attempts.
Practical boundaries
Keep product facts separate from implementation judgment
The services provide capabilities and evidence. The operating organization determines what those facts mean for its systems and mission.
| Documented product fact | Implementation judgment |
|---|---|
| Artifact Analysis can scan artifacts, continually update vulnerability information for supported automatic scans, and store structured metadata. | Which artifact formats and repositories are in scope, how scan gaps are handled, and which findings materially affect release. |
| Binary Authorization can monitor or enforce policy for supported container-based platforms and records enforcement outcomes. | Where to begin in monitor mode, which environments require blocking, and who owns failed deployment decisions. |
| Attestations certify that a required activity was performed for a specific image digest. | Which activities deserve an attestation, which identities may sign, how keys are protected, and when evidence expires. |
| Continuous validation can periodically assess running images against policy where the documented feature is available. | How nonconformance becomes operational work, how quickly teams respond, and when a workload must be isolated or replaced. |
Leadership questions
Questions to answer before turning on enforcement
The answers determine whether Binary Authorization becomes a reliable release control or a brittle gate that teams learn to bypass.
- Question 01Which artifacts, registries, build systems, deployment targets, and external release paths are inside the control boundary?
- Question 02What evidence is required for each environment, and is every item bound to the exact artifact digest?
- Question 03Who may create attestations, administer policy, approve exceptions, and use breakglass; and how are those duties separated?
- Question 04How will vulnerability context, VEX information, exposure, and mission consequence shape the release decision?
- Question 05What happens when a previously admitted artifact no longer conforms after new vulnerability or policy information appears?
- Question 06Which measures will show that fewer unauthorized or untrusted artifacts reach runtime without making delivery unsupportable?
Selected references
Primary product and federal guidance informing this review
- Google Cloud Artifact Analysis overview
- Google Cloud Binary Authorization overview
- Google Cloud Binary Authorization attestations
- Google Cloud software supply chain security overview
- NIST SP 800-218, Secure Software Development Framework Version 1.1
- NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
Next field review
AWS Inspector and Security Hub: From Vulnerability Findings to Risk Prioritization
The next installment examines how AWS-native vulnerability and security findings can be correlated, prioritized, assigned, and translated into verified remediation.
