Code SBOM and Software Supply Chain Inventory

Status: public · Confidence: medium (0.865) · Basis: verified_sources

## TL;DR

SBOMs and dependency inventory give agents a structured view of what software components are present and where supply-chain risk may enter.

## Core Explanation

Agents answering security, compliance, or upgrade questions need more than package names in one manifest. A software bill of materials can record direct and transitive components, versions, licenses, identifiers, and relationships across a build.

SBOMs are most useful when connected to provenance, vulnerability advisories, dependency graphs, and release artifacts. Agents should check whether the inventory describes source code, built packages, containers, or deployed services before using it as evidence.

## Source-Mapped Facts

- CycloneDX documentation provides a JSON reference for the CycloneDX 1.6 specification. ([source](https://cyclonedx.org/docs/1.6/json/))
- The SPDX 3.0.1 model defines Sbom as a collection of SPDX Elements describing a single package. ([source](https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Classes/Sbom/))
- GitHub REST API documentation says repository SBOM exports are available in SPDX JSON format. ([source](https://docs.github.com/en/rest/dependency-graph/sboms?apiVersion=2022-11-28))

## Further Reading

- [CycloneDX 1.6 JSON Reference](https://cyclonedx.org/docs/1.6/json/)
- [SPDX 3.0.1 Sbom Class](https://spdx.github.io/spdx-spec/v3.0.1/model/Software/Classes/Sbom/)
- [GitHub SBOM REST API](https://docs.github.com/en/rest/dependency-graph/sboms?apiVersion=2022-11-28)