[[["易于理解","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 generates and stores Software Bill of Materials (SBOMs) for container images in Artifact Registry, aiding in understanding software dependencies and improving security.\u003c/p\u003e\n"],["\u003cp\u003eSBOMs created by Artifact Analysis are in SPDX 2.3 format, with support for uploading SBOMs in other formats, and are stored in Cloud Storage within your Google Cloud project.\u003c/p\u003e\n"],["\u003cp\u003eArtifact Analysis supports various package types including OS, Java (Maven), Go, Python, and Node.js (npm) and provides a Grafeas SBOM reference occurrence with details like Cloud Storage location, hash, and signature.\u003c/p\u003e\n"],["\u003cp\u003eIn addition to SBOMs, Artifact Analysis generates a Grafeas package occurrence for each installed package, including version, type, and license information, but only for images stored in Artifact Registry.\u003c/p\u003e\n"],["\u003cp\u003eThe platform will only work for images stored within Artifact Registry, and not the deprecated Container Registry, so transitioning from Container Registry to Artifact Registry is necessary to utilize these features.\u003c/p\u003e\n"]]],[],null,["# SBOM overview\n\nThis document introduces SBOM concepts and outlines the Artifact Analysis\nfeatures available to help you understand the dependencies in your software\nsupply chain.\n\nWhen you store a container image in Artifact Registry, you can create a software bill\nof materials (SBOM) describing the contents of that image. Knowing your\nsoftware's dependencies can help you improve your security posture. An SBOM can\nalso help you attest to the composition of your software in support of\ncompliance with security regulations such as\n[Executive Order (EO) 14028](https://www.cisa.gov/topics/cybersecurity-best-practices/executive-order-improving-nations-cybersecurity).\n\nSBOMs\n-----\n\nAn SBOM is a machine-readable inventory of an application, identifying the\npackages your software relies on. The contents can include third-party software\nfrom vendors, internal artifacts, and open source libraries.\n\nArtifact Analysis lets you generate SBOMs or upload your own.\n\nWhether you generate your SBOM with Artifact Analysis or upload your own,\nArtifact Analysis provides consistent storage and retrieval processes to\nhelp you coordinate and assess all of your dependency information in one place.\n\nSBOM format\n-----------\n\nArtifact Analysis produces SBOMs in the\n[Software Package Data Exchange (SPDX) 2.3](https://spdx.github.io/spdx-spec/v2.3/) format.\n\nIf you want to upload an existing SBOM from outside Google Cloud, additional\nformats are supported. See [Upload\nSBOMs](/artifact-analysis/docs/upload-sbom#formats).\n\nSBOM storage\n------------\n\nArtifact Analysis stores your SBOMs in Cloud Storage in your\nGoogle Cloud project. SBOMs remain stored in Cloud Storage unless you\n[delete the SBOM objects](/storage/docs/deleting-objects) or\n[delete the bucket](/storage/docs/deleting-buckets). For information on pricing,\nsee [Cloud Storage Pricing](https://cloud.google.com/storage/pricing).\n\nSupported package types\n-----------------------\n\nThe SBOM provides a list of all the packages that can be identified by\nArtifact Analysis scanning. Packages must be containerized\nand stored in a Docker repository in Artifact Registry.\n\nFor more information on supported package types, see\n[Container scanning overview](/artifact-analysis/docs/container-scanning-overview).\n\nSBOM reference occurrence\n-------------------------\n\nIn addition to the container-specific SBOM, Artifact Analysis generates a\nGrafeas SBOM [reference occurrence](https://github.com/grafeas/grafeas/blob/master/proto/v1/sbom.proto#L40) which includes\nthe following information:\n\n- The Cloud Storage location of the SBOM\n- A hash of the SBOM\n- A signature over the `SbomReferenceIntotoPayload`\n\nYou can use the signature to verify that the SBOM was generated by\nArtifact Analysis.\n\nThe signing uses the [DSSE signature protocol](https://github.com/secure-systems-lab/dsse), with the\npayload type `application/vnd.in-toto+json`.The payload is the jsonified value\nof the `SbomReferenceIntotoPayload`.\n\nPackage occurrence\n------------------\n\nTo provide more dependency information, Artifact Analysis also generates a\nGrafeas [package occurrence](https://github.com/grafeas/grafeas/blob/master/proto/v1/package.proto#L122) for each installed\npackage. Package occurrences include the following information:\n\n- Package version\n- Package type\n- License information for installed packages\n\nLimitations\n-----------\n\n- Installed package tracking is only supported for container images that are pushed to Artifact Registry and assessed by the Container Scanning API. By extension, the gcloud CLI lookup based on installed packages only works with images stored in Artifact Registry, because installed packages are only tracked on those images.\n\nWhat's next\n-----------\n\n- [Generate and store SBOMs](/artifact-analysis/docs/generate-store-sboms).\n- [Upload SBOMs](/artifact-analysis/docs/upload-sbom).\n- [View SBOMs and dependencies](/artifact-analysis/docs/view-sboms-dependencies)."]]
