Linux Foundation gives automotive suppliers an SBOM rulebook for component handoffs

Why it matters

Automotive SBOMs are useful only when suppliers and automakers can exchange and act on them. OpenChain 1.0 defines a common baseline; broad, consistent use will determine whether it improves that handoff.

Toyota's Masato Endo, who helped establish the OpenChain Automotive Working Group, has spent years trying to make software supply-chain practices work across company lines. On October 7th, the Linux Foundation's OpenChain Project released the group's Automotive SBOM Framework 1.0, a guide for describing and exchanging software inventories across the automotive supply chain. The framework aims to give automakers and suppliers a shared set of expectations for what those inventories contain.

The project grew out of coordination among industry participants. Endo, Toyota's Keisuke Takase and Hitachi Solutions' Ayumi Watanabe began the early discussions, according to the Linux Foundation announcement. Endo founded the Automotive Working Group in 2019; at the time, OpenChain said it had more than 80 participants from automakers and suppliers. In the years since, the work has drawn on feedback from organizations and industry specialists. Endo's day job at Toyota has included intellectual-property work and building open-source governance, a combination that puts him close to the practical problem the framework addresses: companies need to identify software components and communicate that information beyond their own engineering teams.

A shared data model, not a new file format

The framework's main contribution is a common set of data fields. It calls for information such as the SBOM author, timestamp and primary software component, plus component names, versions, suppliers, dependencies and identifiers. Some fields are required; others, including download location and cryptographic hash, are optional under the baseline. The document maps its fields to established formats including SPDX and CycloneDX, rather than requiring suppliers to adopt a new file type or particular software tool.

That focus reflects how automotive software is assembled. A vehicle can include software from multiple suppliers and tiers, and its configuration can change after production through service work or software updates. The framework describes using linked, component-level SBOMs to help trace software through those layers and support maintenance and vulnerability response over a vehicle's lifetime. Those are intended use cases, not evidence that the framework has already improved reliability or security in deployed vehicles.

The project's development shows how Endo's working-group role translated into a concrete specification. In an April 2026 community discussion, Takase and Watanabe presented an update after receiving stakeholder feedback; a June update described revisions to the draft. Those public discussions show a review process underway before the October release, while the final announcement credits a wider group of organizations and experts with shaping the guidance.

OpenChain Project General Manager Mary Meixia Wang described the release as practical guidance for more consistent SBOM practices. Version 1.0 sets a common baseline for exchanging component information. It does not replace SPDX or other underlying standards, and the framework does not prescribe one implementation method. Suppliers can use different systems, provided the resulting information can express the required fields.

Adoption will determine whether the fields travel

A common schema can reduce bespoke requests and manual mapping between organizations, a problem the framework itself identifies. But publishing a schema does not make each supplier's inventory complete, keep it current, or turn it into a vulnerability-management process. NIST guidance treats SBOM data as one input to supply-chain security, to be integrated with vulnerability information and supplier processes. The OpenChain guide gives participants a shared starting point; its value will depend on how consistently automakers and suppliers use it in their actual exchanges.

The framework's uptake will depend on adoption across the industry. The project is open to participation, and its announcement says the framework will evolve with industry feedback and use. There is no customer metric or deployment figure in the release to show how widely version 1.0 is already in operation. Endo's longer-running bet is that shared process can make open-source and software supply-chain work more manageable across an industry where no single automaker controls every component.

The Linux Foundation has hosted other efforts to make software practices interoperable. In August, RuntimeWire covered its acceptance of OPAQUE's TRACE standard for AI runtime evidence, a separate project aimed at making technical evidence portable across organizations. The automotive SBOM framework tackles a more established supply-chain task: agreeing on what information a supplier should hand to an automaker about software inside a vehicle.