What Is a Software Bill of Materials
A Software Bill of Materials (SBOM) is a machine-readable inventory of every component inside a software application. CISA and NTIA describe it as a “nested inventory” or “list of ingredients” because software components often contain their own dependencies, which contain further dependencies, creating layers of code that most development teams never directly select.
The SBOM captures details about each component: its name, version, supplier, licensing terms, and relationships to other components. For organizations running embedded systems or critical infrastructure, this transparency matters because it enables faster vulnerability identification and clearer compliance documentation.
Think of it like a nutrition label for software. Instead of listing calories and sodium, an SBOM lists every open source package, third-party library, and internally developed module bundled into your final build.
Why Organizations Need SBOMs
Software Supply Chain Visibility
Modern software rarely gets built from scratch. Most applications incorporate dozens or even hundreds of open-source and third-party components. Without an SBOM, teams often lack a clear picture of what’s actually running in production.
This visibility gap creates real risk. When a vulnerability like Log4Shell (CVE-2021-44228) surfaces, organizations without accurate inventories scramble to determine whether they’re affected. Teams with SBOMs can query their inventory and get answers in minutes.
Vulnerability Identification and Response
SBOMs enable teams to match their software inventory against vulnerability databases, like the National Vulnerability Database (NVD). When a new CVE gets published, you can check your SBOM to determine exposure quickly rather than manually auditing codebases.
For embedded systems and critical infrastructure, this speed matters. Devices deployed in the field often can’t be patched quickly, so knowing your exposure early gives you time to plan mitigation.
Regulatory and Compliance Pressure
Federal requirements are driving SBOM adoption across industries. Executive Order 14028, issued in 2021, requires SBOMs for software sold to the U.S. government. The FDA now expects SBOMs as part of premarket cybersecurity submissions for medical devices.
Organizations that build SBOM capabilities now position themselves ahead of expanding mandates.
Open Source License Management
Beyond security, SBOMs capture licensing information for every component. This helps legal and compliance teams track obligations under licenses such as the GPL, Apache, or MIT, avoiding costly licensing disputes down the road.
What Does an SBOM Contain
NTIA’s baseline guidance specifies minimum data fields for a useful SBOM:
- Component name: The identifier for each software package or library
- Version string: The specific release of each component
- Supplier: The entity that created or distributed the component
- Dependency relationship: How components relate, whether direct or transitive
- Unique identifier: Such as CPE or PURL for precise matching against vulnerability databases
- Cryptographic hash: Verification of component integrity
Additional fields like license type, download location, and file checksums add value for compliance and security workflows. The more complete your SBOM, the more useful it becomes for vulnerability management and incident response.
How SBOMs Are Generated
The method you use to generate an SBOM directly affects its accuracy. Different approaches suit different situations, and the tradeoffs matter.
Build-Time SBOM Generation
Generating SBOMs during compilation captures the most accurate picture of what’s included in a build. The build system has direct visibility into every file and library linked into the final artifact.
This approach proves especially valuable for compiled languages like C and C++, where dependency relationships aren’t declared in manifest files. Build-time generation captures components that other methods miss entirely.
Source Code Analysis
Source code scanners examine repositories and manifest files (package.json, requirements.txt, go.mod) to identify declared dependencies. This works well for languages with strong package management ecosystems, such as JavaScript or Python.
However, source analysis only captures what’s declared, not necessarily what’s actually compiled into the final binary.
Binary Analysis
When source code isn’t available, binary analysis tools reverse-engineer compiled executables to identify embedded components. This approach helps with legacy systems or third-party binaries when you don’t have access to the original source code.
The tradeoff: binary analysis typically produces less accurate results than build-time generation, and some components may go undetected.
Package Manager Extraction
Package managers maintain dependency graphs that can be exported as SBOMs. This works well for ecosystems like npm, PyPI, or Maven.
For C/C++ codebases, which are common in embedded systems, package manager coverage remains limited. This makes package manager extraction less reliable for compiled software.
How SBOM Differs from SCA and Traditional BOM
Newcomers often confuse related terms, so here’s how they differ:
- SBOM vs. BOM: A traditional Bill of Materials lists physical parts in manufactured products. An SBOM specifically inventories software components.
- SBOM vs. SCA: Software Composition Analysis (SCA) is a scanning process or tool. An SBOM is the inventory artifact that SCA tools often produce.
- Relationship: SCA tools frequently generate SBOMs, but SBOMs can also be created through build-time instrumentation or binary analysis.
The key distinction is that SCA describes the process, while SBOM describes the output.
SBOM Best Practices for Implementation
1. Automate SBOM Generation in the Build Pipeline
Integrate SBOM creation into CI/CD workflows so every build produces an updated inventory automatically. Manual SBOM generation doesn’t scale and quickly becomes outdated.
2. Validate SBOM Accuracy and Completeness
Establish processes to verify SBOMs capture all components, especially transitive dependencies that tools sometimes miss.
3. Integrate SBOMs with Vulnerability Databases
Connect SBOM data to NVD, OSV, or commercial vulnerability feeds for continuous monitoring. This enables proactive identification of newly disclosed vulnerabilities.
4. Establish SBOM Sharing and Distribution Processes
Define how SBOMs will be delivered to customers, regulators, or internal teams. Standardize on a format (SPDX or CycloneDX) that your stakeholders can consume.
5. Maintain SBOMs Throughout the Product Lifecycle
Update SBOMs with each release and track changes over time for audit and incident response. Version history becomes valuable during security investigations.
How to Build Accurate SBOMs for Embedded Software
Embedded software requires specialized approaches due to C/C++ complexity and extended device lifecycles. Build-time generation provides the most accurate results for compiled code, capturing file-level component data that source scanning and binary analysis miss.
For teams building embedded systems, accurate SBOMs enable better vulnerability management, faster incident response, and smoother compliance workflows. RunSafe Identify provides build-time SBOM generation specifically designed for embedded systems, addressing the accuracy challenges that frustrate many software manufacturers.
Request a consultation to learn more about RunSafe’s approach to SBOM generation.
Frequently Asked Questions
SBOM stands for Software Bill of Materials, a machine-readable inventory listing all components, libraries, and dependencies in a software product.
What is a build-time SBOM?
A build-time SBOM is a Software Bill of Materials generated automatically during the build process that captures the exact components and versions compiled into a specific release. Because it reflects what ships—rather than what’s in source or inferred from a binary scan—it provides a high-fidelity inventory for each build, improving vulnerability management and compliance.
Are SBOMs required by law in the United States?
Executive Order 14028 requires SBOMs for software sold to the federal government. Sector-specific regulations, such as FDA guidance, mandate the creation of SBOMs for medical devices. Requirements continue expanding across industries.
How often should an SBOM be updated?
SBOMs should be regenerated with each software build or release to reflect current components. Organizations often maintain version history for audit and incident response purposes.
Can an SBOM be generated for legacy software without source code?
Yes, binary analysis tools can extract component information from compiled executables. However, results are typically less accurate than build-time generation, so teams often validate binary-derived SBOMs against known dependencies.
What type of SBOM is best for C/C++ code bases?
For C/C++ codebases, a build-time SBOM is generally the best option when you control the build environment. It hooks into the compiler and build system to capture exactly which headers, libraries, and linked components are actually used, producing a high‑fidelity SBOM without relying on a package manager—something C/C++ largely lacks.
When you do not have access to the build (for example, legacy firmware or third‑party binaries), a binary SBOM generated from the compiled artifact is the next best choice, but it is typically less precise than build‑time analysis for C/C++.
