Software bill of material system oriented to different languages and software bill of material generation method

Abstract

The invention discloses a software bill of material (BOM) system for different languages and a software bill of material (BOM) generation method, the system comprises an SBOM data module and an SBOM operation module, the SBOM operation module comprises an internal operation unit and an external interface unit, the external interface unit extracts component information and dependency relationship information of each component from software projects of different languages and transmits the component information and the dependency relationship information to the SBOM data module, and the SBOM data module generates a software material list of an expected output format in combination with the internal operation unit. SBOM in different formats can be generated by transmitting component information and dependency relationship information extracted from different languages to a software bill of material system oriented to different languages for data integration; the field coverage rate of the generated SBOM is high, it is ensured that the key attribute of each component in the project is recorded, the known vulnerability database is matched more accurately, vulnerability review is conducted, and therefore misinformation and omission are reduced.

Description

Technical Field

[0001] The present invention relates to the technical field of software bill of materials, and in particular to a software bill of materials system and a software bill of materials generation method oriented to different languages. Background Art

[0002] Software systems play a vital role in various industries such as people's livelihood, medical care, and automobiles. Therefore, ensuring a secure and complete software supply chain is becoming increasingly important. For example, attackers often exploit vulnerabilities in software components, leading to catastrophic consequences such as system compromise, data leakage, and economic losses. Therefore, it is particularly urgent to establish a software bill of materials (SBOM) to ensure the integrity, security, and quality of software components throughout the supply chain. The implementation of these SBOMs requires integrated protocols such as code review, vulnerability scanning, and digital signatures, supplemented by effective governance and risk management practices.

[0003] SBOM is a standardized, normalized, machine-readable metadata that provides a comprehensive list of components, dependencies, and libraries used in software development. SBOM can be used to analyze the dependencies of third-party packages in the project, so as to better analyze the vulnerabilities in the project.

[0004] The current SBOM standard formats mainly include CycloneDX, SPDX and SWID. These standards all contain the necessary fields required by SBOM. At the same time, the three formats also have their own SBOM generation tools to support automatic generation. CycloneDX is a lightweight SBOM standard developed by OWASP (Open Web Application Security Project) to improve the transparency and security of the software supply chain. It is expressed in JSON and XML formats. The CycloneDX format was originally created to work with Dependency-Track. Therefore, the current Dependency-Track tool mainly supports parsing SBOMs in CycloneDX format, thereby realizing project composition analysis, vulnerability detection and other functions. SPDX is an open source project led by the Linux Foundation, which aims to standardize the description of software components, licenses and dependencies. SPDX documents can be expressed in multiple formats, including JSON, RDF, XML and YAML. At the same time, SPDX provides a list of common licenses and uniquely numbers the licenses to facilitate the identification of license information in the SBOM. The SWID tag is a standardized XML format defined by the ISO / IEC 19770-2 standard for identifying and managing software assets. The SWID tag is usually embedded in software packages for distribution and thus integrated into the software deployment and installation process.

[0005] In modern software development, projects usually use multiple programming languages, and each language has its own specific build tools and dependency management systems such as Maven, pip, NPM, etc., which increases the complexity of SBOM generation. When generating SBOMs for different languages, a different SBOM generation process is often used for each language. For example, CycloneDX-Python can only support parsing Python projects, and the CycloneDX Maven Plugin tool can only generate SBOMs for Java projects.

[0006] In addition, different organizations, teams, and tool chains have different requirements for the SBOM format. Some projects may follow the SPDX format, while others may prefer CycloneDX or other formats. The need to generate SBOMs in multiple formats makes it difficult for a single generation tool to meet all requirements. For example, build-info-go only supports the output of SBOMs in CycloneDX format, so frequent conversion and adaptation of different SBOM formats are required, which not only increases the workload of development and operation and maintenance, but also easily introduces errors in the conversion process.

[0007] Due to the diversity of project languages ​​and the limitations of generation tools, the generated SBOM often cannot cover all components and dependencies, and incomplete or inaccurate SBOMs will affect the effectiveness of security management and compliance audits. For example, the lack of version information for a component may lead to failure to identify potential security vulnerabilities, thereby increasing security risks; for example, the syft generation tool, although it supports language diversity and can generate SBOMs in multiple formats, the generated SBOM lacks fields that describe the direct and indirect dependencies of the current project and the dependencies between components, and it is also unable to generate dependency graphs when using Dependency-Track for auditing. Summary of the invention

[0008] In view of the problems existing in the prior art, the present invention provides a software bill of materials system and a software bill of materials generation method for different languages, which can be oriented to different languages ​​and generate SBOMs in different formats. The field coverage of the SBOM generated by the present invention is high, ensuring that the key attributes of each component in the project are recorded, and can display more complete dependencies, describe the version and source information of each component in detail, more accurately match the known vulnerability database, and conduct vulnerability review, thereby reducing false positives and omissions.

[0009] To achieve the above technical objectives, the present invention adopts the following technical solutions: a software bill of materials system for different languages, including: an SBOM data module and an SBOM operation module, the SBOM operation module includes: an internal operation unit and an external interface unit, the external interface unit extracts component information and dependency information of each component from software projects in different languages ​​and transmits them to the SBOM data module, the SBOM data module combines with the internal operation unit to generate a software bill of materials in the desired output format.

[0010] Furthermore, the SBOM data module includes: a component list, a dependency list and metadata, the component list contains multiple component information, each component information includes: component name, component version and component unique identifier; the dependency list contains multiple dependency information, each dependency information includes: dependent source component, dependent target component and dependent category; the metadata contains three fields: timestamp, author and SBOM identification tool generated.

[0011] Furthermore, the external interface unit includes: a component information interface, which is used to store component names and component versions extracted from projects in different languages ​​into a component list; the internal operation unit includes: a component unique identifier generation unit and a component integration unit, which generates a unique ID based on the component name and component version stored in the component list, and combines the component name, component version and unique ID into a component unique identifier; the component integration unit integrates all component information into a component list field and displays it in the component list.

[0012] Furthermore, the process of extracting component names and component versions from a Python language project is as follows: in the poetry.lock file in the Python language project, extract the component name and component version recorded in the [package] field; the process of extracting component names and component versions from a Java language project is as follows: in the Java language project, use the Mvn dependency:tree command to generate a dot file recording the project dependency tree in the project directory, and extract the component name and component version in the project dependency tree node.

[0013] Furthermore, the external interface unit also includes: a dependency interface, and the internal operation unit also includes: a dependency integration unit; the dependency interface is used to pass direct dependencies and indirect dependencies extracted from projects in different languages ​​to the dependency integration unit, and the dependency integration unit determines the dependency category based on the fields of direct dependencies and indirect dependencies, and records the dependency category in the dependency information, integrates all dependency information into a dependency list field, and displays it in the dependency list.

[0014] Furthermore, the process of extracting direct dependencies and indirect dependencies from a Python language project is as follows: in the poetry.lock file in the Python language project, if the [package.dependencies] field exists, the extracted components are indirect dependencies of the project; otherwise, the extracted components are direct dependencies of the project; the process of extracting direct dependencies and indirect dependencies from a Java language project is as follows: in a Java language project, use the Mvn dependency:tree command to generate a dot file that records the project dependency tree in the project directory. The project dependency tree records the dependency relationship of the project, where the edge with the project name as the starting point represents the direct dependency of the project, and the other edges represent the indirect dependencies of the project.

[0015] Furthermore, the internal operation unit also includes: a metadata generation unit, which is used to automatically generate a timestamp, record the generation time of the software bill of materials, and generate an author and an SBOM identification tool according to the SBOM scanning tool, and display the timestamp, author and SBOM identification tool in the metadata.

[0016] Furthermore, the external interface unit also includes: an SBOM output format interface, and the internal operation unit also includes: an SBOM format output and conversion unit, the SBOM output format interface is used to pass the SBOM format that the developer expects to output to the SBOM format output and conversion unit, and the SBOM format output and conversion unit selects an SBOM template according to the SBOM format expected by the developer and outputs the generated software bill of materials.

[0017] Furthermore, the SBOM formats that the developer expects to output include: SPDX format, CycloneDX format and SWID format.

[0018] Furthermore, the present invention also provides a method for generating a software bill of materials for the software bill of materials system for different languages, comprising the following steps: Step 1: Extract the component name, component version, direct dependency, and indirect dependency of each component from projects in different languages, and determine the expected output SBOM format; Step 2: Input the extracted component name, component version, direct dependency, indirect dependency and expected output SBOM format into the software bill of materials system, and generate the software bill of materials in the expected output format through the SBOM operation module and the SBOM data module.

[0019] Compared with the prior art, the present invention has the following beneficial effects: The SBOM data module in the software bill of materials system for different languages ​​of the present invention includes a component list, a dependency list and metadata, so that the generated SBOM includes component name, component version, component unique identifier, dependency, author and timestamp of SBOM data, so that the field coverage rate of the generated SBOM is high, ensuring that the key attributes of each software component are recorded, and can show more complete dependency relationships, describe the version and source information of each component in detail, thereby reducing false positives and omissions, and can more accurately match known vulnerability databases for vulnerability review; (2) The dependency list of the present invention includes SBOM files of direct dependencies and indirect dependencies, which can clearly show the dependency chain of the entire project and generate a complete dependency graph. When conducting vulnerability review, vulnerabilities and risks can be efficiently managed. Risks in direct dependencies can be resolved by updating or replacing, and risks in indirect dependencies can be traced back to upstream dependencies for repair. At the same time, the update of indirect dependencies may cause compatibility issues between versions. Clearly marking indirect dependencies can help identify potential risks in advance and avoid destructive upgrade components. (3) The component information and dependency information extracted in different languages ​​are passed to the software bill of materials system of the present invention for different languages ​​for data integration, and SBOMs in different formats can be generated, which greatly improves the versatility. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 It is a schematic diagram of a software bill of materials system for different languages ​​according to the present invention; Figure 2 A schematic diagram of a SBOM data module in the software bill of materials system of the present invention; Figure 3 A schematic diagram of the SBOM operation module of the software bill of materials system of the present invention; Figure 4 A schematic diagram of generating SBOM for a software bill of materials system in different languages ​​according to the present invention. DETAILED DESCRIPTION

[0021] The technical solution of the present invention is further explained below in conjunction with the accompanying drawings.

[0022] like Figure 1 The present invention is a schematic diagram of a software bill of materials system for different languages, the software bill of materials system includes: an SBOM data module and an SBOM operation module, the SBOM operation module includes: an internal operation unit and an external interface unit, the external interface unit extracts component information and dependency information of each component from software projects in different languages ​​and transmits them to the SBOM data module, the SBOM data module generates a software bill of materials in a desired output format in combination with the internal operation unit. The SBOM operation module in the present invention clearly separates the external interface unit from the internal operation unit, the developer only needs to focus on the data docking of the external interface unit, and does not need to focus on the software bill of materials generation process in the internal operation unit and the SBOM data module, thereby simplifying the developer's workflow.

[0023] like Figure 2,The SBOM data module includes: component list, dependency list and metadata. The component list contains multiple component information, each of which includes: component name, component version and component unique identifier; the dependency list contains multiple dependency information, each of which includes: dependent source component, dependent target component and dependent category, dependency category includes direct dependency and indirect dependency, each dependency describes the relationship between a group of components, the dependent target component is the dependent component of the dependent source component, the dependency category expresses the dependency category in the entire project, when the dependent source component is the direct dependency of the entire project, the dependency category is marked as a direct dependency category, when the dependent source component is an indirect dependency of the entire project, the dependency category is marked as an indirect dependency category; the metadata contains three fields: timestamp, author and SBOM identification tool. The SBOM generated by the SBOM data module contains component name, component version, component unique identifier, dependencies, author and timestamp of SBOM data, so that the generated SBOM has a high field coverage rate, ensuring that the key attributes of each software component are recorded, and can display more complete dependencies, describe each component version and source information in detail, thereby reducing false positives and omissions, and can more accurately match known vulnerability databases, conduct vulnerability reviews, and promptly identify potential risks; in addition, when problems occur in the software, the SBOM can help diagnose the problem more quickly.

[0024] like Figure 3, the external interface unit includes: a component information interface, which is used to store the component name and component version extracted from projects in different languages ​​into the component list; the internal operation unit includes: a component unique identifier generation unit and a component integration unit, the component unique identifier generation unit generates a unique ID according to the component name and component version stored in the component list, and combines the component name, component version and unique ID into a component unique identifier, thereby distinguishing different components; the component integration unit integrates all component information into a component list field and displays it in the component list. Developers do not need to pay attention to the internal specific implementation of the data entering the component information interface, and the software bill of materials system of the present invention automatically performs subsequent operations. Specifically, when the process of extracting the component name and component version from a Python language project is: in the poetry.lock file in the Python language project, extract the component name and component version recorded in the [package] field; when the process of extracting the component name and component version from a Java language project is: in the Java language project, use the Mvn dependency:tree command to generate a dot file recording the project dependency tree in the project directory, and extract the component name and component version in the project dependency tree node. The component information extraction strategies for different languages ​​are developed independently, with low coupling in functionality. When the extracted component information of one language is incorrect, it does not affect the extraction of component information in other languages.

[0025] like Figure 3, the external interface unit also includes: dependency interface, and the internal operation unit also includes: dependency integration unit; the dependency interface is used to pass direct dependencies and indirect dependencies extracted from projects in different languages ​​to the dependency integration unit, and the dependency integration unit determines the dependency category based on the fields of direct dependencies and indirect dependencies, and records the dependency category in the dependency information, integrates all dependency information into the dependency list field, and displays it in the dependency list. The dependency interface comprehensively manages direct and indirect dependencies, ensures complete tracking of all related components, helps to more accurately understand the dependency structure of the project, automatically divides dependency categories, reduces the need for manual intervention, and reduces the error rate; the dependency integration unit makes it easy for developers to view and manage the dependencies of the entire project, and plays an important role in the maintenance and update of subsequent projects. Specifically, the process of extracting direct dependencies and indirect dependencies from a Python language project is as follows: in the poetry.lock file in the Python language project, if the [package.dependencies] field exists, the extracted components are indirect dependencies of the project; otherwise, the extracted components are direct dependencies of the project; the process of extracting direct dependencies and indirect dependencies from a Java language project is as follows: in a Java language project, use the Mvn dependency:tree command to generate a dot file that records the project dependency tree in the project directory. The project dependency tree records the dependency relationship of the project, where the edge starting from the project name represents the direct dependency of the project, and the other edges represent the indirect dependencies of the project.

[0026] like Figure 3 The internal operation unit also includes: a metadata generation unit, which is used to automatically generate a timestamp, record the generation time of the software bill of materials, and generate the author and the SBOM identification tool according to the SBOM scanning tool, and display the timestamp, author and SBOM identification tool in the metadata. The timestamp is used to analyze whether the SBOM is within the validity period. The authority of the SBOM with a longer timestamp will be reduced. The name, version, supplier and other information of the SBOM identification tool are used to distinguish the SBOMs generated by different tools and different versions. The integrity of the SBOM field is greatly improved through the metadata generation unit; in addition, metadata information is important data for generating component dependency graphs. If the metadata is missing, the component dependency graph cannot be generated.

[0027] like Figure 3The external interface unit also includes: an SBOM output format interface, and the internal operation unit also includes: an SBOM format output and conversion unit. The SBOM output format interface is used to pass the SBOM format that the developer expects to output to the SBOM format output and conversion unit. When a new SBOM standard appears or an existing standard is updated, only the SBOM output format interface needs to be updated without changing the architecture of the entire software bill of materials system, so that the software bill of materials system of the present invention can quickly adapt to changes in industry standards; the SBOM format output and conversion unit selects an SBOM template according to the SBOM format expected by the developer, and outputs the generated software bill of materials, reducing the workload of the developer's manual adjustment and code writing. Specifically, the SBOM format that the developer expects to output includes: SPDX format, CycloneDX format and SWID format. The software bill of materials system of the present invention can generate SBOMs in multiple standard formats according to user needs, which is convenient for sharing and exchanging SBOM information between different software supply chain management platforms and security analysis tools.

[0028] like Figure 4 The present invention also provides a method for generating a software bill of materials for a software bill of materials system in different languages, comprising the following steps: Step 1: Extract the component name, component version, direct dependency, and indirect dependency of each component from projects in different languages, and determine the expected output SBOM format; Step 2: Input the extracted component name, component version, direct dependency, indirect dependency and expected output SBOM format into the software bill of materials system, and generate the software bill of materials in the expected output format through the SBOM operation module and the SBOM data module.

[0029] Example 1 SBOM generation for Python projects

[0030] The first step is to analyze the way Python projects record components and dependencies, and extract the required components and dependency information. Python projects can be built using poetry, and a poetry.lock file will be generated in the Python project after the build. In the poetry.lock file, the component name and version information will be recorded through the [package] field. By parsing the [package] field in the poetry.lock file, you can get the component information contained in the project. In addition, poetry.lock will record the dependency information of each component in the [package.dependencies] field. By parsing the [package.dependencies] field in the poetry.lock file, you can get the dependency information of the project; The second step is to record the component information, direct dependency information, and indirect dependency information extracted in the first step, and select the SBOM format to be generated, and pass it to the software bill of materials system of the present invention; In the third step, the software bill of materials system will perform component integration, dependency integration, component unique identifier generation and metadata information generation on the transmitted information, and generate an SBOM in the corresponding format according to the desired SBOM format.

[0031] Example 2 SBOM generation for Java projects

[0032] The first step is to analyze how the Java project records components and dependencies, and extract the required component and dependency information. In a Java project managed by Maven, the direct dependencies of the current project are described through pom.xml, and the Mvn dependency:tree command can be used to generate a dot file that records the project dependency tree in the project directory. The nodes in the dependency tree correspond to the component information in the project, including the component name and component version; in addition, the dependency tree also records the project's dependencies, where the edge starting with the project name represents the direct dependency of the project, and the other edges represent the indirect dependencies of the project. By parsing the dependency tree, you can get component information, direct dependency information, and indirect dependency information; The second step is to record the component information, direct dependency information, and indirect dependency information extracted in the first step, and select the SBOM format to be generated, and pass it to the software bill of materials system of the present invention; In the third step, the software bill of materials system will perform component integration, dependency integration, component unique identifier generation and metadata information generation on the transmitted information, and generate an SBOM in the corresponding format according to the desired SBOM format.

[0033] The software bill of materials system and software bill of materials generation method for different languages ​​of the present invention have high scalability. In addition to the SBOM generation method for Python and Java languages, it can also be expanded to other languages. The developer only needs to follow the first step of the software bill of materials generation method to extract the component name, component version, direct dependency and indirect dependency from the project, and determine the expected output SBOM format, and pass it to the software bill of materials system of the present invention to generate the SBOM. There is no need to pay attention to the internal processing process of the software bill of materials system, and the generation of SBOM for other languages ​​can be realized.

[0034] The above are only preferred embodiments of the present invention, and the protection scope of the present invention is not limited to the above embodiments. All technical solutions under the concept of the present invention belong to the protection scope of the present invention. It should be pointed out that for ordinary technicians in this technical field, some improvements and modifications without departing from the principle of the present invention should be regarded as the protection scope of the present invention.

Claims

1. A software bill of materials system for different languages, characterized in that: include: SBOM data module and SBOM operation module, the SBOM operation module includes: an internal operation unit and an external interface unit, the external interface unit extracts component information and dependency information of each component from software projects in different languages ​​and passes them to the SBOM data module, the SBOM data module combines with the internal operation unit to generate a software bill of materials in the expected output format.

2. A software bill of materials system for different languages ​​according to claim 1, characterized in that: The SBOM data module includes: a component list, a dependency list and metadata, wherein the component list contains multiple component information, each of which includes: component name, component version and component unique identifier; the dependency list contains multiple dependency information, each of which includes: dependent source component, dependent target component and dependent category; the metadata contains three fields: timestamp, author and SBOM identification tool.

3. A software bill of materials system for different languages ​​according to claim 2, characterized in that: The external interface unit includes: a component information interface, which is used to store component names and component versions extracted from projects in different languages ​​into a component list; the internal operation unit includes: a component unique identifier generation unit and a component integration unit, the component unique identifier generation unit generates a unique ID based on the component name and component version stored in the component list, and combines the component name, component version and unique ID into a component unique identifier; the component integration unit integrates all component information into a component list field and displays it in the component list.

4. A software bill of materials system for different languages ​​according to claim 3, characterized in that: The process of extracting component names and versions from a Python project is as follows: in the poetry.lock file in the Python project, extract the component names and versions recorded in the [package] field; the process of extracting component names and versions from a Java project is as follows: in a Java project, use the Mvn dependency:tree command to generate a dot file that records the project dependency tree in the project directory, and extract the component names and versions from the project dependency tree nodes.

5. The software bill of materials system for different languages ​​according to claim 3, characterized in that: The external interface unit also includes: a dependency interface, and the internal operation unit also includes: a dependency integration unit; the dependency interface is used to pass direct dependencies and indirect dependencies extracted from projects in different languages ​​to the dependency integration unit, and the dependency integration unit determines the dependency category based on the fields of direct dependencies and indirect dependencies, and records the dependency category in the dependency information, integrates all dependency information into a dependency list field, and displays it in the dependency list.

6. A software bill of materials system for different languages ​​according to claim 5, characterized in that: The process of extracting direct and indirect dependencies from a Python project is as follows: in the poetry.lock file in the Python project, if the [package.dependencies] field exists, the extracted components are indirect dependencies of the project; otherwise, the extracted components are direct dependencies of the project; the process of extracting direct and indirect dependencies from a Java project is as follows: in a Java project, use the Mvn dependency:tree command to generate a dot file that records the project dependency tree in the project directory. The project dependency tree records the project's dependencies, where the edge starting with the project name represents the project's direct dependencies, and the other edges represent the project's indirect dependencies.

7. The software bill of materials system for different languages ​​according to claim 5, characterized in that: The internal operation unit also includes: a metadata generation unit, which is used to automatically generate a timestamp, record the generation time of the software bill of materials, generate an author and generate an SBOM identification tool according to the SBOM scanning tool, and display the timestamp, author and generate SBOM identification tool in the metadata.

8. The software bill of materials system for different languages ​​according to claim 7, characterized in that: The external interface unit also includes: an SBOM output format interface, and the internal operation unit also includes: an SBOM format output and conversion unit. The SBOM output format interface is used to pass the SBOM format that the developer expects to output to the SBOM format output and conversion unit. The SBOM format output and conversion unit selects an SBOM template according to the SBOM format expected by the developer and outputs the generated software bill of materials.

9. A software bill of materials system for different languages ​​according to claim 8, characterized in that: The SBOM formats that the developer expects to output include: SPDX format, CycloneDX format and SWID format.

10. A method for generating a software bill of materials for a software bill of materials system in different languages ​​as claimed in any one of claims 1 to 9, characterized in that: The steps include: Step 1: Extract the component name, component version, direct dependency, and indirect dependency of each component from projects in different languages, and determine the expected output SBOM format; Step 2: Input the extracted component name, component version, direct dependency, indirect dependency and expected output SBOM format into the software bill of materials system, and generate the software bill of materials in the expected output format through the SBOM operation module and the SBOM data module.

Images