sbom.wiki

Introduction to SBOM

A Software Bill of Materials (SBOM) is a comprehensive inventory of all components, libraries, and dependencies in a software product.

Think of it as a nutritional label for software — it tells you exactly what is inside, where it came from, and what version you are running.

Transparency

Complete visibility into every component of your software supply chain.

Security

Rapidly identify vulnerable components when new CVEs are disclosed.

Compliance

Meet EO 14028, EU CRA, and industry-specific mandates.

Interoperability

SPDX and CycloneDX enable seamless data exchange across tools.

Industry Momentum

SBOMs are required for U.S. federal software. The EU Cyber Resilience Act extends requirements across Europe.

What is an SBOM?

A Software Bill of Materials is a formal, machine-readable record of the components present in a software artifact. It enumerates direct and transitive dependencies, their versions, suppliers, and relationships.

Anatomy of an SBOM

Component Identity

Name, version, supplier, and unique identifiers (CPE, PURL).

Relationships

Dependency trees: direct, transitive, dev, and optional.

License Data

SPDX license identifiers and expressions.

Provenance

Download URLs, checksums, and build metadata.

Timestamps

Creation date, modification, and validity period.

External References

Links to VEX documents, advisories, and upstream SBOMs.

CycloneDX JSON

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [{
    "type": "library",
    "name": "express",
    "version": "4.18.2",
    "purl": "pkg:npm/express@4.18.2"
  }]
}

Why SBOMs Matter

Modern software is assembled from hundreds of open-source and third-party components. Log4Shell in 2021 exposed how few organizations knew whether they were affected.

90%

of apps use open-source components

77%

of codebases have known vulnerabilities

40%

increase in supply chain attacks YoY

Key Milestones

2021

Executive Order 14028

U.S. mandates SBOMs for federal software vendors.

2024

EU Cyber Resilience Act

SBOMs required for digital products in EU.

2026

Industry Standard

SBOM generation default in CI/CD pipelines worldwide.

Quick Start Guide

Choose Format

SPDX (ISO standard) or CycloneDX (security-focused).

Pick a Tool

Use syft, cdxgen, or built-in package manager support.

Generate SBOM

$ syft packages dir:. -o spdx-json

Validate

Check conformance, enrich with VEX and supplier info.

Automate

Integrate into CI/CD. Scan with grype.

SPDX

SPDX is an open standard (ISO/IEC 5962:2021) by the Linux Foundation for communicating SBOM information including provenance, licensing, and security references.

Key Features

ISO international standard
Rich license expression language
Multiple formats: JSON, RDF, XML, YAML
Complex dependency relationships
Snippet-level granularity

Ecosystems

CycloneDX

CycloneDX is a lightweight SBOM standard by OWASP for application security contexts and supply chain analysis.

Feature	CycloneDX	SPDX
Focus	Security & risk	Licensing
Standards	OWASP / Ecma	LF / ISO
VEX	Native	External
BOM Types	SBOM, SaaSBOM, HBOM	SBOM
Formats	JSON, XML, Protobuf	JSON, RDF, XML, YAML

Format Comparison

Criteria	SPDX	CycloneDX	SWID
Best For	License compliance	Security analysis	Asset management
ISO	5962:2021	Ecma-424	19770-2
Complexity	High	Medium	Low
Tooling	Extensive	Extensive	Limited
VEX	Via linking	Native	None

Generation Tools

Syft

Anchore

Generate SBOMs from container images and filesystems.

$ syft packages alpine:latest -o cyclonedx-json

cdxgen

CycloneDX

Multi-language SBOM generator for source-level analysis.

$ cdxgen -o sbom.json -t node .

Trivy

Aqua Security

All-in-one security scanner with SBOM generation.

$ trivy image --format cyclonedx myapp:v1

Validation

Validation Layers

Schema Validation

JSON/XML schema conformance.

NTIA Elements

All required fields present.

License Check

Valid SPDX expressions.

PURL/CPE

Identifier accuracy.

Executive Order 14028

Signed May 2021, EO 14028 mandates SBOMs for all software sold to the federal government.

Key RequirementsSBOM for each product delivered to agencies
NTIA minimum elements required
Machine-readable format (SPDX or CycloneDX)
Continuous lifecycle updates
Secure development self-attestation

NTIA Minimum Elements

The NTIA baseline for SBOM content. These are the floor, not the ceiling.

Supplier Name

Entity that creates components.

Component Name

Software designation by supplier.

Version String

Change identifier.

Unique Identifier

CPE, PURL, SWID Tag ID.

Dependency Relationship

How X is included in Y.

Author of SBOM

Entity creating the document.

Timestamp

Date/time of assembly.

VEX Documents

VEX documents communicate whether a product is actually affected by a known vulnerability.

Not Affected

Not exploitable in this context.

Affected

Exploitable. Remediation needed.

Fixed

Patch applied, version updated.

Under Investigation

Assessment in progress.

CI/CD Integration

Integrate SBOM generation into CI/CD for continuous supply chain security.

Build

Generate SBOM

Validate

Publish

GitHub Actions

- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    format: cyclonedx-json
    output-file: sbom.cdx.json
- name: Scan for vulnerabilities
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.cdx.json
    fail-build: true
    severity-cutoff: high