Scanning and supply-chain governance
Storing an artifact is only half the job. Registry layers governance on top: vulnerability scanning, access control, retention, deployment pinning, and cross-namespace sharing. This page explains those capabilities and how they fit together. For exact request shapes, fields, and methods, see the API reference.
Vulnerability scanning
Section titled “Vulnerability scanning”Registry can scan an artifact for known vulnerabilities. Scanning is separate from the artifact lifecycle: you trigger a scan against a specific artifact, identified by its digest or one of its tags, and the registry dispatches it to a configured scanner engine. Each artifact tracks a scan status, from not yet scanned, through scanning, to scanned or failed, so you can tell at a glance where an artifact stands.
A completed scan produces a report: a count of findings by severity (critical, high, medium, and low) and the list of individual vulnerabilities behind those counts. Each finding names the vulnerability, the affected package and version, the version that fixes it where one exists, and a link to the advisory.
Scan policies
Section titled “Scan policies”A scan policy captures how scanning should behave for a namespace or a single repository. A policy can ask that artifacts be scanned automatically as they are pushed, that an artifact with a critical-severity finding be refused, and it can carry an allowlist of vulnerabilities that do not count against that block rule. Policies are configuration: a scanner engine applies them once one is connected.
Access control
Section titled “Access control”Access to a registry is granted, not assumed. An access policy binds a principal, a user, a group, or a service account, to a set of actions (pull, push, delete, or administer) over a namespace or a single repository. A repository-scoped grant narrows access to just that repository within the namespace.
Sometimes one team needs to consume another team’s images without copying them. A cross-namespace grant authorizes the principals of one namespace to act on another, for the actions it lists and until it expires. This is how a shared base-image namespace lets other namespaces pull from it without duplicating images.
Retention
Section titled “Retention”A retention policy keeps a repository from growing without bound. It describes what a repository should keep, as an ordered set of rules: keep the most recent N artifacts, keep anything pushed within the last N days, or keep artifacts whose tag matches a pattern. Anything no rule keeps becomes a candidate for cleanup on the policy’s schedule. Retention is declarative: policies are defined and managed today, and removal runs against them when retention execution is enabled.
Deployment locks
Section titled “Deployment locks”A deployment lock protects an artifact that is in use. It pins a specific artifact in a repository, noting what depends on it and, optionally, when the lock expires. While a lock is active, that artifact cannot be deleted. This keeps a running deployment from losing the image it booted from.
Deleting a namespace is guarded separately: a namespace must be empty before it can be removed, independent of any deployment lock. Locks are intended to be created when an image is put into service, for example by the Compute service.
Every governed action is meant to leave an audit record: who acted, what they did, which resource they touched, and the outcome. This audit trail backs the platform security baseline.