SBOM (software bill of materials)

A software bill of materials (SBOM) is a machine-readable inventory of the components inside a piece of software: each library and package, its version, its supplier, its license and how it relates to the others. It answers the question "what exactly did we ship?".

What it is

An SBOM is usually generated during the build, from lockfiles, manifests or the built artifact, and written in a standard format. The two common ones are CycloneDX and SPDX. A useful SBOM identifies each component precisely, often with a package URL (purl) such as pkg:npm/[email protected], so tools can match it against vulnerability advisories and license lists.

An SBOM describes one version of the software. Ship a new build with different dependencies and you need a new SBOM.

Why it matters

When a new vulnerability is announced, the first question is "are we affected?". With an SBOM per release, that's a lookup, not an investigation. SBOMs also make license review possible at scale, and customers increasingly ask for them. In the US, Executive Order 14028 (2021) pushed SBOMs into federal software purchasing, and the NTIA published minimum elements for them the same year.

In AI CodeOps

AI CodeOps records SBOMs per project; it doesn't generate them or store the file itself. You create the SBOM with your existing tool, keep the file where you keep build artifacts, and record a snapshot. In the open beta that's a request to /api/sbom from a signed-in session (there's no upload form or API-key route yet):

{
  "projectID": "checkout",
  "commitSHA": "4f2a9c1e7b3d",
  "format": "cyclonedx",
  "formatVersion": "1.5",
  "downloadURL": "https://artifacts.example.com/checkout/4f2a9c1e7b3d/bom.json",
  "sha256": "9d1c5e0b7a2f4c6e8d0b1a3c5e7f9a2b4d6c8e0f1a3b5c7d9e2f4a6b8c0d1e3f",
  "componentCount": 412,
  "vulnerableCount": 3,
  "licenseSummary": { "MIT": 301, "Apache-2.0": 74, "ISC": 29, "BSD-3-Clause": 8 },
  "generationSource": "ci"
}

The SHA-256 lets anyone match the record to the file. The component and vulnerable counts and the license summary are the figures you send; AI CodeOps doesn't parse the file to check them.

The newest record is the project's current SBOM. You see it on the project page (Recent SBOMs, Vulnerable components (latest SBOM)) and in the Software Bill of Materials panel under Secure → Security, which rolls license summaries up across projects. The release check your CI calls can then enforce a license policy against it.

To look inside a CycloneDX JSON file without signing in, open the SBOM viewer.

Related terms

• CycloneDX: one of the two SBOM formats AI CodeOps records.
• Software composition analysis (SCA): the tooling that usually produces SBOMs and vulnerability counts.
• License policy: rules checked against the SBOM's license summary.