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-workspace 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 workspace’s registry or a single repository. A policy can ask that artifacts be scanned automatically as they arrive, 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 or push) over a scope: the whole workspace registry, a single repository, or every repository whose name matches a pattern. A policy only ever narrows what a principal’s role already allows; it never extends them beyond it.
Sometimes one team needs to consume another team’s images without copying them. A cross-workspace pull grant authorizes the principals of one workspace to pull from another, for the repositories and tag patterns it names and until it expires. This is how a shared base-image workspace lets other workspaces 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 repository is guarded separately: a repository must be marked for deletion 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.