SBOM Examples and Key Components

What all goes into an SBOM?. Below are the key components:

• Component name: Each software component is listed by its name. This includes libraries, frameworks, and modules. Example: libssl.so.1.1.
• Version information: The specific version of each component is noted. Example: Version 1.1.1g.
• Supplier Information: Details about the vendor or author of the component. Example: OpenSSL Software Foundation.
• Licensing information: The type of license governing the use of the component. This ensures compliance with legal and regulatory requirements. Example: Apache License 2.0.
• Component hash: A cryptographic hash (e.g., SHA-256) that verifies the integrity of the component. Example: 3c1a84ab7f23cd8c1e8f4564a2e4f45b234a7d8e92b6ec34b8b9d5c6e8f01234.
• Dependency relationships: Information on how components depend on each other. Example: libssl.so.1.1 -> libcrypto.so.1.1.
• Security and vulnerability information: Known vulnerabilities associated with the components. Example: CVE-2020-1971.

An SBOM for an embedded system might include a line like the following examples.

File Component Example from a Build-Time SBOM

In this example, a file-based, build-time SBOM reports on the files that go into the final target, providing detailed provenance information on authors, copyright, and licenses.

Library Component Example from a Build-Time SBOM

This example shows a build-time SBOM capturing both static and dynamic libraries in a build.

Creating an SBOM: Top Security Tools and Best Practices

Before choosing a tool, decide which SBOM format and what level of data your regulators and downstream customers will accept. Most organizations standardize on SPDX or CycloneDX and will want to select a tool that meets all the NTIA SBOM Minimum Elements.

• Syft: A CLI tool for creating SBOMs from container images and filesystems.
• CycloneDX: A lightweight SBOM standard.
• SPDX: An open standard with tools like SPDX-Tools for SBOM creation and validation.
• Black Duck: A comprehensive open-source management tool with SBOM generation features.
• FOSSA: An automated tool for open-source compliance, security, and SBOM generation.
• Endor Labs: Goes beyond traditional SCA tools by not relying solely on package manifests, addressing transitive dependencies effectively.
• RunSafe Security: Generates SBOMs as part of the build process with unique capabilities for C/C++ languages

Best practices for creating effective and comprehensive SBOMs  include the following:

• Integrate automated tools into the CI/CD pipeline for consistent SBOM updates.
• List all software components, including dependencies, versions, licenses, and suppliers.
• Regularly update SBOMs to reflect new components and patches.
• Use cryptographic hashes to verify component integrity.
• Include known vulnerabilities (e.g., CVEs) for proactive security management.
• Ensure license compliance for all components.
• Maintain clear documentation and transparency throughout the supply chain.

The Challenges of Embedded SBOM Generation and Next Steps

Implementing SBOMs in embedded systems comes with many of the same hurdles seen in other software environments—like managing large numbers of third-party components, tracking versions over time, and keeping inventories consistent across development and production. 

However, embedded and OT environments introduce additional complexity due to limited compute resources, long product lifecycles, and development workflows that don’t always align with modern software packaging and automation practices.

One of the biggest challenges is accurately identifying dependencies in embedded C/C++ projects. Unlike ecosystems such as Python or Rust, embedded development often lacks clear package manifests or package managers. Components may be integrated as static libraries, vendor SDKs, or even source code copied directly into a codebase, making it difficult to define “what counts” as a dependency and maintain a reliable component inventory. 

In OT settings, SBOM generation can be further complicated by legacy systems, inconsistent build environments, and cases where source code access is limited or unavailable—leading to incomplete SBOMs and reduced vulnerability visibility.

Practical solutions include:

• Adopt automated SBOM tooling and use recognized formats such as SPDX or CycloneDX
• Integrate SBOM generation into CI/CD pipelines (or build workflows) to keep inventories current
• Use a mix of SBOM generation methods—including source-based, build-time, and binary analysis—based on system constraints and available access
• Standardize dependency tracking practices to reduce ambiguity when “packages” aren’t clearly defined
• Conduct regular audits and validation checks to reduce inaccuracies and improve confidence in results
  
• Train development and security teams on SBOM best practices, including maintaining component metadata and version traceability

Together, these strategies improve dependency transparency, reduce errors in component inventories, and make SBOMs more useful for compliance, vulnerability identification, and long-term risk management in embedded and operational environments.

SBOM Adoption Is Rising

SBOM adoption is expected to increase in the coming years. New software supply chain attacks, government rules, and advances in technology are all working together to improve security and make operations more efficient.

Recent federal SBOM requirements and the Cyber Resilience Act (CRA) in Europe underscore the importance of SBOMs for software security. The rules focus on secure software development. Automation tools and AI will become more important for creating SBOMs, making it easier to find vulnerabilities and predict risks.

In the future, SBOMs will likely use real-time monitoring, machine learning, and big data analytics to improve their integrity and authenticity. As standards and regulations develop, more organizations will adopt SBOMs and use them in DevSecOps, helping teams find vulnerabilities earlier.

SBOMs Turn Embedded Complexity Into Defensible Security

A high-quality SBOM delivers the visibility teams need to identify vulnerable components, respond faster to new CVEs, and reduce uncertainty across long-lived products and complex environments. And while embedded C/C++ development introduces real challenges—limited resources, unclear “package” boundaries, and legacy dependencies—those obstacles aren’t reasons to delay. They’re reasons to build SBOMs the right way: with automation, consistent formats like SPDX or CycloneDX, and SBOM generation integrated into the build process.

The takeaway is simple: you can’t secure what you can’t see. SBOMs provide that visibility, and when implemented effectively, they become a practical, scalable foundation for embedded cybersecurity. 

Ready to go from SBOM examples to looking for SBOM generation solutions? Learn more about RunSafe’s build-time SBOM generator or get in touch with our team.