[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-08-19。"],[[["\u003cp\u003eArtifact Analysis facilitates the storage and retrieval of metadata crucial for auditing and securing the software supply chain, by leveraging Grafeas, an open-source component metadata API.\u003c/p\u003e\n"],["\u003cp\u003eGrafeas employs a model with "providers" creating metadata in "notes," and "customers" identifying "occurrences" of these notes on their artifacts, allowing for detailed tracking of software component lifecycles.\u003c/p\u003e\n"],["\u003cp\u003eNotes represent high-level metadata, such as vulnerability details or build information, and occurrences represent specific instances of a note applied to a particular software artifact, such as a specific instance of a vulnerability in a package.\u003c/p\u003e\n"],["\u003cp\u003eArtifact Analysis supports several metadata types, including vulnerability, build, package, discovery, attestation, vulnerability assessment, and SBOM reference, catering to various aspects of software security and compliance.\u003c/p\u003e\n"],["\u003cp\u003eStoring notes and occurrences in separate projects is recommended for enhanced access control, ensuring that only note owners can edit notes, and only those who are linked to an occurrence can write to it.\u003c/p\u003e\n"]]],[],null,["# Metadata management overview\n\nThis page introduces key concepts for metadata management and its importance in\na secure software delivery chain.\n\nOne of the aspects of a secure supply chain is keeping track of the lifespan of\na software artifact. For compliance purposes, this tracking information might\nneed to be available even well after the artifact is retired. This can be\nachieved by generating and storing metadata that describes important events\nabout an artifact or a software resource: a container image, a virtual machine,\nor a software package.\n\nArtifact Analysis lets you store metadata information associated with\na resource, this metadata can be later retrieved to audit your software supply\nchain.\n\nHow Artifact Analysis stores metadata\n-------------------------------------\n\nArtifact Analysis is built on top of\n[Grafeas](https://grafeas.io), an open source component\nmetadata API that can work as a centralized source of truth for tracking and\nenforcing policies. Build, auditing, and compliance tools can use Grafeas to\nstore, query and retrieve comprehensive metadata about software components.\n\nBecause Grafeas is open source, you are not locked in to a particular vendor.\nGrafeas associates metadata using a unique software identifier. It decouples the\nartifact storage, so you can store metadata about components from many different\nrepositories. The same principles apply to Artifact Analysis, you can use\nit as a centralized universal metadata store for software components in\nArtifact Registry or any other location.\n\nThe Grafeas model involves two entities:\n\n- A **provider** that creates metadata stored in **notes**.\n- A **customer** that identifies if the metadata stored in a note applies to their artifacts. If that's the case, the metadata is represented as an **occurrence** of a note.\n\n### Note\n\nA [note](/artifact-analysis/docs/reference/rest/v1/projects.notes) describes a\nhigh-level piece of metadata. For example, you can create a note about a\nparticular vulnerability for a Linux package. You can also use a note to store\ninformation about the builder of a build process. Providers that perform the\nanalysis typically own and create notes. Customers that want to use the metadata\ncan then identify occurrences of notes within their projects.\n\nWe recommend that you store notes and occurrences in separate projects, allowing\nfor more fine-grained access control.\n\nNotes must be editable only by the note owner, and read-only for customers who\nhave access to occurrences referencing them.\n\n### Occurrence\n\nAn [occurrence](/artifact-analysis/docs/reference/rest/v1/projects.occurrences)\nrepresents when a note was found on a software artifact; it can be thought of as\nan instantiation of a note. For example, an occurrence of a note about a\nvulnerability would describe the package that the vulnerability was found in and\nspecific remediation steps. Alternatively, an occurrence of a note about build\ndetails would describe the container images that resulted from a build.\n\nTypically, occurrences are stored in separate projects than those where notes\nare created. Write access to occurrences should only be granted to users who\nhave access to link a note to the occurrence. Any user can have read access to\noccurrences.\n\nSupported metadata types\n------------------------\n\nThe following table lists the\n[metadata types](/artifact-analysis/docs/reference/rest/v1/NoteKind) that\nArtifact Analysis supports. Third-party metadata providers can store\nand retrieve all of the following metadata types for their customers' images.\n\nWhat's next\n-----------\n\n- [Provide metadata](/artifact-analysis/docs/store-retrieve-metadata) for your images.\n- Grant granular control over your metadata by [configuring access\n control](/artifact-analysis/docs/ca-access-control)."]]
