SBOM: What a Software Bill of Materials Contains and How to Use It

An SBOM is a structured inventory of software components and dependencies within a defined scope, typically including versions, identifiers, and license data where available. Teams use it to catch outdated, vulnerable, or non-compliant dependencies before they become a supply chain risk.

SBOM: Key takeaways

• An SBOM lists software components and dependencies within its defined scope, giving security and compliance teams an inventory to check against known vulnerabilities and license requirements.
• CycloneDX and SPDX are the two dominant SBOM formats. CycloneDX originated for security use cases. SPDX started as a license-compliance standard, and SPDX 2.2.1 was standardized as ISO/IEC 5962:2021.
• VEX documents complement an SBOM by stating whether and how a known vulnerability affects a listed component in your specific product, cutting down false-positive alerts.
• Cedalo’s MQTT Platform builds on Eclipse Mosquitto, a widely used and actively maintained open-source project, giving industrial and IoT teams a documented data layer to include in their own SBOM and supply chain security processes.

What is an SBOM?

An SBOM (Software Bill of Materials) lists identifying information for software components within a defined scope, such as name, version, supplier, license, and unique identifiers, plus known dependency relationships between them. That list turns an opaque codebase into a documented inventory you can check against vulnerability databases, license policies, and audit requirements.

What information does an SBOM include?

CISA’s 2025 draft guidance, which updates the NTIA’s 2021 baseline, proposes minimum data fields that a usable SBOM should cover:

• SBOM author and software producer
• Component name and version
• Software identifier, such as a PURL, CPE, or OmniBOR
• Component hash and license
• Dependency relationships and tool name
• Timestamp and generation context

An SBOM missing recommended minimum fields can still list packages, but those gaps may limit how effectively security and audit teams can use it.

Why do software supply chains need an SBOM?

A modern application pulls in dozens or hundreds of open-source and third-party packages, often several layers deep. The Log4Shell vulnerability in 2021 showed how many organizations couldn’t answer a simple question fast enough: which of our products use this library?

Executive Order 14028 pushed SBOM-related guidance into US federal software procurement, and the EU Cyber Resilience Act will generally require in-scope manufacturers to include an SBOM in technical documentation from December 11, 2027.

Figure 1: An SBOM captures every layer of the dependency tree, direct packages, the transitive packages they pull in, and third-party services, in one inventory you can audit.

SBOM tools: which tools and formats should you choose?

Choosing SBOM software comes down to two decisions: which format to generate, and which tool to run inside your build process. CycloneDX and SPDX cover almost every use case, and a handful of open-source generators handle both.

CycloneDX vs. SPDX: what’s the difference?

Both formats can represent the NTIA minimum elements, so whether a specific SBOM meets them depends on the data it contains and what your downstream tooling expects.

Which SBOM generation tools are worth using?

Syft, maintained by Anchore, scans container images and local file systems and outputs either CycloneDX or SPDX. Trivy can combine SBOM generation with vulnerability scanning when the relevant scanners are enabled, which suits teams that want generation and scanning in one step. For a container-heavy pipeline, Syft is a reasonable default because of its dual-format output and low setup effort.

How do you create an SBOM? A step-by-step workflow

SBOM creation usually happens in three steps: generate the inventory from your build artifacts, validate the output against your chosen schema, and store it somewhere your security tooling can reach.

Generate an SBOM with Syft

Install Syft, then point it at a container image or a local directory:

# Install Syft (sudo is required to write into /usr/local/bin)
curl -sSfL https://get.anchore.io/syft | sudo sh -s -- -b /usr/local/bin

# Against a built container image
syft your-image:tag -o cyclonedx-json=sbom.cdx.json

# Against a local project directory
syft dir:. -o spdx-json=sbom.spdx.json

If your build already produces a container image, generating the SBOM from that image can closely reflect what ships, including detected packages added by your base image. This works well alongside a documented Docker setup like the one covered in Docker configuration for Mosquitto.

How do you validate an SBOM before using it?

Run the output through a schema validator, such as cyclonedx-cli validate or the SPDX tools, before you trust it downstream. Check that the dependency tree includes transitive packages, not only the libraries you imported directly, since known vulnerabilities can also appear several layers down. Teams that treat validation as a pipeline gate catch missing or malformed SBOMs before a release ships, rather than during an audit months later.

How do you turn an SBOM into a vulnerability report?

An SBOM can serve as input for a vulnerability report when you match its component list against a vulnerability database. VEX can add product-specific vulnerability status and context. That combination helps identify relevant findings and supports decisions about what to fix first.

What is VEX and how does it reduce alert fatigue?

A VEX (Vulnerability Exploitability eXchange) statement attaches an exploitability status to a component-CVE pair, such as affected, not affected, fixed, or under investigation, depending on the VEX format. A library can carry a published CVE while the vulnerable code path never executes in your build, and VEX lets you document that pairing accordingly instead of leaving it open as an unresolved alert.

What does a practical SBOM vulnerability report look like?

A report structured this way lets a reviewer triage in minutes instead of chasing down every CVE match by hand.

How do you manage SBOMs in your CI/CD pipeline?

SBOM management means treating the SBOM as a build artifact: generate it automatically on every build, store it alongside the release, and check it against new vulnerability data on a recurring schedule.

Where does SBOM generation belong in the pipeline?

Place SBOM generation right after your build and packaging step, before the deployment stage, so it captures the exact artifact you’re about to ship. Store the resulting file alongside your release, either as a pipeline artifact or attached to the release notes, so anyone auditing a specific version can pull the matching SBOM without regenerating it.

How do you keep SBOMs current as dependencies change?

Regenerate the SBOM whenever a dependency version bumps, and diff it against the previous version to flag new or removed components automatically. Beyond that, schedule a recurring re-scan of your stored SBOMs against updated vulnerability feeds, since a component that was safe last month can carry a newly disclosed CVE today even if your code hasn’t changed.

How do you secure software supply chains in MQTT and industrial IoT environments?

Industrial and IoT deployments add a layer most generic SBOM guidance skips: the broker and edge software that move data between machines, gateways, and the cloud need the same component-level visibility as any other production system.

MQTT brokers, gateways, and drivers in OT environments tend to run for years with infrequent patching, which makes their dependency risk easy to lose track of. Securing that layer follows the same pattern as any other service. Generate an SBOM for the broker deployment, pair it with TLS and MQTT authentication settings, and feed the results into the same vulnerability review process you already run for the rest of your stack.

Figure 2: In an MQTT deployment, the broker is the shared hub for live telemetry to Kafka, cloud, and SCADA systems. Separately, at build and deploy time, you generate an SBOM of the broker’s own software so its dependencies get the same component-level visibility as the rest of your stack. The SBOM describes the broker image, not the messages flowing through it.

Turn supply chain visibility into a standard part of your build process

An accurate SBOM turns supply chain risk into a review question instead of a surprise. Generating one with Syft, validating it against CycloneDX or SPDX, and pairing it with VEX data gets you from a component list to a prioritized fix list. Wiring that generation into your CI/CD pipeline keeps the inventory current without adding manual work to every release, and the same discipline extends to the MQTT and edge software connecting your industrial systems.

Your advantages with Cedalo:

• You run on Eclipse Mosquitto, an open-source broker with a large, actively maintained community, so published vulnerabilities can be tracked through public advisories and vulnerability data.
• You connect your broker to Kafka and supported cloud, streaming, database, or industrial systems through documented integrations, so your supply chain visibility doesn’t stop at the broker layer.
• You scale from a single broker to high-availability or high-performance clustering as your deployment grows, without starting your security documentation over from scratch.

SBOM: frequently asked questions

Is an SBOM legally required?

Not universally. Requirements vary by market. Executive Order 14028 established SBOM-related federal guidance, but current US federal requirements are agency- and contract-dependent. Under the EU Cyber Resilience Act, in-scope manufacturers will generally need to include an SBOM in technical documentation from December 11, 2027.

How often should you update an SBOM?

As a best practice, regenerate it on every build so it reflects your current dependency tree. Re-scan existing SBOMs against vulnerability databases on a fixed schedule too, since new CVEs appear for components you haven’t touched in months.

Can an SBOM detect zero-day vulnerabilities?

An SBOM speeds up your response once a zero-day gets disclosed, because you can immediately search your inventory for the affected component and version. Detecting the zero-day itself still requires threat intelligence or vulnerability research separate from the SBOM.

How does an SBOM differ from an SCA report?

An SBOM is a static inventory of components and versions. An SCA (software composition analysis) report adds context on top of that inventory, matching each component against known vulnerabilities and license risks.

Can you generate an SBOM directly from a Docker image?

Yes, Syft and similar tools scan a container image and list the packages they detect, without needing access to the original source repository. Syft scans the final image by default; all layers can be included with the appropriate scope setting.

Does Cedalo provide SBOMs for Mosquitto and the Cedalo MQTT Platform?

Yes. Cedalo provides machine-readable SBOMs in CycloneDX or SPDX format for both Eclipse Mosquitto and the Cedalo MQTT Platform, available on request for a given product version and release.

How does Cedalo support software supply chain security in MQTT-based deployments?

Cedalo documents component versions and security patches across releases of the MQTT Platform, and role-based access controls with audit trails give you a record of changes to your broker configuration. That audit trail complements the SBOM itself when you need to demonstrate compliance.