이 페이지에서는 메타데이터 관리의 핵심 개념과 안전한 소프트웨어 제공 체인에서의 중요성을 소개합니다.
안전한 공급망의 한 가지 측면은 소프트웨어 아티팩트의 수명 주기를 추적하는 것입니다. 규정 준수를 위해 아티팩트가 지원 중단된 후에도 이 추적 정보를 사용할 수 있어야 할 수 있습니다. 이는 아티팩트 또는 소프트웨어 리소스(컨테이너 이미지, 가상 머신, 소프트웨어 패키지)에 관한 중요한 이벤트를 설명하는 메타데이터를 생성하고 저장하여 달성할 수 있습니다.
Artifact Analysis를 사용하면 리소스와 연결된 메타데이터 정보를 저장할 수 있으며, 이 메타데이터는 나중에 소프트웨어 공급망을 감사하기 위해 검색할 수 있습니다.
Artifact Analysis에서 메타데이터를 저장하는 방법
아티팩트 분석은 정책 추적 및 시행을 위한 중앙화된 정보 소스로 작동할 수 있는 오픈소스 구성요소 메타데이터 API인 Grafeas를 기반으로 합니다. 빌드, 감사, 규정 준수 도구는 Grafeas를 사용하여 소프트웨어 구성요소에 관한 포괄적인 메타데이터를 저장, 쿼리, 검색할 수 있습니다.
Grafeas는 오픈소스이므로 특정 공급업체에 종속되지 않습니다.
Grafeas는 고유한 소프트웨어 식별자를 사용하여 메타데이터를 연결합니다. 아티팩트 저장소를 분리하므로 여러 저장소의 구성요소에 관한 메타데이터를 저장할 수 있습니다. Artifact Analysis에도 동일한 원칙이 적용되며, Artifact Registry 또는 다른 위치의 소프트웨어 구성요소에 대한 중앙 집중식 범용 메타데이터 저장소로 사용할 수 있습니다.
Grafeas 모델에는 두 가지 항목이 포함됩니다.
메모에 저장된 메타데이터를 만드는 제공업체입니다.
메모에 저장된 메타데이터가 아티팩트에 적용되는지 확인하는 고객입니다. 이 경우 메타데이터는 메모의 어커런스로 표시됩니다.
참고
메모는 상위 수준의 메타데이터를 설명합니다. 예를 들어 Linux 패키지의 특정 취약점에 대한 메모를 작성할 수 있습니다. 메모를 사용하여 빌드 프로세스의 빌더 관련 정보를 저장할 수도 있습니다. 일반적으로 분석을 수행하는 제공업체가 메모를 소유하고 만듭니다. 그런 다음 메타데이터를 사용하려는 고객은 프로젝트 내에서 발생하는 메모를 식별할 수 있습니다.
메모와 어커런스를 별도의 프로젝트에 저장하여 보다 세밀한 액세스 제어가 가능합니다.
메모는 메모 소유자만 편집할 수 있고, 메모를 참조하는 어커런스에 액세스할 수 있는 고객은 메모를 읽을 수만 있어야 합니다.
어커런스
어커런스는 소프트웨어 아티팩트에서 메모가 발견된 시점을 나타냅니다. 메모의 인스턴스화라고 생각하면 됩니다. 예를 들어 취약점에 대한 메모의 어커런스는 취약점이 발견된 패키지와 구체적인 해결 조치 단계 등을 설명합니다. 또한 빌드 세부정보에 대한 메모의 어커런스는 빌드로 인해 생성된 컨테이너 이미지를 설명합니다.
일반적으로 어커런스는 메모가 생성된 프로젝트가 아닌 별도의 프로젝트에 저장됩니다. 어커런스에 대한 쓰기 액세스 권한은 메모를 어커런스에 연결할 수 있는 사용자에게만 부여해야 합니다. 어커런스에 대한 읽기 액세스 권한은 모든 사용자가 가질 수 있습니다.
지원되는 메타데이터 유형
다음 표에는 아티팩트 분석에서 지원하는 메타데이터 유형이 나와 있습니다. 서드 파티 메타데이터 제공업체는 고객의 이미지에 대해 다음과 같은 메타데이터 유형 일체를 저장하고 검색할 수 있습니다.
메타데이터 유형
Google Cloud 서비스에서의 사용
취약점: 감사된 파일의 취약점 정보를 제공합니다.
Artifact Analysis는 공개적으로 공개된 보안 문제의 외부 데이터베이스를 기반으로 취약점 발생을 생성합니다.
빌드: 빌드 출처에 대한 정보를 제공합니다.
Cloud Build를 사용하여 이미지를 빌드하는 경우 Cloud Build에서 이 메타데이터를 생성하고 Artifact Analysis에서 정보를 저장합니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-03(UTC)"],[[["\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)."]]
