What Is SBOM? A Developer’s Guide to Software Bill of Materials

When the Log4Shell vulnerability dropped in December 2021, security teams worldwide faced the same urgent question: do we use Log4j, and where? Teams without a component inventory spent days manually auditing repos. Teams with one had answers in hours.

That gap — between knowing and not knowing what's inside your software — is exactly what Software Bills of Materials (SBOMs) solve. An SBOM is a machine-readable inventory of every library, version, and dependency in your codebase. It has quietly become one of the most important artifacts in modern software security: required by US federal procurement under EO 14028, expected under the EU Cyber Resilience Act, and increasingly demanded by enterprise customers during vendor due diligence.

This guide covers what SBOMs contain, how to generate one, how to integrate it into your CI/CD pipeline, and how to move beyond static snapshots to continuous vulnerability monitoring.

---

What Is an SBOM?

An SBOM (Software Bill of Materials) is a machine-readable inventory of every component in a piece of software.

Think of it as the ingredient list on a food package — but for code. An SBOM records every open-source library, commercial dependency, transitive package, version number, license, and the relationships between those components.

Why SBOMs Became a Baseline Engineering Practice

When the Log4Shell vulnerability (CVE-2021-44228) was disclosed in December 2021, organizations worldwide scrambled to answer a simple question:

"Do we use Log4j, and where?" Teams without SBOMs spent days — sometimes weeks — manually auditing repositories and build artifacts. Teams with SBOMs identified affected systems within hours. That gap in response time directly translates to breach risk and remediation cost.

Today SBOMs are no longer optional for many organizations:

• US Executive Order 14028 requires software vendors supplying federal agencies to provide SBOMs as part of procurement.
• EU Cyber Resilience Act (CRA) introduces similar expectations across the EU market, with enforcement planned from 2027.
• NTIA Minimum Elements for an SBOM defines the baseline fields required for compliance.

Generating and maintaining SBOMs has therefore become a baseline engineering practice in modern DevSecOps.

---

SBOM Scope

An SBOM can describe software at multiple levels:

• Source code — components declared in manifest files (package.json, requirements.txt, pom.xml, go.mod)
• Build artifacts — compiled binaries and bundled outputs
• Container images — OS packages, language runtimes, and application layers
• Firmware — embedded software components
• Any deployable software unit — serverless functions, ML model packages, etc.

A single application may generate multiple SBOMs — one per build target, container image, or release artifact. For containerized applications, it is common to attach SBOMs directly to OCI images using tools like cosign attach sbom.

---

What an SBOM Contains

An SBOM includes standardized metadata for each component. The NTIA Minimum Elements define seven required fields that every compliant SBOM must include:

Field	Description	NTIA Required
Component Name	Library or package identifier	✅
Version	Exact version string used	✅
Supplier	Maintainer or vendor of the component	✅
Unique Identifier	PURL or CPE for precise matching	✅
Dependency Relationships	Links between components	✅
Author of SBOM Data	Who produced this SBOM	✅
Timestamp	When the SBOM was generated	✅
License	Open-source license metadata	➕ Recommended
Hash	Integrity verification (SHA-256, etc.)	➕ Recommended

Note: Many SBOM tools also capture license, hash, and download location fields. While not strictly required by NTIA, these fields are expected by most downstream security tooling and should be treated as de facto required.

Transitive Dependencies: The Hidden Risk

One of the most critical aspects of SBOMs is capturing transitive dependencies — the indirect packages pulled in by your direct dependencies. A real-world dependency graph for even a modest Python microservice can look like this:

In production applications, this graph can reach hundreds of transitive nodes. A single library may introduce dozens of indirect dependencies — each a potential attack surface. SBOMs make this graph explicit and machine-queryable, so when [[email protected]](/cdn-cgi/l/email-protection) appears in a CVE feed, you know immediately which services are affected.

SBOM Example (CycloneDX JSON)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.6",
  "metadata": {
    "timestamp": "2025-03-13T10:00:00Z",
    "component": { "type": "application", "name": "my-api-service", "version": "2.4.1" }
  },
  "components": [
    {
      "type": "library",
      "name": "requests",
      "version": "2.31.0",
      "purl": "pkg:pypi/requests@2.31.0",
      "licenses": [{ "license": { "id": "Apache-2.0" } }],
      "hashes": [{ "alg": "SHA-256", "content": "942c5a758f98d790..." }]
    }
  ]
}

This enriched format — with timestamp, tools, hashes, and metadata.component — satisfies all NTIA minimum elements and is accepted by major vulnerability databases.

---

SBOM Formats: CycloneDX vs SPDX

The two dominant SBOM standards serve overlapping but distinct purposes:

Dimension	CycloneDX	SPDX
Maintained by	OWASP	Linux Foundation
Current version	1.6	2.3 / 3.0 (draft)
Primary focus	Security and vulnerability context	License compliance
Serialization formats	JSON, XML, Protobuf	JSON-LD, YAML, RDF, tag-value
VEX support	Native (built into spec)	External (via separate document)
NTIA compliance	✅ Full	✅ Full
Best suited for	DevSecOps pipelines, CVE matching	Legal/compliance teams, open-source audits

Practical guidance: For security-first workflows (vulnerability tracking, CI/CD gating), CycloneDX is the stronger choice. For open-source program offices and license audits, SPDX is better aligned with legal and compliance tooling. Many mature organizations generate both formats simultaneously from a single scan.

---

SBOM vs SCA

These two concepts are closely related but serve different roles:

Category	SBOM	SCA (Software Composition Analysis)
What it is	A structured inventory of components	A continuous analysis process
Primary output	Machine-readable component list	Vulnerability and license findings
When it runs	Build time / release time	Continuously, or on every commit
Regulatory artifact	Yes — satisfies EO 14028, CRA	No — a process, not an artifact
Relationship	Provides the inventory SCA analyzes	Consumes the SBOM as input

Put simply: SBOM is the ingredient list; SCA is the nutritionist reading it. You need both — the SBOM gives you an auditable artifact for compliance and sharing with customers, while SCA gives you actionable vulnerability findings.

---

How to Generate an SBOM

SBOMs are generated using tools that analyze source code, build artifacts, or container images. The most widely adopted open-source tool is Syft, maintained by Anchore.

Below is a simplified view of how SBOM generation fits into a modern DevSecOps pipeline.

Dependency manifests such as package.json, requirements.txt, or pom.xml are analyzed during the build process to generate SBOM artifacts. These artifacts are then scanned against vulnerability databases.

Generating an SBOM with Syft

The most common invocation scans a project directory and outputs a CycloneDX JSON file:

syft dir:./my-service --output cyclonedx-json=sbom.json

Other SBOM Generation Tools

Tool	Best For	Output Formats	Limitations
Syft	Directories, containers, binaries	CycloneDX, SPDX	Static snapshot only — no continuous monitoring or VEX analysis
cdxgen	Language-native deep scanning	CycloneDX	Generation only — requires separate tooling for CVE matching and reporting
Trivy	Containers + vuln scanning combined	CycloneDX, SPDX	Limited to container scope — no compliance reporting or VEX support

---

Integrating SBOM into CI/CD

For most teams, generating an SBOM per tagged release is the right starting point. As your security posture matures, you can add per-PR scanning and policy gates.

GitHub Actions Example

name: Build and Generate SBOM

on:
  push:
    tags: ['v*']

jobs:
  sbom:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

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

      - name: Generate SBOM
        run: syft dir:. --output cyclonedx-json=sbom.json

      - name: Upload SBOM as release artifact
        uses: softprops/action-gh-release@v2
        with:
          files: sbom.json

Adding a Vulnerability Gate with Grype

After generating the SBOM, you can fail the pipeline on critical findings:

# Install Grype (Anchore's vulnerability scanner)
curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin

# Scan the SBOM and fail on critical CVEs
grype sbom:./sbom.json --fail-on critical

This pattern — generate SBOM → scan SBOM → gate on severity — is the foundation of a mature DevSecOps pipeline.

Limitations of Standalone SBOM Tools

Syft and Grype cover generation and scanning, but several gaps remain in production workflows.

Static snapshots. A CVE disclosed after release won't surface against an existing SBOM — teams must re-scan manually.

Precogs AI monitors component inventories continuously, alerting on new CVEs without a re-scan.

Vulnerability noise. Grype returns every CVE match regardless of reachability — a typical service scan yields 200–400 results, most not actionable.

Precogs AI applies VEX analysis to filter unreachable code paths, surfacing only exploitable risk.

Toolchain fragmentation. A complete pipeline requires separate tools for generation, scanning, VEX enrichment, and reporting — held together with custom scripts.

Precogs AI replaces the entire toolchain with a single integration.

No compliance reporting. Syft and Grype produce CLI output, not audit artifacts. Mapping findings to NTIA, EO 14028, or EU CRA requires custom work.

Precogs AI generates compliance-ready reports out of the box.

No lifecycle management. Neither tool tracks SBOM history across release versions or alerts when a new CVE affects an older release.

Precogs AI maintains a live inventory across all versions, surfacing newly disclosed CVEs against historical releases automatically.

---

What Precogs AI Does Differently

---

Frequently Asked Questions

Why are SBOMs important for software security?

Modern applications commonly pull in hundreds or thousands of transitive dependencies. Without an SBOM, you have no reliable way to answer "are we affected?" when a new CVE drops. With an SBOM, the answer becomes a database query rather than a multi-day manual audit. The Log4Shell incident is the canonical example: organizations with SBOMs identified exposure within hours; those without them spent days or weeks.

Is an SBOM the same as a dependency lock file?

No. Lock files (package-lock.json, poetry.lock, go.sum) ensure reproducible builds by pinning dependency versions. An SBOM goes further by adding standardized metadata — licenses, cryptographic hashes, PURLs, supplier information, timestamps, and structured dependency relationships. Lock files are often used as input to SBOM generators, but they are not a substitute: they don't satisfy NTIA minimum elements, and they can't be consumed by vulnerability databases directly.

Do I need to generate an SBOM on every commit?

For most teams, per release is the right starting cadence. Generate and sign an SBOM for each tagged release or build artifact. For higher-security environments (financial services, healthcare, government supply chains), per-PR SBOM generation with automated diff analysis can catch regressions earlier. Start with release-time generation and add frequency as your tooling matures.

What is a PURL and why does it matter?

A Package URL (PURL) is a standardized, ecosystem-agnostic identifier for software packages. Example:

pkg:pypi/[[email protected]](/cdn-cgi/l/email-protection)
pkg:npm/%40babel/[[email protected]](/cdn-cgi/l/email-protection)
pkg:maven/org.apache.logging.log4j/[[email protected]](/cdn-cgi/l/email-protection)

PURLs allow vulnerability databases (NVD, OSV, GitHub Advisory) to match your components with high precision. Without standardized identifiers, package-to-CVE matching is inconsistent and error-prone — different tools may refer to the same package under different names.

What is VEX and why should I care?

VEX (Vulnerability Exploitability eXchange) is a companion document to an SBOM that provides exploitability context for each vulnerability. Common statuses:

• not_affected — the vulnerable code path is unreachable in this product build
• affected — the vulnerability is exploitable and requires remediation
• fixed — the issue has been patched in this version
• under_investigation — status pending analysis

Without VEX, a typical enterprise SBOM might surface 300–500 CVEs per release. With VEX analysis, the actionable list shrinks to a handful. VEX is what turns an SBOM from a compliance checkbox into a practical security tool.

How do I share an SBOM with customers or auditors?

Common distribution methods include: attaching the SBOM JSON file to GitHub releases, embedding it in OCI image metadata via cosign attach sbom, hosting it at a well-known URL path (/.well-known/sbom), and including it in vendor security packages shared during procurement. For regulated industries, signed SBOMs (using cosign sign-blob or Sigstore) provide cryptographic proof of origin and integrity.

What is the difference between CycloneDX 1.5 and 1.6?

CycloneDX 1.6 (released 2024) added native support for machine learning model components, improved attestation capabilities, and expanded VEX integration. If you are generating SBOMs for AI/ML pipelines or need richer attestation metadata, target 1.6. For standard application SBOMs, 1.5 and 1.6 are functionally equivalent at the component-inventory level.

---

Conclusion

Modern applications depend on hundreds of third-party components. Without visibility into those components, the most basic supply-chain security question — "Are we affected?" — takes days to answer instead of minutes.

An SBOM makes that question answerable. As regulations like EO 14028 and the EU Cyber Resilience Act raise the bar, generating and maintaining SBOMs is transitioning from a best practice to a contractual requirement.

Maintaining a complete SBOM pipeline — generation, vulnerability matching, VEX analysis, continuous monitoring, and compliance reporting — requires significant tooling and ongoing integration work. Precogs AI automates the entire lifecycle in a single pipeline integration.

Precogs AI covers SBOM generation, continuous monitoring, and VEX analysis — alongside code security, PII detection, and AI application security. Looking for an all-in-one security platform? Try it free — no credit card required.

---