OpenChain Automotive SBOM Framework 1.0: What It Requires in 2026
| Interlynk
The Linux Foundation's OpenChain Automotive SBOM Framework 1.0 defines a common set of information for automotive supplier handoffs. Here is what the framework requires, what it leaves open, and why accurate generation still matters.
Overview
On October 7, 2026, the Linux Foundation announced version 1.0 of the OpenChain Automotive SBOM Framework at Open Source Summit Europe in Prague. The framework is intended to give automakers and suppliers a shared way to describe and exchange software-component information across the automotive supply chain.
It is not a replacement for SPDX or CycloneDX. Instead, it defines a common set of information and shows how that information can be represented in established SBOM formats.
That distinction matters. An SBOM framework can tell suppliers what information to provide. It cannot, by itself, make that information accurate. The quality of the final inventory still depends on how it is produced and what evidence supports each field.
Framework Scope and Structure
The framework specification groups its work into three areas: data fields, automation support, and practice and process. The data-field section is the most concrete part of version 1.0. It defines a minimum set of information for identifying components, understanding relationships, and supporting later license, vulnerability, and traceability work.
Each field is either Required or Optional. The specification does not create a separate "recommended" category. Required fields are expected in every implementation. Optional fields may be omitted unless a contract, organizational policy, or industry guideline makes them necessary.
The Required Field Set
The required information falls into two broad groups: SBOM-level metadata and component attributes.
At the SBOM level, the framework requires the author name, timestamp, SBOM type, and primary component. The timestamp identifies when the SBOM was created, while the SBOM type describes where the inventory sits in the software lifecycle. The framework uses the six types described in CISA guidance: Design, Source, Build, Analyzed, Deployed, and Runtime.
For each component, the framework requires a name, version, supplier name, relationship, unique identifier, file name, concluded license, copyright notice, and external document references.
The distinction between declared and concluded license is important. A declared license is what the component's author or publisher says applies. A concluded license is the license the SBOM creator believes governs the component after review. They may be the same, but they do not have to be. In version 1.0, the declared license is optional while the concluded license is required.
Download location and cryptographic hash are optional in the framework's field table. When a hash is included, the specification's examples use SHA-256.
The most demanding requirements are not necessarily the most visible ones. A supplier may be able to populate a component name and version easily, but a reliable unique identifier, responsible supplier, and concluded license can require investigation, especially when the software was delivered as a binary, copied into a source tree, or bundled inside an SDK.
Format Neutrality and Standards Alignment
The framework does not mandate one SBOM format or one format version. It says that any format may be used if it can express the required data fields and the organization also follows that format's own specification. Examples listed at publication include SPDX 2.x and 3.x, along with CycloneDX 1.4, 1.5, 1.6, and 1.7.
The specification includes a coverage table for three concrete cases: SPDX Lite as defined in SPDX 2.3, ISO/IEC 5962:2021 (SPDX 2.2.1), and CycloneDX 1.6. ISO/IEC 5962:2021 is the published ISO standard for the SPDX data format.
That table exposes a practical interoperability issue. SPDX Lite does not provide a direct place for several Automotive SBOM requirements, including SBOM type, primary component, component relationship, cryptographic hash, and external document references. A supplier can still use the framework's data model, but SPDX Lite alone will not represent every required field in the table.
For the fields that do map, the specification gives concrete examples. SBOM type is represented through CreatorComment in the SPDX 2.2.1 mapping and through metadata.lifecycles in CycloneDX. The primary component maps to an SPDX DESCRIBES relationship and to metadata.component in CycloneDX. Hashes map to SPDX package checksums and CycloneDX component hashes.
Linked SBOMs and Vehicle Traceability
The automotive model is not a single application built in one repository. A vehicle can contain software from many suppliers and tiers, with components managed on different release schedules. The framework therefore describes a hierarchical model rather than one enormous vehicle-level file.
In that model, SBOMs for individual components can be managed separately and connected through external document references. The specification describes traceability from a vehicle identification number, through the relevant software part number, to the corresponding SBOM. It also notes that the software configuration of a vehicle may change after shipment through reprocessing or over-the-air updates, so the associated SBOM information needs to change as well.
This is more than a file-format preference. It is a way to keep ownership and updates manageable while preserving the links needed for investigation. If a vulnerability is disclosed years after a vehicle ships, the useful question is not simply "what was in the original SBOM?" It is "which software configuration was associated with this vehicle at the time in question?"
The framework provides a structure for that traceability. It does not, by itself, define an OEM's product-lifecycle database, update policy, or vulnerability-response process.
Version 1.0 Boundaries
Version 1.0 deliberately keeps some information outside its core data fields. Dynamic information, such as vulnerability findings, is not part of the SBOM field set. Instead, the SBOM should provide enough identity and relationship information for components to be matched with external vulnerability and license sources. Entity-specific business information, such as vehicle-model details, is also outside the framework and should be handled through separate implementation-specific schemas.
The framework also identifies several items as outside the scope of version 1.0 or normally supplied by the underlying SBOM format. These include the author's signature, the SBOM tool name and version, the SBOM version, and the data-format name and version.
That boundary is reasonable, but it has an operational consequence: conformance to the Automotive SBOM field set is not the same thing as a complete governance or vulnerability-management program. Organizations still need processes for generating SBOMs, exchanging them securely, assessing findings, and recording decisions.
The Generation Problem
The required fields assume that a supplier can identify what went into the software and who is responsible for it. That is straightforward for a clean package from a public registry. It is less straightforward for embedded and automotive firmware.
Firmware builds often combine vendored C or C++ source, static libraries supplied as binaries, and silicon-vendor SDKs. Some components arrive without a manifest, a stable package identifier, or clear license metadata. A file-system scan may find the artifacts, but it may not establish their provenance or the supplier responsible for them.
This is where a conformant SBOM can still be incomplete or misleading. Populating every required field with guesses does not create a trustworthy inventory. The better approach is to connect component records to evidence from the development and build process whenever possible. Build-aware generation can help by observing compiler and linker inputs, including source files, archives, and SDK objects that a manifest-only process may miss.
For Interlynk, this is the role its company describes for lynkctl: generating SBOM data from build activity for embedded and firmware software, then using the Interlynk platform to assess SBOM completeness and quality and monitor changes. Those are product capabilities, not requirements imposed by the OpenChain framework. The broader point is independent of any one tool: the framework defines the information to exchange, while the generator determines whether the supplied information is supported by evidence.
Supplier Starting Points
A supplier evaluating version 1.0 can start with four checks:
Compare its current SBOM output with the framework's Required fields.
Confirm that the chosen document format can express every required field; SPDX Lite may not be sufficient on its own.
Test how the process handles vendored source, binary libraries, SDK content, and components with uncertain licensing or supplier data.
Decide how component-level SBOMs will link to one another and to the product records used for post-shipment traceability.
The goal is not merely to produce a file that passes a schema check. It is to produce component records that another organization can identify, interpret, and connect to the right software configuration.
The Bottom Line
The OpenChain Automotive SBOM Framework 1.0 is useful because it makes a supplier handoff more specific. It defines a shared field set, supports a linked-SBOM model, and stays compatible with established formats instead of creating another proprietary document type.
Its limits are just as important. It does not choose a single format, settle every process question, or supply vulnerability findings. Most importantly, it cannot solve the evidence problem for components that are buried in firmware builds or delivered without useful metadata.
The framework gives the industry a clearer definition of what should be exchanged. The next challenge is making sure that what gets exchanged is accurate.
Sources
About Interlynk. Interlynk provides tools for generating, managing, and operationalizing SBOMs across the software supply chain. Its lynkctl product is positioned for build-aware SBOM generation for embedded and firmware software, while the Interlynk platform supports SBOM and CBOM ingestion, quality evaluation, risk assessment, and change notifications.
This article is informational and does not constitute legal or compliance advice. Framework conformance requirements, regulatory obligations, and industry guidance evolve; confirm current requirements against the primary sources and your own counsel.