What Does an SBOM Look Like, and What Should It Include?

An SBOM is typically generated in a machine-readable format such as CycloneDX or SPDX. These standards organize information about the software components in an application, including their identities, versions, licenses, and relationships.

While the exact fields depend on the format and available data, a typical SBOM includes information such as:

Not every SBOM contains every field, and the level of detail can vary significantly depending on how it was generated.

For a detailed explanation of SBOM generation methods, see 3 SBOM Generation Methods: Binary vs. Build-Time vs. Source Code.

Capturing this data matters for two reasons. First, compliance. The EU Cyber Resilience Act (CRA) began requiring reporting of actively exploited vulnerabilities and severe security incidents in September 2026; its broader requirements, including machine-readable SBOMs covering at least top-level dependencies, take effect in December 2027. In the United States, FDA Section 524B already requires SBOMs in premarket submissions for qualifying cyber devices. CISA’s 2026 SBOM minimum-elements guidance also raises expectations for metadata such as hashes, licenses, and component identifiers, although it does not create legal requirements.

Second, speed. As vulnerabilities are discovered and exploited more quickly with the help of AI, manufacturers need to identify affected products, determine whether vulnerable code was included in a particular build, and prioritize their response. Accurate component information and file-level evidence make that assessment faster and more defensible, especially for embedded products that remain in service for years.

Now, let’s take a look at examples of SBOMs and what they can capture.

SBOM Example 1: File Component Example from a Build-Time SBOM

Source scanning and binary analysis can both provide useful SBOM data, but neither necessarily captures every dependency used in a specific embedded build. For example, when source code is vendored or libraries are statically linked.

A file-level SBOM records information about individual files associated with a software build, rather than relying exclusively on a list of packages.

Here’s an example of the file-level information that RunSafe Identify, RunSafe’s build-time SBOM generator, captured during a build.

Identify captured a source file from libwebp, an image-processing library included within OpenCV’s 3rdparty/ directory.

This is an example of vendored code: third-party software that has been incorporated directly into another project’s source tree.

Notice the file name (predictor_enc.c), the authorship and copyright information, and the file path pointing into opencv/3rdparty/libwebp. These details help establish the source of code that might otherwise appear to be part of the larger OpenCV project.

Why is this significant?

In some development environments, a dependency won’t appear in a traditional package manifest because its source code has been copied directly into the project. A scanner that depends on package declarations may not recognize it as an independent software component.

Build-time SBOM generation takes a different approach. By observing the files involved in compilation and linking, it can preserve information about software dependencies that aren’t explicitly declared through a package manager.

In RunSafe’s example, file-level information helps establish which libwebp source code participated in the build. This provides more specific evidence than simply identifying OpenCV or libwebp at the package level.

That additional detail can be valuable when investigating security vulnerabilities.

SBOM Example 2: Static and Dynamic Libraries

Libraries are another important part of an embedded software inventory.

A dynamically linked library exists as a separately identifiable library artifact, whereas code from a static library can be incorporated into a compiled executable. The latter can be difficult to recognize through inspection of the finished binary alone.

For developers, the important question isn’t simply whether a library exists somewhere in the source repository. It’s whether that library participated in the specific build being examined.

This matters because embedded applications frequently use conditional compilation and different hardware configurations. Two versions of the same product may use different libraries or compile different portions of the same library.

An accurate SBOM should preserve this information so teams can understand what changed between software versions.

How to Generate an SBOM for Embedded Software

The process for generating an SBOM depends on the development environment, the available source code, and the type of software being analyzed.

For a C/C++ project where developers have access to the build process, build-time SBOM generation can provide detailed information about the files and dependencies involved.

For example, RunSafe Identify integrates with existing C/C++ build workflows and records information as the compiler and linker execute. After the build, developers can export a CycloneDX SBOM containing the collected component information.

The general process involves:

1. Select a generation method: Consider whether you have access to source code, build tools, or only compiled artifacts.
2. Generate the SBOM: Integrate the selected tool into the relevant build or analysis workflow.
3. Review the resulting components: Confirm that expected libraries, third-party source files, and component identities are represented.
4. Validate accuracy: Check the inventory against known dependencies and investigate missing or incorrectly identified components.
5. Maintain the SBOM: Generate updated inventories as software changes and retain the relevant records for each release.

For a hands-on example, see RunSafe’s Linux C/C++ SBOM Quick Start, which demonstrates how to generate a CycloneDX SBOM from a C/C++ build.

You can also review How to Validate SBOM Accuracy for Embedded C/C++ Projects for practical guidance on checking component coverage and data quality.

For a comparison of available generators, see The Best SBOM Tools for C/C++ Development. If you’re evaluating tools for your own build, use Questions to Ask When Evaluating SBOM Tools for Embedded C/C++.

How SBOMs Support Better Vulnerability Management

The information in an SBOM becomes particularly useful when a new software vulnerability is disclosed.

Consider the libwebp example we looked at above.

If a vulnerability is discovered in libwebp, a manufacturer needs to determine whether the affected library is present in its products, which versions are involved, and whether the vulnerable code was included in the relevant builds.

A package-level SBOM can help identify products containing the library.

A file-level SBOM provides additional evidence about which source files were used. When a vulnerability can be traced to a specific portion of a component, that evidence can help determine whether the affected code was included in the build.

This doesn’t automatically establish whether every vulnerability is exploitable. Factors such as runtime behavior, reachability, and configuration may require further investigation.

However, more precise component information can help security teams reduce unnecessary investigations and focus on the vulnerabilities most relevant to their products.

This becomes especially important for embedded devices with long product lifecycles, where manufacturers need to investigate newly disclosed software vulnerabilities that may have shipped years earlier.

Learn more about how an accurate inventory supports ongoing vulnerability management in From SBOM to Answer: Cutting Vulnerability Triage Time in Embedded Devices.

Explore More Build-Time SBOM Examples

These examples show why an SBOM needs to capture more than package names. File-level evidence can help teams trace dependencies back to a specific build and investigate vulnerabilities more precisely.

For additional examples and a closer look at how RunSafe captures and uses this information, read the white paper: RunSafe Identify: Build-Time SBOM Generation and Vulnerability Management.

Evaluating SBOM generation for your own build? Get in touch with our team.