Our February meeting of the Specification and Education Work Groups for North America and Europe covered four major topics:

1. The current status of the freeze period for proposed updates to ISO/IEC 5230 and ISO/IEC 18974
2. Potential future standardization work
3. The recent release of the Capability Model for ISO/IEC 5230
4. Next steps for the Education Work Group

Check out the Meeting Slides:

• https://github.com/OpenChain-Project/Meeting-Minutes/tree/main/Slides/2025

Watch the Recording:

Coming Next:

We will be following up on the activities outlined above on the mailing lists, and we will continue our regular series of calls and meetings throughout the year.

Join Our Work:

Everyone is welcome to be part of the Specification Work Group. You can join their mailing list here:
https://lists.openchainproject.org/g/specification/

You can find and be part of all OpenChain calls through our participation page here:
https://openchainproject.org/participate

OpenChain is looking at the challenge of addressing policy implementation and information fidelity in SBOM. Suppliers provide different SBOM or document formats. Users need to consolidate them.

Example analysis from the Japan SBOM Sub-Group:

The OpenChain Japan SBOM Sub-Group has been conducting an analysis in Japanese. This is one of several discussions around the world, and it has been consolidated into a detailed document:

• https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/subgroups/sbom-sg/meetings/20250203.en.md#proposed-solutions-and-automation-considerations

Mailing List of the global SBOM Study Group:

We are actively considering all aspects of SBOM Quality, and you are invited to be part of this via our global mailing list. Discussions happen here in English:

• https://lists.openchainproject.org/g/sbom

Full Analysis from Japan SBOM Sub-Group:

Shared Issues

1. Lack of Accuracy in SBOM Information
   There is a lack of consistent and accurate information about package details such as package names, versions, and supplier names because different departments or providers use varying formats.
   • Differences in Package Name Notation
     Even for the same component, different vendors or departments might list slightly different names. For example, one company might mix the official name with abbreviations, include spelling mistakes, or vary between uppercase and lowercase letters, making it difficult for the recipient to consistently identify the component in the SBOM.
   • Differences in Version Information Notation
     For the same component, one source might list “1.0.0” while another might use “v1.0” or other formats, resulting in inconsistent version representations that can cause ambiguity.
   • Variations in Supplier Names
     Similarly, supplier names might vary. Official company names, abbreviations, or even outdated names that do not reflect mergers or acquisitions can be present, leading to an overall lack of consistency.
2. Inconsistency of Component Granularity
   When receiving SBOMs from multiple suppliers, one SBOM might provide detailed information at the file level, while another might compile data at the package level. This inconsistency in granularity requires the recipient to normalize the data.
3. Insufficient Source Information When Binaries Are Provided
   When receiving a binary along with its SBOM, detailed information about the source files (such as file listings, hash values, change histories, etc.) is often missing, making it challenging to manage vulnerabilities or assess risks.
   • Listing of Source Files
     A list detailing which source files are included in the component.
   • Hash Values of Source Files
     Hash values (e.g., SHA-256) for each file to prevent tampering and ensure integrity.
   • License Information
     Information about the license and copyright associated with each source file.
   • Patch or Diff Information
     Details on modifications or patches applied to the source code.
   • Build Environment and Configuration Information
     Data regarding the build environment, such as which compilers or build options were used.
   • Dependency Information
     Details about other libraries or components that this source code depends on.
4. Lack of Integration with Vulnerability Information
   There are cases where the component or library information listed in the SBOM is not adequately correlated with known vulnerability information (such as security advisories, CVEs, or PSIRT reports).
   • Lack of Integration between SBOM and Vulnerability Databases
     Since there isn’t a consistent method to automatically link each SBOM entry (e.g., package name, version, supplier details) with subsequently discovered vulnerability information (for example, CVE numbers or vulnerability details), it becomes difficult to pinpoint which vulnerability affects which software component.
   • Inconsistency in Reporting Channels and Contact Points
     When vulnerability information is provided internally (via PSIRT or a security team) or externally, there is often a lack of clarity regarding where in the SBOM this information should be incorporated, or which department should handle it. This can delay communication and hinder prompt responses during vulnerability discovery and mitigation.
5. Mismatch in Information Sharing and Coordination Between Upstream and Downstream
   There is often a disconnect between the SBOM provided by upstream vendors and the information managed by the manufacturer assembling the final product.
   • Use of Different Formats or Standards
     When the SBOM format or the security management standards of each company differ, it becomes challenging to uniformly interpret and reconcile the information, causing the assessment of risk or the need for countermeasures to rely heavily on individual discretion.
   • Disjointed Internal Processes
     If there is no routine process for information updates or feedback between the upstream vendor (providing the SBOM) and the downstream final product manufacturer or security team (handling vulnerability information), it can hinder early detection or impact evaluation of vulnerabilities.
6. Unclear Accountability in Contracts or Internal Processes
   There is an issue over ambiguity regarding how much information should be requested within contractual obligations for SBOM provision, and who should be responsible (e.g., quality control or PSIRT) for addressing inquiries if internal communication processes are insufficient.
7. Diversity in SBOM Formats and Standards
   Currently, multiple formats (SPDX, CycloneDX, JSON, Excel, etc.) exist without unified quality guidelines or evaluation criteria, resulting in variable judgment on the recipient side.
8. Difficulty Ensuring the Trustworthiness of Altered SBOMs
   Sometimes the SBOM generated by a vendor is different from the one generated from an in-house build at the manufacturer. This discrepancy makes it challenging to assess the impact on vulnerability evaluation and risk management.
   • Lack of Transparency in the Modification Process
     When an SBOM is modified through several departments or tools after its initial generation, if the modification history or details are not adequately recorded or disclosed, it becomes difficult to verify whether the final SBOM matches the original source.
   • Risk of Human Error in Manual Modifications
     If the SBOM is manually corrected or supplemented, there is a high risk of input errors or inadvertent modifications, which can lead to divergence from the original, accurate information, compromising reliability.
   • Variability in Automatic Generation Processes
     When multiple automated tools or processes are involved in generating the SBOM, the differences in the output format or content among tools may inadvertently result in loss or alteration of information during integration or editing.
   • Overlooking of Vulnerability Information Due to Modifications
     Altered SBOMs might omit or edit crucial details regarding vulnerabilities or dependency information that should be included, leading to inadequate internal or external security assessments.
9. Lack of Clear Definition for Additional Information Expected in an SBOM
   For example, there is no clear standard definition for the specific items (such as hash values, timestamps, or listings of source files) that should be included in the SBOM. This leads to each company providing different sets of information, further complicating subsequent analysis or vulnerability assessments.
10. Insufficient Update Mechanisms and Contact Points
    When vulnerabilities are discovered, the absence or lack of a centralized contact point (such as a PSIRT department) and an effective communication mechanism regarding the SBOM information can cause delays in information transmission.
    • The checklist includes whether the SBOM is updated, including the display of update timestamps and a clearly indicated inquiry contact point.

Proposed Solutions and Automation Considerations:

1. Lack of Accuracy in SBOM Information
   • Checkpoints
     • The way each component’s package name, version, and supplier details are recorded
     • Consistency in the notation of names and version formats
   • Proposed Solutions (Processes/Mechanisms)
     • Establish naming and versioning rules based on industry standards or internal guidelines
     • Introduce an automated validation system (using regular expressions, etc.) to verify these items during SBOM generation
     • Set up a process for periodic reviews to identify inconsistencies and provide feedback
   • Automation Feasibility
     • Automatable: Checks for naming conventions or version formats can be validated using dedicated scripts or tools.
     • Manual Verification: Ambiguous cases or new exceptions may require human review.
2. Inconsistency of Component Granularity
   • Checkpoints
     • Identification of the granularity used in each SBOM (file level, package level, etc.)
     • Differences in the level of detail provided
   • Proposed Solutions (Processes/Mechanisms)
     • Clarify the “desired granularity” either industry-wide or internally, and adopt a unified format with corresponding guidelines
     • Build a conversion tool (intermediate tool) to normalize and standardize the granularity of the SBOM data received
   • Automation Feasibility
     • Automatable: It is possible to create parsers or conversion scripts that transform various SBOM formats into a unified one.
     • Manual Verification: In cases where the rules are complex, final verification might require human judgment.
3. Insufficient Source Information When Binaries Are Provided
   • Checkpoints
     • Presence of a source file list
     • Availability of hash values for each source file
     • Inclusion of license and copyright information
     • Documentation of patches/differences and change histories
     • Records regarding the build environment, compilers, and build options
     • Dependency information
   • Proposed Solutions (Processes/Mechanisms)
     • Mandate the inclusion of the above details as required fields during SBOM creation
     • Enhance automatic generation tools or adjust settings to include source information in the SBOM
     • Introduce processes that automatically extract and append necessary details from build logs or static analysis tools
   • Automation Feasibility
     • Automatable: It is feasible to integrate build systems with extraction processes to automatically append the required information during SBOM generation.
     • Manual Verification: A final review by humans may be necessary to ensure complete coverage.
4. Lack of Integration with Vulnerability Information
   • Checkpoints
     • The linking of each component’s version information to vulnerability databases (e.g., CVE, security advisories)
     • Documentation of contact points and update histories
   • Proposed Solutions (Processes/Mechanisms)
     • Develop a system that automatically correlates each SBOM entry with vulnerability information from relevant databases (e.g., through integration with vulnerability scanners)
     • Implement regular automated scans and an alerting system that ensures prompt action when vulnerabilities are detected
     • Clearly define and incorporate contact information within the SBOM for unified internal and external communication
   • Automation Feasibility
     • Automatable: Integration with vulnerability scanning tools and automated matching and alert systems can be programmed.
     • Manual Verification: Human oversight may be required to review alerts and determine the applicability of fixes.
5. Mismatch in Information Sharing and Coordination Between Upstream and Downstream
   • Checkpoints
     • Discrepancies between the SBOM provided by vendors and the internally managed SBOM of the final product manufacturer
     • Existence of update histories, difference reports, or integration processes to confirm consistency
   • Proposed Solutions (Processes/Mechanisms)
     • Establish a common repository to aggregate SBOM information from both upstream vendors and downstream manufacturers
     • Introduce regular synchronization processes (for example, periodic cross-check meetings or automated comparison tools for updates)
     • Use format conversion tools based on a unified standard to automatically verify consistency
   • Automation Feasibility
     • Automatable: Tools for comparing differences or integrating information via standardized formats can be implemented for automatic update checks.
     • Manual Verification: Evaluation of particular discrepancies or context-specific information might ultimately require human review.
6. Unclear Accountability in Contracts or Internal Processes
   • Checkpoints
     • Clarity on the scope of SBOM information provided and the designated responsible contact details
     • Documentation of responsibilities as per contractual agreements or internal rules
   • Proposed Solutions (Processes/Mechanisms)
     • Clearly state in contracts or SLAs what information is mandatory and who is responsible for it
     • Establish internal processes for escalation and inquiry handling, with documented contact points and periodic reviews
     • Embed inquiry management and update history functions directly into the SBOM system
   • Automation Feasibility
     • Automatable: For instance, recording contact information and update histories automatically on an SBOM system is achievable through programming.
     • Manual Verification: Contractual and organizational aspects may require document management and human oversight.
7. Diversity in SBOM Formats and Standards
   • Checkpoints
     • Identification of the SBOM output format (e.g., SPDX, CycloneDX, JSON, Excel, etc.)
     • Presence of mandatory fields that should be shared across formats
   • Proposed Solutions (Processes/Mechanisms)
     • Adopt unified rules or conversion tools based on industry standards (such as SPDX or CycloneDX)
     • Build a “format normalization process” to convert each company’s SBOM to a common intermediate format and define clear evaluation criteria
   • Automation Feasibility
     • Automatable: Using conversion tools or format checkers, it is possible to automatically verify compliance with established standards.
     • Manual Verification: Exceptional cases or minor adjustments post-conversion might still require human review.
8. Difficulty Ensuring the Trustworthiness of Altered SBOMs
   • Checkpoints
     • Availability of modification history, version control, or log information
     • Presence of digital signatures, hash values, or verification data to confirm authenticity
   • Proposed Solutions (Processes/Mechanisms)
     • Immediately after SBOM generation, attach a hash or digital signature to the original state so that any post-generation modifications can be detected
     • Implement a modification history management system (using version control, for example) and establish regular audit processes
     • Utilize automatic verification tools (for hash computation and signature verification) that ensure the SBOM’s integrity
   • Automation Feasibility
     • Automatable: Digital signatures and hash verification processes can be entirely automated using software tools.
     • Manual Verification: In some cases, audits or final checks may still require human review.
9. Lack of Clear Definition for Additional Information Expected in an SBOM
   • Checkpoints
     • Whether the SBOM includes the additional required fields (hash values, timestamps, source file list, license information, etc.)
   • Proposed Solutions (Processes/Mechanisms)
     • Develop an industry-wide or internal checklist defining the mandatory metadata that should be included in an SBOM
     • Employ automated generation or static analysis tools to check for the presence of these essential details and trigger alerts if any are missing
     • Hold periodic reviews to evaluate and update the additional required items as needed
   • Automation Feasibility
     • Automatable: It is possible to build an automated validation tool based on a checklist of requirements.
     • Manual Verification: A human review might still be necessary to assess the thoroughness of these guidelines.
10. Insufficient Update Mechanisms and Contact Points
    • Checkpoints
      • Inclusion of update history and the record of the latest update time in the SBOM
      • Presence and clarity of the designated inquiry contact details
    • Proposed Solutions (Processes/Mechanisms)
      • Build a workflow that regularly updates the SBOM information and automatically notifies relevant parties when changes occur
      • Mandate the inclusion of inquiry contact information in the SBOM, and integrate it with a dedicated contact management system (such as a helpdesk or chatbot)
      • Document the inter-department communication rules regarding updates and establish internal audit processes
    • Automation Feasibility
      • Automatable: Update history management, notification systems, and automatic linking to inquiry contacts can be achieved with dedicated tools.
      • Manual Verification: Evaluation of inquiry responses or the appropriateness of updates might ultimately require human oversight.

The OpenChain Project will be delivering a major talk for the open source ecosystem at the LF Member Summit in March. This is a “lessons learned” talk to help everyone understand how to build and deliver open standards to the community.

Talk Abstract:

The OpenChain Project has built two open source process management standards (ISO/IEC 5230 and ISO/IEC 18974) and deployed them across the open source supply chain. While OpenChain was the first Linux Foundation project in 14 years to produce an ISO standard, it is far from the last.During the 2023~2024 period, we saw growing engagement around Joint Development Foundation and committee discussions around standards or specifications in other LF projects.

This talk will consolidate OpenChain’s lessons learned in creating, submitting and deploying open source standards. It will help projects at any stage in the development lifecycle of specifications, including those only just considering this option for long-term impact. It will also help people with a specific interest in a more trusted supply chain to get more involved in OpenChain, building on our existing work or participating in new potential standards.

Our optics will be on the legal, risk and compliance side due to the nature of the OpenChain Project’s mission for a more trusted supply chain, but the core material will be equally applicable to technical, code or other projects working on this topic.

Learn More:

• https://sched.co/1urWe

OpenChain is part of the fabric of quality open source process management. During the Automotive Grade Linux All Member Meeting in Tokyo, we will discuss how our ISO process standards – ISO/IEC 5230 and ISO/IEC 18974 – support technology management activities in Japan and beyond.

“Grab a beverage and food at the AGL Showcase then sit down and learn how AGL and the Linux Foundation can help you gear up your company’s OSPO. Join a special event that will be mostly conducted in Japanese for companies to learn more about OSPO activities within the AGL OSPO Expert Group. This will include presentations from OEM OSPO leaders at Toyota and Honda, OpenChain, and AGL leadership and much more. Afterwards, stick around and talk to AGL developers about what is happening on the project during the AGL Showcase.”

– 17:15-17:25 OSPO Introduction by HONDA
– 17:25-17:35 OSPO Introduction by TOYOTA
– 17:35-17:45 AGL Introduction by Dan Cauchy
– 17:45-17:55 AGL OSPO-EG introduction
– 17:55-18:05 break
– 18:05-18:15 OpenChain Introduction
– 18:15-18:25 OpenChain Japan Introduction
– 18:25-18:35 Civil Infrastructure Project Introduction
– 18:35-18:45 Discussion & QA

Learn More on the AGL Event Page:

• https://aglammspring2025.sched.com/event/1veYl/update-on-open-source-program-office-ospo-activities-in-japan-special-session-for-japanese-attendees?iframe=no&w=100%25&sidebar=yes&bg=no

We held our regular workshop for the OpenChain AI Work Group this week. It was a two-hour session to allow topics related to AI compliance to be discussed, explored and defined. The key focus for the Work Group is to develop and finalize a Guide to AI Bill of Material Compliance in the Supply Chain, and there is active drafting going on during each meeting.

The Draft Guide:

• https://docs.google.com/document/d/1g1kdmx1bDlQ0feSeW-ZY5JRFAF-HC30a/edit

Watch the Recording:

Track This Work:

You can follow and contribute to the work of the OpenChain AI Work Group through its dedicated mailing list. This is open to everyone regardless of industry vertical or speciality. You will find it here:

• https://lists.openchainproject.org/g/ai

Attend Future Meetings:

You can find and get the dial-in details for all future AI Work Group meetings from our participate page here:

• https://www.openchainproject.org/participate

Background

The OpenChain Project provides ISO standards to help ensure open source is professionally managed, and to build increased trust across the open source supply chain. One important aspect of our work is explaining why this is beneficial to different teams in an organization.

What is Happening?

Today, we take a significant step forward to support better understanding of OpenChain open source process management standards by releasing “Explainers” for different teams in organizations. These have been released as CC-0 (effectively public domain) to help companies around the world benefit from adoption best practices for building trusted compliance programs.

These Explainers were developed by Andrew Katz from Orcro, Martin Yagi from First Light Fusion and the rest of the community of contributors who make up the OpenChain Education Work Group.

Get the Explainers

We host the Explainers in our Reference Library in GitHub. You can find them in a dedicated directory called “Education-For-Internal-Teams.”

Access and download them here:
https://github.com/OpenChain-Project/Reference-Material

You can also open GitHub issues with ideas, suggestions and bug-fixes:
https://github.com/OpenChain-Project/Reference-Material/issues

Contribute to Further Development

The Explainers were developed by the OpenChain Education Work Group after initial work through the OpenChain UK Work Group. You can participate in further development by joining the Education Work Group mailing list:
https://lists.openchainproject.org/g/education

You can also join our monthly call by checking out the calendar on our participation page:
https://openchainproject.org/participate

Please Note

This is reference material to help inspire understanding about the value of OpenChain open source process management standards for teams across organizations. It is not designed to be (a) legal advice, (b) assured to work in your context or (c) replace internal or third-party professional support and advice.