What Is an SBOM? Software Bill of Materials Explained

A software bill of materials, or SBOM, is a formal, machine-readable record of the software components in a product and the dependency relationships between them. It helps an organization answer which libraries, packages, modules, and other components are present in a specific software release.

The idea resembles an ingredient list, but the useful security unit is more exact. An SBOM should identify the component, version, supplier, unique identifier, relationship, author, and creation time with enough precision to support automated queries. It should also stay tied to the specific artifact or release it describes.

The CISA 2025 Minimum Elements for an SBOM states that each new software build or release should receive a new SBOM. It also calls for complete dependency depth, including transitive components. These requirements prevent a top-level package list from being mistaken for a complete product inventory.

Key Takeaways

• An SBOM records component identity and dependency relationships for a specific software version or artifact.
• Useful inventories include direct, transitive, bundled, build-time, and runtime components rather than relying on one manifest.
• SPDX and CycloneDX are common machine-readable formats, and the right choice depends on required data and consuming tools.
• An SBOM speeds vulnerability and supply chain response, but it does not determine whether a component is exploitable or safe.

What an SBOM Contains

The original NTIA minimum elements report defined baseline data fields for component supplier, component name, version, unique identifiers, dependency relationship, SBOM author, and timestamp. It also described automation support and practices for handling SBOM use. CISA’s later guidance expands expectations for depth, versioning, and declared gaps.

Component identity needs more than a display name. A package URL, CPE, namespace, ecosystem, cryptographic digest, or other identifier can distinguish two components with similar names. Multiple identifiers may be necessary because vulnerability databases, package registries, and procurement systems do not use one shared naming scheme.

Relationships describe how components connect. A record can show that an application depends on a library, a package contains a file, or one SBOM describes another artifact. Without relationships, a flat list cannot show whether a vulnerable package belongs to the shipped product, a development tool, or an unrelated scan environment.

The SBOM author and timestamp establish who created the record and when. These fields do not prove accuracy, but they make accountability and freshness visible. A consumer can ask whether the inventory was produced by the supplier, an integrator, or a downstream scanner.

Some components remain unknown. CISA guidance uses the concept of known unknowns for omissions that the producer cannot resolve and supports explicit statements about intentional redaction. Declaring the gap is better than silently presenting an incomplete inventory as complete.

How Teams Generate SBOMs

SBOM generation can happen from source manifests, lock files, build environments, final artifacts, or running systems. Each method sees a different part of the product. A reliable process combines evidence rather than treating one scanner output as definitive.

Source analysis can identify declared packages and dependency resolution before compilation. Lock files usually provide better version detail than a loose manifest. They can still miss copied source, downloaded binaries, operating system packages, generated code, and components introduced by build scripts.

Build-time generation observes the dependency graph while the artifact is assembled. This position can capture resolved versions and connect the SBOM to build provenance. It needs a controlled pipeline because a compromised build step could alter both the artifact and its claimed inventory.

Artifact analysis inspects the container image, executable, archive, firmware, or package that will be shipped. It can find components absent from source records and confirm what survived compilation or bundling. Identification may be uncertain when metadata was stripped or code was statically linked.

Runtime discovery can reveal plugins, sidecars, packages installed during startup, and remote services that do not appear in the release artifact. It is useful for operational inventory, but the result may describe one deployment rather than the product itself. Keep the product SBOM and deployment inventory connected without claiming they are identical.

SPDX and CycloneDX Formats

SPDX is an open standard for communicating software bill of materials information, including components, files, licenses, security data, and relationships. SPDX 2.2 is published as ISO/IEC 5962:2021. SPDX 3 adds a common model with profiles for software, security, licensing, build, datasets, and AI.

CycloneDX is an OWASP standard built around bill of materials use cases. It can describe components, services, dependencies, vulnerabilities, compositions, pedigree, and external references. Its related capabilities include vulnerability disclosure reports, VEX, operations bills of materials, and machine learning bills of materials.

Both formats support JSON and other serializations used by automated systems. They differ in data model, terminology, extensions, and tooling. A team should test whether its generators preserve the required fields and whether its vulnerability, asset, procurement, and response systems can consume the result.

Choosing one format does not settle inventory quality. A syntactically valid document can contain shallow dependencies, ambiguous component names, or stale versions. Define a profile that states mandatory identifiers, relationship depth, hash requirements, license fields, and allowed unknowns.

Conversion between formats may be necessary when suppliers and customers use different standards. Validate converted documents because some properties have no direct equivalent. Preserve the source SBOM and conversion tool version for audit and troubleshooting.

How SBOMs Support Vulnerability Response

When a new vulnerability is disclosed, responders first need to know whether the affected component exists in their products. Querying a maintained SBOM repository is faster than asking every engineering team to search manually. Exact versions and artifact links reduce false matches.

Presence does not equal exposure. The affected code may be unreachable, disabled, excluded during compilation, or protected by another control. The SBOM finds candidate products, while configuration, reachability, exploit evidence, and deployment context determine the response priority.

An inventory can also support proactive monitoring. Organizations can match components against vendor advisories, CVE records, and the CISA Known Exploited Vulnerabilities Catalog. New data should trigger analysis against stored releases rather than a fresh scan that may no longer reproduce the old artifact.

Supply chain incidents require similar queries. If a package publisher, signing key, registry, or build service is compromised, responders can locate products that used the affected component or release path. Digests and provenance references help separate an approved artifact from a malicious replacement with the same name.

For a wider view of dependency risk, see the OWASP Open Source Software Top 10 and the glossary entries for software composition analysis and software supply chain security.

Why an SBOM Is Not a Vulnerability Verdict

An SBOM describes composition. It usually does not state whether a vulnerability affects the way a component is built, configured, or used. Treating every component match as an urgent product vulnerability creates noise and can reduce trust in the inventory program.

Vulnerability Exploitability eXchange, or VEX, carries a supplier or operator statement about whether a known vulnerability affects a product. Common states can indicate that a product is affected, not affected, under investigation, or fixed. The statement should include justification, status time, product identity, and supporting evidence.

VEX does not replace the SBOM. It refers to a product and vulnerability, while the SBOM supplies component context and relationships. A consumer needs both accurate identity and a trustworthy explanation of exploitability.

Neither document guarantees security. Undisclosed vulnerabilities, malicious logic, unsafe configuration, excessive privilege, and deployment errors can exist even when the inventory is complete and every known CVE has a status. SBOMs improve a specific set of decisions rather than serving as a product grade.

SBOM Quality, Completeness, and Maintenance

Quality begins with coverage. Compare source, build, artifact, and runtime views to find missing classes of components. Include transitive dependencies to the greatest available depth and identify where a tool cannot resolve them.

Accuracy requires evidence. Record package manager coordinates, versions, digests, file hashes, supplier data, and the collection method. Mark inferred identities so consumers can distinguish a confident match from a filename-based guess.

Freshness depends on release integration. Generate and store the SBOM as part of every build or release, then bind it to the artifact digest. If a vendor overwrites one inventory for all versions, incident responders lose the historical record they need.

Completeness should be measurable. Track missing version fields, unresolved suppliers, components without unique identifiers, unrepresented relationships, and known unknowns. A percentage alone can hide a critical opaque binary, so review the significance of each gap.

Distribution also needs policy. Some customers may receive full component details, while public documents may omit sensitive internal paths or supplier information. Any redaction should be declared, justified, and linked to a process for authorized access.

A Practical SBOM Adoption Process

Start with one product and one response use case. Define the exact question the SBOM should answer, such as locating affected releases within hours of a critical library disclosure. That goal determines required identifiers, storage, query access, and ownership.

Generate inventories from both the build and the final artifact, then reconcile differences. Test a known transitive dependency, copied library, operating system package, and statically linked component. Document what the selected tools cannot identify.

Store the SBOM beside provenance, artifact digest, release metadata, owner, and deployment references. Restrict write access and keep the original signed or hashed record. Consumers should be able to verify that an inventory belongs to the artifact they received.

Run exercises before an incident. Choose a component from a shipped product, simulate an advisory, query affected releases, confirm deployment exposure, and record the decision. Fix identity and workflow gaps found during the exercise.

Finally, establish supplier requirements that are specific enough to test. Ask for an accepted format, complete dependency depth, stable identifiers, version-specific delivery, known unknowns, update timing, and a contact for corrections. “Provide an SBOM” leaves too much open to interpretation.

Frequently Asked Questions

What does SBOM stand for?

SBOM stands for software bill of materials. It is a machine-readable inventory of software components and their dependency relationships. The record should identify the particular release or artifact it describes.

Is an SBOM required for every software release?

CISA guidance recommends a new SBOM for each new build or release because component versions and relationships can change. Contractual or regulatory requirements vary by jurisdiction, customer, and software category. Producers should map applicable rules and still preserve version-specific inventories for security response.

What is the difference between SPDX and CycloneDX?

SPDX and CycloneDX are open standards that can represent software bills of materials in machine-readable formats. Their models, terminology, profiles, and surrounding tools differ. Teams should compare required fields and downstream compatibility instead of choosing by format name alone.

Does an SBOM show whether software is vulnerable?

An SBOM can show that a component associated with a vulnerability is present. It does not by itself prove that the affected code is reachable, enabled, or exploitable in the product. Configuration analysis, VEX, runtime context, and security testing provide the rest of that decision.