What Is an SBOM (Software Bill of Materials)?
A software bill of materials (SBOM) is a complete inventory of the components that make up an application, including open-source packages, their versions, and their dependencies. It exists so teams can answer a basic question fast: what is actually in this software, and is any of it vulnerable? An SBOM is only as useful as it is accurate and current.
What is a software bill of materials?
A software bill of materials is a structured inventory of everything that goes into a piece of software: the open-source and third-party packages it uses, the exact versions, and the transitive dependencies those packages pull in. The name borrows from manufacturing, where a bill of materials lists every part in a product. In software, the parts are components, and most of them are open source that your team did not write.
The purpose is traceability. When a new vulnerability is disclosed in a popular package, the first question is whether you use it and where. Without an inventory, answering that means a scramble across every repository. With an accurate SBOM, it is a lookup.
What an SBOM includes
- Components and versions. Each package and the specific version in use.
- Dependency relationships. Which components pull in which others, including transitive dependencies several layers deep.
- Licenses. The license of each component, for compliance and legal review.
- Supplier and provenance data. Where a component came from, increasingly important for supply-chain trust.
Common formats are SPDX and CycloneDX, which make an SBOM machine-readable and shareable across tools and organizations.
Why SBOMs matter
Modern applications are mostly assembled, not written. A single direct dependency can pull in dozens of transitive ones, so the real attack surface is far larger than the code a team authored. SBOMs became a focus after high-profile supply-chain incidents showed how a compromised or vulnerable component deep in the tree can affect thousands of downstream applications. They are also increasingly expected: regulators and enterprise buyers now ask vendors for an SBOM as a condition of trust.
The limit of a traditional SBOM, and what fixes it
A standard SBOM has a blind spot: it lists what is declared, not what actually runs. A manifest can show dozens of vulnerable packages, most of which are never loaded or executed in production. Acting on the raw list means chasing vulnerabilities that pose no real risk while the genuinely exposed ones sit in the same undifferentiated pile.
Runtime context is what turns an inventory into a priority list. Kodem enriches the SBOM with runtime intelligence to produce a runtime bill of materials (RBOM): the same inventory, annotated with whether each component is actually loaded and whether its vulnerable functions execute. That is the difference between a list of everything you depend on and a short list of what is exposed and worth fixing. See how this works in runtime-powered SCA and reachability analysis, grounded in runtime intelligence.
Frequently Asked Questions
A software bill of materials (SBOM) is a complete inventory of the components in an application, including open-source packages, their versions, dependency relationships, and licenses. It lets teams quickly answer what is in their software and whether any of it is vulnerable.
Components and their exact versions, dependency relationships including transitive dependencies, license information, and supplier or provenance data. Common machine-readable formats are SPDX and CycloneDX.
Modern software is mostly assembled from open-source components, so the real attack surface is larger than the code a team wrote. SBOMs let teams trace exposure when a vulnerability is disclosed, and they are increasingly required by regulators and enterprise buyers.
An SBOM lists the components declared in the software. A runtime bill of materials (RBOM) adds runtime context, showing which components actually load and which vulnerable functions execute, so teams can prioritize what is genuinely exposed.
The two most widely used standards are SPDX and CycloneDX. Both make the SBOM machine-readable so it can be generated, shared, and consumed automatically across tools and organizations.
Related blogs
What is an LLM Jailbreak?
An LLM jailbreak bypasses a model's safety guardrails to produce restricted output. How jailbreaks work, how they differ from prompt injection, and defenses.
4
Stop the waste.
Protect your environment with Kodem.
A Primer on Runtime Intelligence
See how Kodem's cutting-edge sensor technology revolutionizes application monitoring at the kernel level.
Platform Overview Video
Watch our short platform overview video to see how Kodem discovers real security risks in your code at runtime.
The State of the Application Security Workflow
This report aims to equip readers with actionable insights that can help future-proof their security programs. Kodem, the publisher of this report, purpose built a platform that bridges these gaps by unifying shift-left strategies with runtime monitoring and protection.
.avif)
Get real-time insights across the full stack…code, containers, OS, and memory
Watch how Kodem’s runtime security platform detects and blocks attacks before they cause damage. No guesswork. Just precise, automated protection.
