What is an SBOM? Software bill of materials explained
What is an SBOM? A software bill of materials (SBOM) is a machine-readable inventory of every component, library, and dependency inside a piece of software—plus the relationships between them. Think of it as the ingredient label on packaged food: it tells you exactly what is inside, where it came from, and what version you are consuming.
SBOMs moved from a niche engineering artifact to a mainstream compliance requirement after high-profile supply chain incidents (SolarWinds, Log4Shell) showed how little visibility most organizations had into the code they run and ship.
This guide covers:
- A plain-English SBOM definition with an example structure
- The minimum data fields an SBOM typically contains
- Who requires SBOMs today (governments, regulators, enterprise buyers)
- The two dominant formats—SPDX and CycloneDX
- How to produce your first SBOM without slowing engineering down
GIF via GIPHY
Related guides:
Key takeaways
- An SBOM lists every component in your software—direct and transitive dependencies included.
- SPDX and CycloneDX are the two widely adopted machine-readable formats.
- Governments and enterprise buyers increasingly request SBOMs during procurement and vendor security reviews.
- SBOMs are only useful when they are generated automatically per release, not built by hand once a year.
- SecureSlate helps map SBOM practices to SOC 2, ISO 27001, and customer questionnaire evidence.
SBOM definition: the ingredient list for software
An SBOM is a formal, structured record of the components used to build a software product. Modern applications commonly contain hundreds of open source and third-party packages—and each of those packages pulls in its own dependencies. An SBOM makes that entire tree visible in one document.
The concept was popularized by the U.S. National Telecommunications and Information Administration (NTIA), which defined minimum elements every SBOM should include, and later reinforced by Executive Order 14028 on improving the nation's cybersecurity.
What an SBOM contains
| Field | What it captures | Why it matters |
|---|---|---|
| Component name | The package or library identifier | Ties findings to a specific artifact |
| Version | Exact version string | Vulnerability matching depends on it |
| Supplier | Who produced the component | Provenance and trust decisions |
| Unique identifiers | PURL, CPE, or SWID tags | Machine matching against CVE databases |
| Dependency relationships | What includes what | Finds transitive exposure fast |
| License | SPDX license expression | Open source license compliance |
| Timestamp and author | When and how the SBOM was made | Freshness and audit trail |
An SBOM without versions and unique identifiers is a list of names—not a usable security artifact. Auditors and buyers typically check for these fields first.
Why SBOMs matter now
- Incident response speed. When the next Log4Shell drops, teams with SBOMs answer "are we affected?" in minutes instead of days.
- Procurement pressure. Enterprise and government buyers commonly request SBOMs in security questionnaires and contracts.
- Regulatory momentum. U.S. federal procurement, FDA premarket submissions for medical devices, and the EU Cyber Resilience Act all reference SBOMs.
- License risk. SBOMs surface copyleft licenses (GPL, AGPL) before they become an M&A due diligence problem.
SBOM formats: SPDX and CycloneDX
Two formats dominate. Both are machine-readable and supported by mainstream tooling:
- SPDX — an ISO/IEC 5962 standard with roots in license compliance, stewarded by the Linux Foundation.
- CycloneDX — an OWASP standard designed with security use cases (vulnerability correlation, VEX) front of mind.
Most SBOM generation tools export both, so the practical decision is usually driven by what your customers or regulators request. See our full SPDX vs CycloneDX comparison for a decision framework.
Who requires an SBOM
| Requester | Context | Typical expectation |
|---|---|---|
| U.S. federal agencies | Software procurement under EO 14028 | SBOM with NTIA minimum elements |
| FDA | Medical device premarket submissions | SBOM covering commercial and open source components |
| EU regulators | Cyber Resilience Act for products with digital elements | Machine-readable SBOM of top-level dependencies |
| Enterprise buyers | Vendor security reviews and DDQs | SBOM on request, per major release |
| Auditors | SOC 2 / ISO 27001 secure development evidence | SBOM generation as part of SDLC controls |
How to get started
- Pick one product or service and generate an SBOM with an open source tool (Syft, Trivy, or your build ecosystem's plugin).
- Automate it in CI so every release produces a fresh SBOM—manual SBOMs go stale immediately.
- Store SBOMs with your release artifacts so you can answer "what was in version 2.3?" later.
- Assign an owner—typically the platform or security engineering lead.
- Wire SBOM output into vulnerability triage so new CVEs match against real component data.
SBOMs and compliance with SecureSlate
SecureSlate maps secure development practices—including SBOM generation and dependency review—to SOC 2, ISO 27001, and customer questionnaire evidence, so the work engineering already does becomes audit-ready proof.
Get started for free · Free readiness score
FAQ: What is an SBOM
Is an SBOM the same as a dependency list?
Not quite. A dependency manifest (like package.json) lists direct dependencies you asked for. An SBOM captures the entire resolved tree—including transitive dependencies—in a standardized, machine-readable format with identifiers and licenses.
Do SBOMs expose sensitive information?
An SBOM reveals component names and versions, which some vendors treat as sensitive. Many share SBOMs under NDA or through access-controlled portals rather than publishing them publicly.
How often should an SBOM be updated?
Typically per release or per build. An SBOM describes a specific artifact, so a new build means a new SBOM.
Who is responsible for SBOMs in an organization?
Commonly platform engineering or security engineering owns generation, while GRC teams own responding to customer and regulator SBOM requests.
Does SOC 2 require an SBOM?
SOC 2 does not name SBOMs explicitly, but auditors commonly accept SBOM generation as evidence for change management and vulnerability management criteria. See SBOMs and SOC 2.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
No credit card required
