Cybersecurity glossary
What is a Software Bill of Materials (SBOM)?
Learn what an SBOM is, what it contains, how SPDX and CycloneDX are used, and how SBOMs differ from SCA, dependency scanning, and VEX.
Definition
A Software Bill of Materials (SBOM) is a structured inventory of software components, dependencies, versions, suppliers, and relationships associated with an application or artifact.
Why SBOMs matter
Modern software is assembled from source code, third-party packages, base images, build tools, generated files, and runtime libraries. When a severe vulnerability appears, teams need to know whether a product contains the affected component before they can decide what to fix or tell customers.
A Software Bill of Materials (SBOM) gives teams and customers a portable record of software ingredients. It does not make software safe by itself, but it shortens the path from "a component is vulnerable" to "these products are affected, unaffected, fixed, or still under investigation."
What an SBOM can capture
Component identity
Names, versions, package URLs, CPEs, suppliers, and other identifiers help tools match components correctly.
Relationships
Dependency links show which components are direct, transitive, bundled, generated, or part of an image.
Artifact context
Metadata ties the SBOM to a release, image, binary, repository, build, or delivered product.
Automation input
Security tools can ingest SBOMs for vulnerability monitoring, license review, and customer reporting.
How SBOMs become useful
Generate from real builds
Create the SBOM from the build output, container image, package graph, or release artifact rather than a stale spreadsheet.
Normalize identifiers
Use consistent package URLs, ecosystems, versions, suppliers, hashes, and relationship fields for reliable matching.
Store with releases
Retain each SBOM beside the artifact or release record so future advisory checks know what shipped.
Analyze continuously
Feed SBOMs into SCA, vulnerability monitoring, license review, and supply-chain risk workflows.
Communicate status
Use vulnerability response and VEX-style status to explain affected, not affected, under-investigation, or fixed states.
Improve accuracy
Compare SBOM output with lockfiles, image scans, runtime evidence, and manual review to close inventory gaps.
SBOM, SCA, dependency scanning, and VEX
| Item | Answers | Does not do |
|---|---|---|
| SBOM | Which components and versions are in this artifact? | Automatically prove exploitability or fix vulnerabilities |
| SCA | Which component risks, licenses, and policies apply? | Replace the inventory record customers may request |
| Dependency scanning | Which package versions match known vulnerability advisories? | Cover every SBOM use case such as supplier disclosure or license inventory |
| VEX | Is this product affected by a specific vulnerability? | List all components in the product |
SBOM readiness checklist
- Generate SBOMs from build artifacts, container images, or resolved dependency graphs.
- Use a standard format such as SPDX or CycloneDX for machine-readable exchange.
- Include direct and transitive dependencies, component versions, identifiers, and relationships.
- Tie each SBOM to a specific release, image digest, binary, or deployable artifact.
- Store SBOMs where vulnerability response, support, and customer-facing teams can retrieve them.
- Continuously rescan retained SBOMs as new advisories are published.
- Use VEX or vulnerability response notes to communicate affected status, not the SBOM alone.
- Review SBOM accuracy by comparing tool output with lockfiles, package managers, and image scans.
The practical takeaway
SBOMs answer an inventory question: what software components are present in this product or artifact? That makes them valuable during audits, customer assurance, and vulnerability response.
Do not confuse inventory with analysis. Use SBOMs alongside SCA, dependency scanning, VEX, and release evidence so component data turns into decisions teams and customers can trust.
Related security terms
Software Composition Analysis (SCA)
Analyzes SBOMs and dependency graphs for vulnerabilities, licenses, and policy risk.
Dependency Scanning
Finds vulnerable packages in manifests, lockfiles, installed graphs, or SBOM inputs.
Software Supply Chain Attack
Inventory helps responders identify exposure when packages or build systems are attacked.
Lockfile
A resolved dependency record that can improve SBOM accuracy for open-source packages.
Secure Software Development Lifecycle (SSDLC)
The lifecycle where SBOM generation, storage, and release evidence are managed.
Frequently asked questions
What is an SBOM in simple terms?
An SBOM is an ingredient list for software. It records the components and versions that make up an application or artifact.
Is an SBOM the same as SCA?
No. An SBOM is inventory data. SCA is analysis that can use inventory data to find vulnerabilities, license issues, component policy violations, and supply-chain risk.
Is an SBOM the same as VEX?
No. An SBOM says what components are present. VEX communicates whether a known vulnerability is exploitable, affected, not affected, or fixed in a specific product context.
What formats are commonly used for SBOMs?
SPDX and CycloneDX are widely used machine-readable SBOM formats. Some ecosystems also produce package manager or vendor-specific inventories.
When should teams generate an SBOM?
Generate SBOMs from the build or release process so they reflect what was actually shipped, then retain them for vulnerability response and customer requests.
Does an SBOM prove software is secure?
No. It improves visibility, but teams still need analysis, vulnerability management, secure builds, provenance, testing, and remediation processes.
What should an SBOM include?
Useful SBOMs include component names, versions, suppliers, identifiers, dependency relationships, hashes where available, generation metadata, and the artifact they describe.
References
Explore authoritative guidance and frameworks related to software bill of materials (sbom).
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.