What Is a Software Bill of Materials?

Most embedded teams can name the third-party libraries in a current build. Far fewer can produce, on demand, the exact versions that shipped in a release still running in the field. Three jurisdictions now require that record formally, and the software bill of materials (SBOM) is the artifact they expect.

For the systems engineers and quality leads on those programs, the SBOM has become security work and submission evidence at once. What it records, though, is only which version of a library shipped. It does not record which requirement that library satisfies, which hazard it touches, or which test verifies it, and that is what an audit asks for. This guide covers which regulations require an SBOM and when, and how the inventory connects to the requirements and risk records around it.

How Standards Bodies Define a Software Bill of Materials

An SBOM is a formal record of software components and their supply chain relationships in the framing of the National Telecommunications and Information Administration (NTIA) published under Executive Order 14028. In practice it is a machine-readable inventory of what sits inside a piece of software, recording each component’s producer, version and dependencies. The Cybersecurity and Infrastructure Security Agency (CISA) describes an SBOM as a nested inventory of the ingredients in software. A hardware bill of materials (BOM) lists physical parts an engineer selected, while an SBOM records transitive dependencies nobody chose directly. The result is a hierarchical tree in which each component carries its own dependencies.

The 2021 baseline set seven minimum fields per component, according to NTIA. CISA has since replaced it. CISA published the new elements with the National Security Agency, the Federal Bureau of Investigation, and international partner agencies, after a public comment period that drew more than 90 responses. The new baseline covers all software, including open-source software, AI software, and software-as-a-service, and adds ten data fields to the 2021 set. Five of them change what a supplier has to record about each component and how its SBOM was produced:

• Component Hash Value: The entry carries the cryptographic hash of the component.
• Component Hash Algorithm: The entry names the algorithm that produced that hash.
• Component License: The entry lists the license attached to each component.
• SBOM Tool Name: The SBOM identifies the tool that generated its data.
• SBOM Generation Context: The field describes the circumstances under which teams produced the SBOM.

The remaining five, SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Tool Version and SBOM Version, describe the SBOM document rather than the components inside it. The 2026 baseline also renamed fields carried over from the prior baseline. Supplier Name became Component Producer, Version of the Component became Component Version, and Author of SBOM Data became SBOM Author. Four more were renamed and one was folded into another element, so teams migrating legacy SBOMs should work from Appendix B of the guidance. A partial mapping misses four of them.

Which Regulations Require a Software Bill of Materials?

Four instruments bear on SBOMs today. They cover US medical cyber devices under the FD&C Act, products with digital elements under the EU Cyber Resilience Act, road vehicles under UNECE Regulation No. 155, and US federal procurement under Executive Order 14028. They differ in whether they mandate the SBOM directly, specify its submission context, or treat it as supporting cybersecurity-management evidence.

The SBOM sits inside a security risk management report, alongside system threat modeling, the cybersecurity risk assessment, component support information, vulnerability assessments, and unresolved anomaly assessments, under FDA’s February 2026 guidance. The same guidance adds the level of support and end-of-support date for each component. For each known vulnerability the sponsor also owes a safety and security risk assessment and the controls that address it. Those are separate submission elements, not SBOM fields. The level-of-support and end-of-support entries are the ones FDA lets a manufacturer supply in an addendum.

Jama Software® walks through the same obligations and enforcement timeline in its recent CRA webinar and frames the work as embedding cybersecurity into the product lifecycle from day one, so the documentation exists before the submission does. The two US baselines have not converged. FDA’s February 2026 guidance directs sponsors to the 2021 NTIA minimum elements, and CISA replaced those in July 2026 without the guidance catching up. A medical device submission and a CISA-aligned supplier programme therefore work from different field lists, so one SBOM for both needs the union.

The automotive path runs through contracts, and UNECE Regulation No. 155 never uses the word SBOM at all. ISO/SAE 21434:2021, the road vehicle cybersecurity engineering standard, supports component inventories as management system evidence across the supply chain.

Read the BrightInsight Story

SBOM Formats Authorities Accept

Software Package Data Exchange (SPDX) and CycloneDX are the two machine-readable formats most relevant to current SBOM programs. Suppliers should produce either on request, using current format versions and dropping deprecated ones. The CRA itself names no format. It requires the SBOM in a commonly used and machine-readable format covering at least the top-level dependencies, which in practice means SPDX or CycloneDX unless a customer specifies otherwise. Let the recipient decide, whether that is a customer, an FDA reviewer, or a market surveillance authority.

Interoperability depends on an export that preserves component and dependency information. Confirm it retains component producers, versions, dependency relationships, hashes, licenses, the SBOM tool name, and the generation context. A PDF export invites a challenge from market surveillance authorities on machine-readability grounds, so pick the format that a scanner can consume without a conversion step.

How Embedded Teams Generate and Keep an SBOM Current

A build-time SBOM captures the source files, linked libraries and active configuration used for a release. Working from the build also accounts for static linkage and vendored code, and for the conditional compilation post-build tools may miss.

The Yocto Project supports SPDX output during the build. Binary analysis is the fallback for firmware and supplier deliverables that arrive without source. Static linking can erase library boundaries, and heuristic fingerprinting may produce false positives that require manual review.

The same product can yield different SBOMs at the development, build, deployment and runtime stages. Three of the four checks below are named practices in the 2026 CISA guidance, under Frequency, Accommodation of Updates to SBOM Data, and Explicitly Identifying Unknown Information. The fourth is convention.

SBOM content changes with releases while exploitability changes far more often, so govern the two on separate cadences. Common Security Advisory Framework (CSAF) 2.0 can carry VEX information.

Where the SBOM Meets Requirements and Risk Traceability

International Electrotechnical Commission (IEC) 62304, the medical device software life cycle processes standard, and ISO/SAE 21434 impose component-level traceability duties. Automotive SPICE (ASPICE) does as well:

• IEC 62304 (medical device software lifecycle): Software of Unknown Provenance (SOUP) records identify the component and its manufacturer. They also record the version. For higher safety classes, teams connect each SOUP item to the functional and performance requirements it supports and use risk analysis to evaluate its potential contribution to hazardous situations and known anomalies.
• ISO/SAE 21434 (road vehicle cybersecurity engineering): Component monitoring and vulnerability analysis continue across the lifecycle. Teams revisit the Threat Analysis and Risk Assessment (TARA) when new information about an installed component changes attack feasibility or risk.
• ASPICE SUP.10: Change request management requires bidirectional traceability between change requests and the work products they affect. Impact analysis comes before the change proceeds. Teams that treat a component version bump as a change request inherit that traceability obligation.

The weakest link usually sits upstream with suppliers. Supplier SBOMs may arrive inconsistently, carry incomplete component data, or arrive with no contractual requirement behind them at all. Even complete supplier SBOM data can remain isolated in build output and unavailable to change-impact analysis.

Learn About IEC 62304

How Jama Connect Supports Software Bill of Materials Traceability

An SBOM stops being an inventory and starts being evidence at the link between a component and the requirement it satisfies. Holding that link is what Jama Connect®, a web-based requirements management and traceability platform, is for. The Traceability Information Model (TIM) defines which relationships each item type must carry, so a SOUP or third-party component can be modelled with a required link to the requirement it supports, and an item missing that link shows as a missing required relationship. The link provides the per-item requirements record IEC 62304 asks for at Class B and C, while the same model links risk items and verifying test cases. When a linked requirement, risk item or component changes, Jama Connect flags each downstream relationship as suspect until an engineer assesses and clears it, so drift surfaces without a scheduled reconciliation step. Jama Software calls this change-triggered approach Live Traceability™.

Impact analysis before a version change lists the requirements, risk assessments and test cases downstream. Jama Connect risk management covers safety risk aligned to ISO 14971 and cybersecurity risk aligned to ISO/SAE 21434 TARA. Risk items stay linked to the requirements and controls that address them, the pairing FDA’s security risk management report expects. The Jama Connect Interchange™ add-on syncs change requests bidirectionally with the requirements they touch, the ASPICE SUP.10 linkage. SBOM generation stays with the build tools.

Getting the SBOM in Place Before December 2027

The new component-level fields are cheap to write into a supplier agreement now and expensive to reconstruct at submission time. The CRA treats the SBOM as an ongoing product-lifecycle obligation, and the July 2026 CISA elements are the current U.S. baseline for SBOM content even where no procurement clause makes them binding. The CRA’s reporting duties are already live. The December 2027 product obligation is the one still ahead, and an incomplete inventory gets more expensive to correct the closer it gets.

If your SOUP list sits in a spreadsheet three tabs away from the hazard analysis it is supposed to support, that relationship is what Jama Connect holds as a live link instead of a cross-reference you maintain by hand. You can start a free 30-day trial.

Frequently Asked Questions About Software Bill of Materials

Does the FDA require an SBOM for every medical device?

No, it does not. Section 524B of the FD&C Act applies to “cyber devices,” a narrower class than medical device security rules as a whole. A cyber device is one that includes software validated, installed, or authorized by the sponsor, has the ability to connect to the internet, and has technological characteristics that could be vulnerable to cybersecurity threats, all three together. FDA recommends submitting an updated SBOM even for modifications unlikely to affect cybersecurity, and failure to meet the separate cybersecurity design-and-maintenance duty at section 524B(b)(2) is a prohibited act.

What does a VEX document add to a software bill of materials?

A VEX statement tells the recipient whether a vulnerability in a listed component affects the product that contains it and can explain why the product is or is not affected. A justification may show, for example, that the vulnerable code is not in the execute path or that inline mitigations already exist. Consumers also should not assume an upstream component’s status automatically applies to a product that uses it. Specialized security tools generate the VEX, and the resulting statements belong beside the cybersecurity case management records a requirements platform like Jama Connect already holds.

Why do vulnerability scanners produce false positives against an SBOM?

Vulnerability scanners match component identifiers against vulnerability databases, but the identifiers do not always align across those systems. Some identifiers work better for packaged open-source software, while others cover a broader range of products but can produce imprecise matches. Carrying complementary identifiers, then pairing the SBOM with a VEX, filters scanner output before it reaches the risk file, where it would otherwise sit beside the rest of your third-party component risk.

If I want to learn more about a software bill of materials, what else should I read?

For the EU obligations behind the SBOM, watch the Cyber Resilience Act webinar. Preparing for the Cyber Resilience Act covers the design-side changes. Industrial and OT teams should also read what IEC 62443 requires.

This article was authored by Patrick Garman and published on October 9, 2026.