SBOM overview

This document introduces SBOM concepts and outlines the Artifact Analysis features available to help you understand the dependencies in your software supply chain.

When you store a container image in Artifact Registry, you can create a software bill of materials (SBOM) describing the contents of that image. Knowing your software's dependencies can help you improve your security posture. An SBOM can also help you attest to the composition of your software in support of compliance with security regulations such as Executive Order (EO) 14028.

SBOMs

An SBOM is a machine-readable inventory of an application, identifying the packages your software relies on. The contents can include third-party software from vendors, internal artifacts, and open source libraries.

Artifact Analysis lets you generate SBOMs or upload your own.

Whether you generate your SBOM with Artifact Analysis or upload your own, Artifact Analysis provides consistent storage and retrieval processes to help you coordinate and assess all of your dependency information in one place.

SBOM format

Artifact Analysis produces SBOMs in the Software Package Data Exchange (SPDX) 2.3 format.

If you want to upload an existing SBOM from outside Google Cloud, additional formats are supported. See Upload SBOMs.

SBOM storage

Artifact Analysis stores your SBOMs in Cloud Storage in your Google Cloud project. SBOMs remain stored in Cloud Storage unless you delete the SBOM objects or delete the bucket. For information on pricing, see Cloud Storage Pricing.

Supported package types

The SBOM provides a list of all the packages that can be identified by Artifact Analysis scanning. Packages must be containerized and stored in a Docker repository in Artifact Registry.

Artifact Analysis supports the following package types:

  • OS
  • Java (Maven)
  • Go
  • Python
  • Node.js (npm)

SBOM reference occurrence

In addition to the container-specific SBOM, Artifact Analysis generates a Grafeas SBOM reference occurrence which includes the following information:

  • The Cloud Storage location of the SBOM
  • A hash of the SBOM
  • A signature over the SbomReferenceIntotoPayload

You can use the signature to verify that the SBOM was generated by Artifact Analysis.

The signing uses the DSSE signature protocol, with the payload type application/vnd.in-toto+json.The payload is the jsonified value of the SbomReferenceIntotoPayload.

Package occurrence

To provide more dependency information, Artifact Analysis also generates a Grafeas package occurrence for each installed package. Package occurrences include the following information:

  • Package version
  • Package type
  • License information for installed packages

Limitations

  • 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.
  • Container Registry (Deprecated) repositories are not supported. Learn how to transition from Container Registry.

What's next