What is an SBOM?

A Software Bill of Materials (SBOM) is a structured inventory of the components in a software release. It records direct and transitive dependencies, versions, identifiers, relationships and, where possible, origin and hashes. An SBOM does not make software secure, but it quickly answers where an affected component is actually deployed.

What should an SBOM contain?

• Component:
  Name, version, supplier and identifiers such as Package URL or CPE.
• Relationships:
  Which application contains which direct and transitive libraries.
• Integrity:
  Hashes, creation time and generating tool.
• License and origin:
  Licenses, source and external references.
• Release binding:
  Exact artifact, image, firmware or version represented.

CycloneDX and SPDX

The suitable format depends on recipients and tooling. More important is automated, complete, reproducible generation for each release and preferably from the final artifact.

Small CycloneDX example

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "components": [{
    "type": "library",
    "name": "example-library",
    "version": "1.2.3",
    "purl": "pkg:npm/example-library@1.2.3",
    "hashes": [{ "alg": "SHA-256", "content": "..." }]
  }]
}

Practical use

1. Generate during build or from the final image.
2. Bind it to the release and protect it from modification.
3. Continuously compare components with CVE, vendor and threat data.
4. Validate reachability, used functionality and compensating controls; maintain VEX where useful.
5. When a new flaw appears, identify products, customers and support windows.

Useful open-source tools

Syft and cdxgen generate SBOMs. OSV-Scanner, Grype and Trivy compare components with vulnerabilities. Package name and version do not prove vulnerable code is reachable; analyst review remains necessary.