SBOM 101: A Complete Beginner's Guide to Software Bill of Materials

If you ship software in 2022, someone is going to ask you for a Software Bill of Materials. Maybe it's a federal agency invoking Executive Order 14028. Maybe it's an enterprise customer with a new procurement checklist. Either way, the question is coming, and "we'll get back to you" is not an answer that ages well.

This guide breaks down what an SBOM actually is, why the industry is converging on it, and how you start producing one without turning your build pipeline inside out.

What Is an SBOM?

A Software Bill of Materials is a machine-readable inventory of every component inside a piece of software. Think of it like the ingredient list on a food label, except instead of "modified corn starch" you're listing lodash@4.17.21 or openssl-1.1.1k.

An SBOM typically captures:

• Component names and versions -- the exact packages included
• Suppliers and authors -- who produced each component
• Dependency relationships -- which components depend on which
• Licenses -- what legal terms govern each component
• Hashes and identifiers -- cryptographic checksums, CPEs, or Package URLs (purls) that pin each component to a specific artifact

The point is transparency. When a vulnerability drops -- say, the next Log4Shell -- an SBOM lets you answer "are we affected?" in minutes instead of days.

Why SBOMs Matter Now

Software supply chain attacks aren't new. What's new is the frequency, the scale, and the regulatory attention.

The Regulatory Push

Executive Order 14028, signed in May 2021, directed NIST to define minimum SBOM requirements for software sold to the US federal government. The Cyber Safety Review Board followed up with specific recommendations after the Log4j incident. The EU's Cyber Resilience Act is drafting similar requirements for the European market.

This is not a trend that reverses.

The Dependency Problem

Modern applications are assembled more than they are written. A typical Node.js project pulls in hundreds of transitive dependencies. A Java application can have thousands. Most development teams cannot name half the libraries in their dependency tree without tooling.

When a CVE drops against one of those libraries, you need to know:

1. Do we use this library?
2. Which version?
3. In which products?
4. In production or just dev?

An SBOM gives you that lookup capability before the crisis hits.

The Trust Problem

If you're a software vendor, your customers increasingly want proof that you know what's inside your product. If you're a buyer, you want confidence that your vendor isn't shipping known-vulnerable components. SBOMs establish that baseline of mutual accountability.

SBOM Formats: CycloneDX vs SPDX

Two formats dominate the SBOM landscape.

CycloneDX

Originally created by OWASP, CycloneDX is designed specifically for security use cases. It supports JSON and XML, versions components with Package URLs, and includes native fields for vulnerability information and service definitions.

CycloneDX is practical and developer-friendly. Its schema is tight, the tooling ecosystem is broad, and the specification evolves fast.

SPDX

SPDX (Software Package Data Exchange) comes from the Linux Foundation and started as a license compliance format. It has since expanded to cover security use cases and became ISO/IEC 5962:2021 -- the first internationally recognized SBOM standard.

SPDX supports tag-value, JSON, XML, YAML, and RDF formats. It's more verbose than CycloneDX but carries more legal and provenance metadata.

Which Should You Pick?

If your primary concern is vulnerability management, CycloneDX is the path of least resistance. If license compliance matters or you're dealing with government procurement that references ISO standards, SPDX has the edge. In practice, most organizations will need to support both.

How to Generate Your First SBOM

You don't need to buy a platform to produce an SBOM. Several open-source tools will get you started in minutes.

Using Syft

Anchore's Syft is one of the most popular SBOM generators. It works against container images, directories, and archives.

# Install Syft
curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin

# Generate a CycloneDX SBOM from a container image
syft alpine:latest -o cyclonedx-json > sbom.json

# Generate an SPDX SBOM from a local directory
syft dir:./my-project -o spdx-json > sbom.spdx.json

Using Trivy

Aqua Security's Trivy combines vulnerability scanning with SBOM generation.

# Generate a CycloneDX SBOM
trivy image --format cyclonedx --output sbom.json alpine:latest

# Generate an SPDX SBOM
trivy fs --format spdx-json --output sbom.spdx.json ./my-project

Using cdxgen

CycloneDX Generator (cdxgen) is purpose-built for CycloneDX and supports a wide range of language ecosystems.

# Install cdxgen
npm install -g @cyclonedx/cdxgen

# Generate SBOM for a Node.js project
cdxgen -o sbom.json ./my-node-project

What Makes a Good SBOM?

Not all SBOMs are equal. A good SBOM has:

1. Completeness -- every component, including transitive dependencies, is listed
2. Accuracy -- version numbers and identifiers are correct, not approximated
3. Timeliness -- generated at build time, not weeks later from memory
4. Machine readability -- valid JSON or XML that tools can parse
5. Stable identifiers -- Package URLs or CPEs that connect components to vulnerability databases

A bad SBOM is worse than no SBOM because it creates false confidence. If your SBOM says you're running OpenSSL 1.1.1n but you're actually on 1.1.1k, you'll miss the vulnerabilities patched between those versions.

Integrating SBOMs Into Your Workflow

The real value of SBOMs comes when they're part of your process, not a one-time artifact.

Build-Time Generation

Generate SBOMs as part of your CI/CD pipeline. Every build should produce a fresh SBOM that reflects exactly what went into that artifact.

# Example GitHub Actions step
- name: Generate SBOM
  run: syft dir:. -o cyclonedx-json > sbom.json

- name: Upload SBOM
  uses: actions/upload-artifact@v3
  with:
    name: sbom
    path: sbom.json

Storage and Versioning

Store SBOMs alongside your release artifacts. If you publish container images, attach the SBOM as an OCI artifact. If you distribute binaries, ship the SBOM with the release.

Continuous Monitoring

An SBOM generated last month doesn't tell you about vulnerabilities discovered today. You need a system that re-evaluates stored SBOMs against current vulnerability data continuously.

Common Misconceptions

"SBOMs are just for compliance." Compliance is the floor, not the ceiling. The operational value -- incident response speed, license risk management, dependency health tracking -- is where SBOMs pay for themselves.

"Our scanner already does this." Vulnerability scanners check for known CVEs. An SBOM is the underlying inventory that makes scanning accurate and auditable. They're complementary, not interchangeable.

"We only use open-source tools, so we don't need this." Open-source tools are exactly where you need SBOMs the most. Every npm install or pip install is pulling code from thousands of maintainers you've never met.

"SBOMs expose our intellectual property." An SBOM lists components, not your proprietary logic. It's the ingredient list, not the recipe.

What Comes Next

Once you're generating SBOMs, the natural next steps are:

• Vulnerability matching -- correlating SBOM components against CVE databases
• Policy enforcement -- blocking builds that include components with critical vulnerabilities or prohibited licenses
• Drift detection -- comparing SBOMs across versions to catch unexpected dependency changes
• Sharing -- distributing SBOMs to customers, auditors, and partners through standard protocols

How Safeguard.sh Helps

Safeguard automates the SBOM lifecycle end to end. Upload or generate SBOMs through the platform, and Safeguard continuously monitors every component against live vulnerability feeds. Policy gates catch risky dependencies before they reach production. When a new CVE drops, you get immediate visibility into which products are affected -- no manual grep through dependency trees. The platform supports both CycloneDX and SPDX, integrates with your CI/CD pipeline, and provides a single dashboard for tracking SBOM health across your entire portfolio.