Store artifact metadata in attachments
Stay organized with collections
Save and categorize content based on your preferences.
This page describes how to store metadata related to an artifact stored in
Artifact Registry as an attachment.
Metadata stored in attachments can include information about artifact
vulnerabilities, build provenance, package contents, certification,
vulnerability assessment, Software Bill of Materials (SBOM) and more.
Information stored in Artifact Registry attachments can be used by
policy systems and inspected by users to ensure compliance.
For Docker repositories, attachments must be OCI artifacts. For all
formats other than Docker, attachments can be any file type.
To create an attachment, complete the following steps:
gcloud (all formats)
Before using any of the command data below,
make the following replacements:
ATTACHMENT: the fully qualified name
of the attachment, such as
projects/my-project/locations/us-west1/repositories/my-repo/attachments/my-attachment.
Alternatively, provide only the attachment ID and use the --location and
--repository flags.
TARGET: the fully qualified version name.
For Docker images only, you can also use the Artifact Registry URI of the artifact the
attachment refers to. In the URI, you can use the digest or, for Docker images, the tag—for example,
us-west1-docker.pkg.dev/my-project/my-repo/my-image:tag1.
The following example creates an attachment consisting of a file,
hello-world.txt, that refers to a container image, my-image, identified by
its URI and tag:
Docker repository attachments, including build provenance,
are deleted when artifacts they're attached to are deleted. If you use
cleanup policies to delete images
from your repository, then by default, the attachments on those images will
be deleted as well.
To ensure that attachments you want to keep aren't accidentally
deleted by a cleanup policy, you can assign a tag to an image
that has attachments you want to keep. Then, you can configure a cleanup
policy to retain images with those tags. For example, you could assign a
production-signed tag to images with attached build provenance.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2026-06-09 UTC."],[],[]]