What Is an SBOM (Software Bill of Materials)?

SBOM in Plain English

Think of an SBOM as an ingredient list for your software. Just like a food label tells you what is inside a product, an SBOM tells you what software components are inside your firmware, application, or device.

A modern IoT device might contain hundreds of software components — open source libraries, third-party SDKs, operating system packages, and your own code. An SBOM documents all of them: name, version, supplier, and license.

Why SBOMs Matter for CRA Compliance

The CRA requires manufacturers to maintain SBOMs for two critical reasons:

• -Vulnerability detection — when a new CVE is published, you need to know within hours whether it affects your product. Without an SBOM, you are guessing. With an SBOM, you can match automatically.
• -Supply chain transparency — you need to know which third-party components are in your product, who supplies them, and what their security posture is.

SBOM Formats

Two standard formats are widely used and supported by the CRA:

• -CycloneDX — developed by OWASP, focused on security use cases. Supports vulnerability tracking, license compliance, and component metadata. JSON and XML formats. Versions 1.4, 1.5, and 1.6 are current.
• -SPDX — developed by the Linux Foundation, originally focused on license compliance. Now covers security use cases as well. SPDX 2.3 and 3.0 are both in active use.

Both formats are machine-readable and supported by most SBOM generation tools. The CRA does not mandate a specific format, but it must be "commonly used and machine-readable."

How to Generate an SBOM

SBOMs can be generated at different stages of your development process:

• -Build time — tools like Syft, Trivy, or CycloneDX plugins scan your project dependencies during the build process and output an SBOM file
• -Binary analysis — tools like ONEKEY or Finite State scan compiled firmware binaries to identify components (useful when you don't have source code access)
• -Package manager — most package managers (npm, pip, Maven, Cargo) can export dependency lists that are converted to SBOM format
• -Manual — for embedded systems with custom components, you may need to manually document components that automated tools miss

What an SBOM Contains

A well-structured SBOM includes the following for each component:

• -Component name — the name of the library or package (e.g., openssl, libcurl, busybox)
• -Version — the exact version number (e.g., 3.0.2)
• -Supplier — who maintains or distributes the component (e.g., OpenSSL Foundation)
• -Package URL (PURL) — a standardized identifier for locating the component (e.g., pkg:npm/express@4.18.2)
• -CPE — Common Platform Enumeration identifier used for CVE matching
• -License — the open source license (e.g., MIT, Apache-2.0, GPL-3.0)
• -Component type — library, framework, application, firmware, operating system

SBOM and Vulnerability Matching

The primary operational value of an SBOM is automated vulnerability matching. When a new CVE is published in the National Vulnerability Database (NVD) or other sources, the CVE is matched against your SBOM components using:

• -PURL matching — the most precise method, matches package name and version exactly
• -CPE matching — matches against the Common Platform Enumeration entries in the CVE record
• -Name-version matching — fallback method using component name and version range analysis

Lexoreg performs this matching every 2 hours across all four major vulnerability databases (NVD, OSV, CISA KEV, EUVD), covering over 200,000 known vulnerabilities.

SBOM Lifecycle Management

An SBOM is not a one-time document. Every time you release a firmware update, add a dependency, or patch a component, your SBOM changes. CRA compliance requires you to maintain an up-to-date SBOM throughout the product's supported lifetime.

• -Keep SBOMs versioned alongside your firmware releases
• -Re-generate the SBOM with every significant build
• -Monitor for SBOM staleness — an SBOM that is 30+ days old may miss new vulnerabilities
• -Track SBOM diffs — know what changed between versions

How Lexoreg Handles SBOMs

• -Upload via web, API, or CLI — supports CycloneDX (v1.4, 1.5, 1.6) and SPDX (v2.3)
• -Automatic format detection — upload any supported format and we parse it correctly
• -Component extraction — PURL, CPE, name, version, license, and supplier data extracted automatically
• -Supplier tracking — components are linked to suppliers for supply chain visibility
• -Freshness monitoring — we flag stale SBOMs (7 days current, 14 days stale, 30 days outdated)
• -CVE matching — every component is checked against vulnerability databases every 2 hours