"What Is an SBOM? A Beginner's Guide to Software Bills of Materials"

If someone asked you "what software is in your project?" could you answer? Most developers can name the top 5 packages they installed. But behind those 5 packages are 200+ components they've never heard of — each one a potential security risk.

An SBOM (Software Bill of Materials) solves this. It's a structured document that lists every component in your software — what it is, what version it's on, and whether it has known vulnerabilities.

What Does SBOM Stand For?

SBOM = Software Bill of Materials

It's named after the BOM (Bill of Materials) used in manufacturing. When you build a car, the BOM lists every part — every bolt, wire, and circuit board. An SBOM does the same thing for software.

What's In an SBOM?

A complete SBOM includes:

- Component name — e.g., "requests", "flask", "react"

- Version number — e.g., "2.31.0", "3.0.0", "18.2.0"

- Package identifier — unique ID like pkg:pypi/[email protected]

- License — what legal terms govern this component

- Dependency relationships — what depends on what

- Known vulnerabilities — CVEs affecting this component

- Supplier — who maintains this component

Think of it as an ingredient label for your software. Just like food labels list every ingredient, SBOMs list every software component.

Why Do You Need an SBOM?

1. You Don't Know What You're Using

Most developers have no idea how many dependencies their project has. A typical Python project has 50-200 direct dependencies and 200-500 transitive dependencies. Without an SBOM, you're blind to most of your attack surface.

2. Security Vulnerabilities Hide in Dependencies

When a CVE is published for a package, you need to know if you're affected. Without an SBOM, you can't check. With an SBOM, you can instantly see which of your projects use the vulnerable package.

3. Compliance Is Becoming Mandatory

- EU CRA (2027): SBOMs required for all software sold in the EU

- US Executive Order 14028: SBOMs required for federal software

- FDA: SBOMs required for medical device submissions

- PCI DSS 4.0: Component inventory required for payment software

4. Incident Response Requires It

When a vulnerability is discovered, you need to know:

- Which of your products use the affected component?

- What version are they running?

- Which teams need to be notified?

An SBOM answers all three questions instantly.

SBOM Formats

There are three main formats:

Format	Maintained By	Best For	Standard
CycloneDX	OWASP	Security scanning	OWASP project
SPDX	Linux Foundation	License compliance	ISO/IEC 5962
SWID	ISO	Software identification	ISO/IEC 19770-2

For most projects: Use CycloneDX (security focus) or SPDX (compliance focus). VulnLedger supports both.

For a detailed comparison, see our SBOM Format Comparison.

How to Generate Your First SBOM

The fastest way — one command:

pip install vulnledger
vulnledger scan . --json --output sbom.json

This generates a CycloneDX SBOM in 5 seconds. It scans:

- Python packages (requirements.txt, pyproject.toml)

- JavaScript packages (package.json)

- Go modules (go.mod)

- Rust crates (Cargo.toml)

- Java dependencies (pom.xml)

- Docker images

What Your SBOM Looks Like

Here's a simplified example:

{
  "bomFormat": "CycloneDX",
  "components": [
    {"name": "requests", "version": "2.31.0", "purl": "pkg:pypi/[email protected]"},
    {"name": "flask", "version": "3.0.0", "purl": "pkg:pypi/[email protected]"}
  ],
  "vulnerabilities": [
    {"id": "CVE-2024-1234", "severity": "high", "affects": [{"ref": "pkg:pypi/[email protected]"}]}
  ]
}

SBOM vs Dependency List

An SBOM is not the same as a requirements.txt or package.json:

Feature	requirements.txt	SBOM
Lists direct deps	Yes	Yes
Lists transitive deps	No	Yes
Includes versions	Yes	Yes
Includes unique IDs	No	Yes
Includes licenses	No	Yes
Includes vulnerabilities	No	Yes
Machine-readable	Barely	Yes (JSON/XML)
Compliance-ready	No	Yes

Getting Started

If you've never generated an SBOM before:

1. Install: pip install vulnledger

2. Scan: vulnledger scan .

3. Review: You'll see every dependency and any known vulnerabilities

4. Automate: Add to CI/CD so every build generates an SBOM

That's it. You now have a complete inventory of your software's dependencies.

What to Do Next

After generating your first SBOM:

- Check for vulnerabilities — the scan shows CVEs automatically

- Review licenses — make sure you're not using GPL in proprietary code

- Set up CI/CD — generate SBOMs on every build

- Read our compliance guide — SBOM for Compliance: EU CRA, FDA, NIST

Frequently Asked Questions

Q: Is an SBOM the same as a dependency list?

A: No. A dependency list (requirements.txt, package.json) only shows direct dependencies. An SBOM shows ALL dependencies — direct and transitive — with versions, licenses, vulnerabilities, and unique identifiers.

Q: How often should I generate an SBOM?

A: On every build (via CI/CD) and daily (for monitoring). An SBOM from January is useless if new CVEs are published in March.

Q: What format should I use?

A: CycloneDX for security scanning, SPDX for license compliance. Both are widely accepted. See our format comparison for details.

Q: Is an SBOM required by law?

A: Not yet in most countries, but the EU CRA requires them by 2027. The US requires them for federal software. The trend is toward mandatory SBOMs.

Q: Can I generate an SBOM without a tool?

A: Technically yes — you could manually list every dependency. But it would take hours and be outdated immediately. Use a tool like VulnLedger (5 seconds, free, accurate).

Q: What's the difference between SBOM and SCA?

A: SCA (Software Composition Analysis) is the process of identifying and analyzing open-source components. An SBOM is the output of that analysis — the structured document listing all components. SCA is what you do; SBOM is what you produce.

Q: Do I need separate SBOMs for different environments?

A: Ideally, yes. A development SBOM might differ from a production SBOM (different dependency versions, different build configurations). But for most projects, one SBOM per release is sufficient.

Q: Can I use SBOMs for container images?

A: Yes. VulnLedger scans Docker images with vulnledger scan docker://image:tag. The SBOM includes both the base OS packages and your application dependencies.

Q: How do I share my SBOM with customers?

A: Generate it as JSON or XML, then attach it to your release artifacts, host it on your website, or share via email. VulnLedger's dashboard also provides a shareable link.

Q: What if my project has no dependencies?

A: If your project truly has zero dependencies (unlikely), the SBOM will be empty. But most projects have transitive dependencies even if they don't appear in your dependency file.

Q: Is an SBOM different from a BOM?

A: Yes. A traditional BOM lists physical parts (bolts, wires, circuits). An SBOM lists software components (libraries, frameworks, packages). Same concept, different domain.

Q: Can I use SBOMs for internal projects?

A: Absolutely. SBOMs are useful for any software — internal tools, client projects, open source. They help you track what you're using regardless of whether you sell the software.

Q: What's the minimum viable SBOM?

A: At minimum, an SBOM needs: component name, version, and unique identifier (PURL). That's enough to check for CVEs. Licenses, descriptions, and relationships are nice-to-haves but not essential for security scanning.

Q: How do SBOMs help with incident response?

A: When a CVE is published, you can instantly search your SBOM to see if you're affected. Without an SBOM, you'd have to manually check every project, every dependency, every version. With an SBOM, it takes one search.

Q: Can I generate an SBOM from a Git repository?

A: Yes. VulnLedger can scan any Git repository: vulnledger scan https://github.com/user/repo. It clones the repo and scans it automatically. No local installation needed.

Q: What happens if my SBOM has errors?

A: VulnLedger validates the SBOM before output. If a component can't be identified (unknown package manager, corrupted dependency file), it will be flagged in the output. Review any warnings before using the SBOM for compliance. Most issues are trivial to fix.

Conclusion

An SBOM is the foundation of software security and compliance. It tells you what's in your software, what vulnerabilities it has, and what licenses you're using. Generating one takes 5 seconds. Not having one can cost millions.

Next in this series: SBOM Formats: SPDX vs CycloneDX vs SWID

See also: SBOM: The Document Every Open Source Project Needs