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](https://www.cisa.gov/topics/cybersecurity-best-practices/executive-order-improving-nations-cybersecurity).

## 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](https://spdx.github.io/spdx-spec/v2.3/) format.

If you want to upload an existing SBOM from outside Google Cloud, additional
formats are supported. See [Upload
SBOMs](https://docs.cloud.google.com/artifact-analysis/docs/upload-sbom#formats).

## 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](https://docs.cloud.google.com/storage/docs/deleting-objects) or
[delete the bucket](https://docs.cloud.google.com/storage/docs/deleting-buckets). For information on pricing,
see [Cloud Storage Pricing](https://cloud.google.com/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.

For more information on supported package types, see
[Container scanning overview](https://docs.cloud.google.com/artifact-analysis/docs/container-scanning-overview).

## SBOM reference occurrence

In addition to the container-specific SBOM, Artifact Analysis generates a
Grafeas SBOM [reference occurrence](https://github.com/grafeas/grafeas/blob/master/proto/v1/sbom.proto#L40) 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](https://github.com/secure-systems-lab/dsse), 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](https://github.com/grafeas/grafeas/blob/master/proto/v1/package.proto#L122) 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.

## What's next

- [Generate and store SBOMs](https://docs.cloud.google.com/artifact-analysis/docs/generate-store-sboms).
- [Upload SBOMs](https://docs.cloud.google.com/artifact-analysis/docs/upload-sbom).
- [View SBOMs and dependencies](https://docs.cloud.google.com/artifact-analysis/docs/view-sboms-dependencies).