What Is an SBOM?

An SBOM is a complete inventory of the components, libraries, and dependencies that make up software. Think of it as a software ingredient label that shows exactly what you ship or operate.

What You'll Learn

• Key elements every SBOM should include
• The main SBOM types and when to use each
• How SBOMs help with vulnerability, supply chain, and compliance work

---

1. Overview

SBOMs document what is inside an application or system so you can manage security, licensing, and operational risk. They use standard identifiers (PURL, CPE) and formats such as CycloneDX to stay portable across tools.

2. Core Elements

• Component identity: Name, version, supplier, and standardized identifiers.
• Relationships: Direct and transitive dependencies plus how components connect.
• Licensing: License type, text, and attribution details.
• Security metadata: Known CVEs, hashes, signatures, and provenance.

3. SBOM Types

• Build-time SBOMs capture source dependencies, build tools, and settings during CI/CD.
• Deployed SBOMs reflect what actually runs in production, including runtime packages and OS components.
• Design-time SBOMs document planned components and versions during architecture and planning.

4. Why SBOMs Matter

• Vulnerability management: Map CVEs to the exact components you run and prioritize fixes.
• Supply chain security: Surface hidden or outdated dependencies and high-risk components.
• Operational benefits: Maintain asset inventories, perform impact analysis, and supply audit evidence.

5. Putting SBOMs to Work

• Generate automatically by scanning container images, filesystems, or build artifacts.
• Integrate with CI/CD, registries, security scanners, and asset management systems.
• Act on results by routing SBOMs into vulnerability analysis tools and remediation workflows.