Skip to main content
search

SBOM Quality Considerations – OpenChain SBOM Study Group

By 2025-02-20News

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:

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:

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.
Close Menu