Open source software risk detection method and device based on SBOM list, equipment and medium

Abstract

The invention discloses an open source software risk detection method and device based on an SBOM list, equipment and a medium, and relates to the technical field of software detection. The method comprises the following steps: acquiring an SBOM of target software, and analyzing component information of the SBOM; generating a feature character string according to the component information, and calculating a feature hash value through a hash algorithm; based on a known open source component, analyzing component information and vulnerability information of the component, calculating a feature hash value of the component, and storing the feature hash value to form a feature database; searching a matching item in a feature database based on the feature hash value of the target software component, and if the matching item is found, obtaining a license and vulnerability information of the target software component; if not, marking, manually judging and supplementing the data to the feature database; constructing a license compatibility matrix, and checking the compatibility of the obtained license and the overall license of the project; and comparing the acquired vulnerability information with a feature database, calculating vulnerability severity by combining a CVSS scoring model, and generating a priority repair report. According to the method, the software security detection speed and accuracy are improved.

Description

Technical Field

[0001] The present invention relates to the field of software detection technology, and in particular to an open source software risk detection method, device, equipment and medium based on an SBOM list. Background Art

[0002] With the widespread use of open source software in software development, security and compliance issues within the software supply chain are becoming increasingly prominent. As the core vehicle for documenting software components and their dependencies, the software bill of materials (SBOM) has become a crucial element in open source risk governance. However, due to the lack of unified industry standards, SBOM formats can vary. SBOMs are typically generated at project release and may not be updated with subsequent version updates. Consequently, existing SBOM-based open source risk detection methods still have the following limitations or deficiencies: 1) The component information in the SBOM list may be incomplete, missing key dependencies, version numbers, or license information. This makes it impossible to accurately assess the license and potential risks of each component during vulnerability testing.

[0003] 2) Many open source projects involve different license types. The variety and rules of licenses are vast, and the compatibility rules between them are highly complex. Without a unified view of license information in the BOM and consideration of cross-dependencies, critical compatibility issues may be missed. Related technologies often rely on manual review and simple rule matching. They lack in-depth license compatibility reasoning and comprehensive analysis for complex license compatibility issues and vulnerability risk prediction, making them unable to accurately detect potential software risks. Summary of the Invention

[0004] The present invention provides an open source software risk detection method, device, equipment and medium based on the SBOM list, which solves the problem of insufficient accuracy of software risk detection technology.

[0005] To achieve the above objectives, this application adopts the following technical solutions: In a first aspect, a method for detecting open source software risks based on an SBOM checklist is provided, comprising: Obtaining the SBOM of the target software and parsing the component information therein; wherein the component information includes component name, version, license, vendor, and dependency information; Generate a feature character string according to the component information of each component, and calculate a feature hash value based on the feature character string using a hash algorithm; Based on known open source components, analyze their component information and vulnerability information, calculate their feature hash values, and store the component information, vulnerability information, and hash values ​​to form a feature database; Searching for a matching item in the feature database based on the feature hash value of the target software component; if a matching item is found, obtaining the corresponding license and vulnerability information; if not found, marking it as an unknown component, further manually determining and supplementing the data to the feature database; Construct a license compatibility matrix and check the compatibility between the obtained license and the overall license of the project through logical reasoning algorithms; The acquired vulnerability information is compared with the feature database, and the vulnerability severity is calculated using the CVSS scoring model to generate a priority repair report.

[0006] In a first possible implementation manner of the first aspect, obtaining the SBOM of the target software and parsing component information therein includes: Recursively traverse and extract the direct and indirect dependent components of each component, build a dependency tree, and parse the component dependencies.

[0007] Based on the first possible implementation of the first aspect, in a second possible implementation of the first aspect, before performing the step of parsing the component information, the following steps are performed: Use the validation tool to check the contents of the SBOM and fix missing fields.

[0008] In a third possible implementation of the first aspect, the characteristic string is concatenated in the order of <component name|version|license|supplier|dependency>; and a 64-bit hexadecimal hash value is generated using the SHA-256 algorithm and stored as a database primary key.

[0009] In a fourth possible implementation manner of the first aspect, further manually determining and supplementing data to the feature database includes: Manually collect component information; including name, version, source, and functional description; Based on the collected information, determine the license type used by the component and evaluate its compatibility with the overall project license; If there is a compatibility relationship, query the public vulnerability database to check whether the component has known security vulnerabilities; If vulnerability information exists, its component information, vulnerability information and hash value are added to the feature database.

[0010] In a fifth possible implementation manner of the first aspect, the license compatibility matrix is: The rows and columns of the matrix represent different licenses, and each element Compatibility_Matrix[i][j] in the matrix represents the compatibility between license i and license j.

[0011] Based on the fifth possible implementation manner of the first aspect, in a sixth possible implementation manner of the first aspect, checking the compatibility between the obtained license and the overall project license through a logical reasoning algorithm includes: Determine the type of license to obtain; Based on the determined license type and known open source licenses, determine the compatibility relationship between each license and the overall project license through the terms of each license; Match the obtained license with the license of the entire project. For each pair of component licenses, check the corresponding values ​​in the license compatibility matrix. If Compatibility_Matrix[i][j]= 0, it indicates that there is a license conflict.

[0012] In a second aspect, an open source software risk detection device based on an SBOM list is provided, comprising: A component information parsing module is used to obtain the SBOM of the target software and parse the component information therein; wherein the component information includes component name, version, license, supplier and dependency information; A feature hash value calculation module, configured to generate a feature character string according to the component information of each component, and calculate a feature hash value based on the feature character string using a hash algorithm; A feature database construction module is used to parse component information and vulnerability information of known open source components, calculate their feature hash values, and store the component information, vulnerability information, and hash values ​​to form a feature database; A component matching and database update module is configured to search for a matching item in the feature database based on the feature hash value of the target software component. If a matching item is found, the corresponding license and vulnerability information are obtained. If not found, the component is marked as an unknown component and further supplemented with data to the feature database through manual judgment. A compatibility check module is used to construct a license compatibility matrix and check the compatibility between the obtained license and the overall license of the project through a logical reasoning algorithm; The vulnerability assessment module is used to compare the acquired vulnerability information with the feature database, calculate the vulnerability severity in combination with the CVSS scoring model, and generate a priority repair report.

[0013] In a third aspect, an electronic device is provided, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the steps of the open source software risk detection method based on the SBOM list as described in the first aspect are implemented.

[0014] In a fourth aspect, a readable storage medium is provided, on which a program or instruction is stored. When the program or instruction is executed by a processor, the steps of the open source software risk detection method based on the SBOM list as described in the first aspect are implemented.

[0015] The open source software risk detection method based on the SBOM list of the present invention has the following beneficial effects: This application automatically compares the SBOM list with a feature database containing known vulnerability data and license data, dynamically updates the SBOM list and vulnerability information, builds a license compatibility matrix and combines it with a logical reasoning algorithm to automatically check the compatibility between component licenses and the overall project license, reducing manual intervention and improving the speed and accuracy of security testing; ensuring that the vulnerability and license information of open source components and their dependencies are processed in a timely manner, reducing the risk of lag.

[0016] The present invention and the corresponding device, electronic device and readable storage medium of the open source software risk detection method based on the SBOM list can achieve the same technical effects. To avoid repetition, they will not be described here. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 A schematic flowchart of an open source software risk detection method based on an SBOM list provided in an embodiment of the present application; Figure 2 A schematic diagram of the structure of an open source software risk detection device based on an SBOM list provided in an embodiment of the present application; Figure 3 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0018] To further illustrate the technical means and effects of the present invention to achieve its intended purpose, the technical solutions in the embodiments of this application are clearly described. Obviously, the described embodiments are only part of the embodiments of this application, not all of them. All other embodiments obtained by ordinary technicians in this field based on the embodiments of this application are within the scope of protection of this application.

[0019] The terms "first," "second," and the like in the specification and claims of this application are used to distinguish similar objects, and are not used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate, so that the embodiments of this application can be implemented in an order other than that illustrated or described herein, and that the objects distinguished by "first," "second," and the like are generally of the same type, and do not limit the number of objects; for example, the first object can be one or more. In addition, the term "and / or" in the specification and claims represents at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0020] The description of the method flow in the specification of this application and the steps in the flowcharts in the drawings of the specification of this application do not necessarily need to be strictly executed according to the step numbers. The method steps can be executed in a different order. In addition, some steps can be omitted, multiple steps can be combined into one step, and / or one step can be decomposed into multiple steps.

[0021] The following is a detailed description of the open source software risk detection method, device, equipment and medium based on the SBOM list provided in the embodiments of the present application in combination with the accompanying drawings and preferred embodiments.

[0022] The component information in the SBOM manifest may be incomplete, lacking key dependencies, version numbers, or license information. This makes it impossible to accurately assess the license and potential risks of each component during vulnerability testing. Currently, there is no unified SBOM standard, and the format of the SBOM manifest may vary (for example, CycloneDX, SPDX, etc.). This leads to cross-platform or cross-tool compatibility issues, requiring additional conversion and parsing work. SBOMs are usually generated when a project is released, but may not be modified in time with subsequent version updates. This results in new security vulnerabilities or license changes not being reflected in the SBOM in a timely manner.

[0023] Many open source projects have complex dependencies that may not be clearly listed in the SBOM, resulting in vulnerabilities in certain components not being detected in a timely manner. Different open source software uses different license types, such as GPL, MIT, and Apache, each with different requirements and restrictions. When conducting license compatibility analysis, faced with a large number of license types and rules, both manual analysis and rule-based automated analysis are prone to errors. Some licenses have complex compatibility relationships (for example, the compatibility between the GPL and MIT licenses). Most current tools can only perform basic compatibility checks and lack in-depth license reasoning and comprehensive analysis. Many open source projects are composed of multiple small dependent components, which may use different licenses. Without a unified view of the license information in the SBOM list or consideration of cross-dependencies, critical compatibility issues may be missed.

[0024] Current tools and methods mostly rely on manual review and simple rule matching, and their intelligence level is low for complex license compatibility issues and vulnerability risk prediction. For example, automated analysis of complex license combinations and dependencies based on machine learning or inference algorithms remains relatively weak. As open source components and vulnerability information continue to update, existing methods may not be able to adapt promptly.

[0025] Based on this, this application provides an open source software risk detection method based on the SBOM list, which can deeply integrate multi-source data, dynamically analyze dependency networks and have intelligent reasoning capabilities. It aims to achieve accurate identification of open source software risks, improve the accuracy of software risk detection, and also improve detection efficiency.

[0026] See Figure 1 , the embodiment of the present application provides an open source software risk detection method based on the SBOM list, such as Figure 1 Shown, including: S1, obtain the SBOM of the target software and parse the component information therein; wherein the component information includes component name, version, license, supplier and dependency information.

[0027] Specifically, an appropriate parsing tool is selected according to the SBOM format, the SBOM file is loaded, and each component in the SBOM file is traversed one by one using the parser. The specific information of each component will be extracted into a data structure. For each component, its name, version, license, supplier, dependency and other information are extracted and stored in the database or memory for subsequent analysis and detection.

[0028] Furthermore, step S1 includes: S11, recursively traverse and extract the direct and indirect dependent components of each component, build a dependency tree, and parse the component dependency relationships.

[0029] Parse the dependency relationships of components, extract the SBOM information of each dependent component through recursive traversal, and obtain direct and indirect dependent components by building a dependency tree to fully understand the relationship between each component and other components.

[0030] Furthermore, in some possible implementations, before performing the step of parsing the component information, the following steps are further performed: S12, check the contents of the SBOM and repair missing fields using a verification tool. Use a verification tool to check whether the component information in the SBOM is complete or formatted incorrectly. If the SBOM is incomplete or formatted incorrectly, such as missing fields or inconsistent data, the verification tool can be used to repair or supplement it.

[0031] For example, based on the SBOM format, a parsing tool is selected to analyze the SBOM file. Once the SBOM file is loaded, the tool automatically parses and lists all software components and their information. The following is some key component information extracted from the SBOM. The "dependencies" field in the SBOM lists the other components that each component depends on. In the SBOM parsing tool, each component and its dependencies can usually be viewed through a hierarchical structure or tree diagram. This can be done manually by following the steps below: The parsing tool will display a list of other components that each component depends on. For example, the "openssl" component may depend on "zlib" and "libssl." For each dependent component, you can continue to search for its dependencies. This recursive relationship ensures that all components and their interdependencies are captured. Using the visualization capabilities of the SBOM tool, all components and their dependencies are organized into a "dependency tree." The dependency tree displays the dependencies between components, helping to identify direct and indirect dependencies between components. When manually examining the SBOM file, ensure that the information for each component is complete.

[0032] S2, generating a feature string according to the component information of each component, and calculating a feature hash value based on the feature string through a hash algorithm.

[0033] For each component, its feature information is extracted, the extracted feature information is connected into a string in a certain order, and the generated feature string is hashed to obtain a feature hash value.

[0034] Furthermore, the strings are concatenated in the order of <component name|version|license|vendor|dependency>; and a 64-bit hexadecimal hash value is generated using the SHA-256 algorithm and stored as a database primary key.

[0035] For example, assume that the field value of a component obtained from the SBOM file is as follows: component_name: "openssl" component_version: "1.1.1k" license: "OpenSSL" vendor: "OpenSSL Project" dependencies: ["zlib", "libssl"] To calculate the feature hash value, the key information of the components is concatenated into a string in a specific order. Generally, the format of the feature string is: component_name | component_version | license | vendor | dependencies For the component "openssl" above, the signature string would be: openssl | 1.1.1k | OpenSSL | OpenSSL Project | zlib, libssl Use the SHA-256 hash algorithm to calculate the hash value of the signature string. The SHA-256 algorithm converts the signature string into a 64-character hexadecimal string, ensuring that the signature information of each component can be uniquely identified.

[0036] Generate a signature string: "openssl | 1.1.1k | OpenSSL | OpenSSL Project | zlib, libssl" Apply the SHA-256 hash algorithm to the signature string: SHA-256("openssl | 1.1.1k | OpenSSL | OpenSSL Project | zlib,libssl") = "9d5b9e624db1754f67b2bb5f072dc42a174ec4d84ab4b356b5f3bb44f3bb9b43" The calculated hash value is: "9d5b9e624db1754f67b2bb5f072dc42a174ec4d84ab4b356b5f3bb44f3bb9b43".

[0037] S3, based on known open source components, parses their component information and vulnerability information, calculates their feature hash values, and stores the component information, vulnerability information and hash values ​​to form a feature database.

[0038] This step aims to build a database containing known open source component features. During implementation, you can select a database type based on your needs, such as a relational database or a NoSQL database, and create a data table to store component information. For each component, similar to step S2, extract its feature information. This extracted feature information is concatenated into a string in a specific order. The resulting feature string is hashed to obtain a feature hash value, which is then stored in the database along with the corresponding component information. Since these are known open source components, their vulnerability information is also known.

[0039] Furthermore, in the database, create a table to store SBOM component information. The following is an example of table structure design: Field Name Data Type illustrate component_id INT PRIMARY KEY Unique identifier for the component component_name VARCHAR(255) Component Name component_version VARCHAR(100) Component version license VARCHAR(100) Component License Type vendor VARCHAR(255) Component supplier / developer information dependencies TEXT Component dependencies (can be stored in JSON format or string) feature_hash CHAR(64) Component characteristic hash value (SHA-256 calculation result) created_at TIMESTAMP Record creation time The extracted component information and the calculated feature hash values ​​are stored in the database. Assuming that a MySQL database is used, this information is stored in the components table by inserting SQL statements.

[0040] S4, based on the feature hash value of the target software component, searches for a match in the feature database. If a match is found, the corresponding license and vulnerability information are obtained. If no match is found, it is marked as an unknown component, and further manual judgment is performed and data is added to the feature database.

[0041] In specific implementation, the calculated feature hash value is used to search in the pre-built component feature database. The hash function H maps the input feature string S to a fixed-length hash value: H(S)=hash_value Where H is the SHA-256 hash algorithm; In the hash table, search based on the calculated \text{hash\_value}: component_info=hash_table[H(S)]. If \text{component\_info} exists, it means that the matching component information is found.

[0042] Furthermore, the further manual judgment and supplementation of data to the feature database specifically includes: S41, manually collect information about the component; including but not limited to name, version, source and function description.

[0043] S42, based on the collected information, determine the license type used by the component and evaluate its compatibility with the overall project license; if a compatibility relationship exists, proceed to the next step S43.

[0044] S43, query the public vulnerability database to check whether the component has known security vulnerabilities.

[0045] S44, if there is vulnerability information, then add its component information, vulnerability information and hash value to the feature database.

[0046] For example: suppose there is a component openssl, the license is OpenSSL, the vendor is OpenSSLProject, and the dependencies are zlib and libssl.

[0047] Construct the feature string S: Use the SHA-256 hash algorithm to calculate the hash value H(S) of the string S. The SHA-256 algorithm maps the input string to a fixed-length 256-bit hash value: Suppose you need to find component information: Extract the target component's signature information from the SBOM file and construct it into a string S. Use the SHA-256 hash algorithm to calculate the hash value H(S) of this string. Then use the calculated hash value H(S) as the key to search the hash table. If the corresponding hash value H(S) is not found in the hash table, it means that the component information does not exist in the database. In this case, you can take the following actions: The component is marked as "pending review" or "unknown" for further manual review or data supplementation; based on the component's characteristic information, it is manually determined whether the component is known or needs to be further supplemented to the database.

[0048] S5, build a license compatibility matrix and check the compatibility between the obtained license and the overall license of the project through logical reasoning algorithm.

[0049] Furthermore, the license compatibility matrix is: The rows and columns of the matrix represent different licenses, and each element Compatibility_Matrix[i][j] in the matrix represents the compatibility between license i and license j.

[0050] Specifically, step S5 includes: S51, determining the type of the acquired license.

[0051] In specific implementation, list all open source components used in the project, including direct and indirect dependent libraries, and consult the official documentation, source code repository or metadata in the package manager of each component to determine the type of license it adopts.

[0052] S52, based on the determined license type and known open source licenses, determine the compatibility relationship between each license and the overall project license through the terms of each license.

[0053] This step summarizes all licenses involved in the project, as well as other common open source licenses, and determines the compatibility relationship between them based on the terms of each license.

[0054] S53, matching the obtained license with the license of the entire project, for each pair of component licenses, checking the corresponding value in the license compatibility matrix, if Compatibility_Matrix[i][j] = 0, it indicates that there is a license conflict.

[0055] For example, assume that the following open source components and their licenses are used in the project: Component Name license Component A MIT Component B GPL-3.0 Component C Apache-2.0 Component D BSD Assuming that the overall license of the project is MIT, build a license compatibility matrix. Based on the compatibility of common open source licenses, build the following matrix: MIT GPL-3.0 Apache-2.0 BSD MIT 1 0 1 1 GPL-3.0 0 1 0 0 Apache-2.0 1 0 1 1 BSD 1 0 1 1 The license of ComponentA is MIT. Search Compatibility_Matrix[MIT][MIT] and the corresponding value is 1, which indicates compatibility. The license of ComponentB is GPL-3.0. Search Compatibility_Matrix[MIT][GPL-3.0] and the corresponding value is 0, which means it is incompatible. The ComponentC project license is Apache-2.0. Search for Compatibility_Matrix[MIT][Apache-2.0] and the corresponding value is 1, indicating compatibility. The license of Component D is BSD. Search for Compatibility_Matrix[MIT][BSD] and the corresponding value is 1, indicating compatibility. Then component B is incompatible with the overall project license MIT, and there is a license conflict; Generates a report indicating that the license of Component B conflicts with the overall project license.

[0056] Furthermore, for components that are incompatible with the overall project license, the signature database is used to match functionally equivalent, license-compatible replacements. For example, components licensed under MIT, Apache 2.0, or BSD can be used to replace existing GPL-3.0 components. GPL-3.0 components are isolated from the main project logic, interacting with them through inter-process communication or network interfaces.

[0057] In some possible implementations, if there are a large number of incompatible components, the project's overall license type may be changed to one that is compatible with the licenses of the incompatible components. For example, if a project uses a large number of GPL-3.0 components, consider changing the project's overall license to GPL-3.0 to ensure license consistency. S6, compares the obtained vulnerability information with the feature database, calculates the vulnerability severity based on the CVSS scoring model, and generates a priority repair report.

[0058] Specifically, each identified vulnerability is scored using CVSS to assess its severity. The CVSS score ranges from 0.0 to 10.0, with higher scores indicating higher severity of the vulnerability.

[0059] The CVSS score consists of a base score, a temporal score, and an environmental score. The base score considers the inherent characteristics of the vulnerability, including attack vectors, attack complexity, permission requirements, user interaction, and impact. The base score is calculated as follows: The calculation of Exploitability and Impact involves the specific values ​​and weights of the above indicators; Based on the comparison and scoring results, a report containing vulnerability information and severity of each component is generated. Based on the CVSS score, vulnerabilities with high open source software risk detection scores based on the SBOM list are repaired first.

[0060] For example, the exploitability and impact scores of a vulnerability are calculated according to the formula and weight table provided by CVSS: Exploitability Rating: Attack vector (AV) = network (N) = 0.85 Attack Complexity (AC) = Low (L) = 0.77 Permission Requirement (PR) = None (N) = 0.85 User interaction (UI) = None (N) = 0.85 Exploitability=8.22×0.85=6.98; Impact Rating: Confidentiality impact (C) = High (H) = 0.56 Integrity impact (I) = High (H) = 0.56 Availability impact (A) = Medium (M) = 0.275 Impact=0.56×0.56×0.275=0.087; The final basic score is: Base Score=Round(Min(6.98,0.087)×10)=6.98; Create a vulnerability information report for each component based on the CVSS score and indicate the severity of each vulnerability: Component Name Vulnerability Description CVE Number CVSS Base Score Severity Impact Category Component A SQL injection vulnerabilities allow attackers to execute malicious SQL queries CVE-2022-1234 6.98 medium Information leakage and data tampering Component B Buffer overflow vulnerability that could lead to remote code execution CVE-2022-5678 9.8 high Full control, data tampering Component A: CVSS base score is 6.98, severity is medium, and requires timely repair; Component B: The CVSS base score is 9.8, the severity is high, and the repair priority is given.

[0061] Sort the vulnerabilities by CVSS base score from high to low, processing high-risk vulnerabilities first (i.e., CVSS base scores greater than 7), followed by medium-risk vulnerabilities, and finally low-risk vulnerabilities.

[0062] Based on the above technical solution, this application automatically compares the SBOM list with a feature database containing known vulnerability data and license data, dynamically updates the SBOM list and vulnerability information, builds a license compatibility matrix and combines it with a logical reasoning algorithm to automatically check the compatibility between component licenses and the overall project license, reducing manual intervention and improving the speed and accuracy of security testing; ensuring that the vulnerabilities and license information of open source components and their dependencies are processed in a timely manner, reducing the risk of lag.

[0063] See also Figure 2 Corresponding to the above-mentioned embodiment of the open source software risk detection method based on the SBOM list, the embodiment of the present application provides an open source software risk detection device based on the SBOM list, including: The component information parsing module 1001 is used to obtain the SBOM of the target software and parse the component information therein; wherein the component information includes component name, version, license, supplier and dependency information; A feature hash value calculation module 1002 is configured to generate a feature character string according to the component information of each component, and calculate a feature hash value based on the feature character string using a hash algorithm; A feature database construction module 1003 is used to parse component information and vulnerability information of known open source components, calculate feature hash values, and store the component information, vulnerability information, and hash values ​​to form a feature database. Component matching and database update module 1004 is used to search for a matching item in the feature database based on the feature hash value of the target software component. If a matching item is found, the corresponding license and vulnerability information are obtained. If not found, the component is marked as an unknown component and further supplemented with data to the feature database through manual judgment. A compatibility check module 1005 is used to construct a license compatibility matrix and check the compatibility between the obtained license and the overall project license through a logical reasoning algorithm; The vulnerability assessment module 1006 is used to compare the acquired vulnerability information with the feature database, calculate the vulnerability severity in combination with the CVSS scoring model, and generate a priority repair report.

[0064] The above-mentioned open source software risk detection device based on the SBOM list implements the steps and various processes of the above-mentioned open source software risk detection method based on the SBOM list, and can achieve the same technical effect. To avoid repetition, they will not be repeated here.

[0065] See also Figure 3 Corresponding to the above-mentioned embodiment of the open source software risk detection method based on the SBOM list, an embodiment of the present application provides an electronic device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the steps and various processes of the above-mentioned embodiment of the open source software risk detection method based on the SBOM list are implemented, and the same technical effects can be achieved. To avoid repetition, they are not described here.

[0066] The memory 1009 can be used to store software programs and various data. The memory 1009 may mainly include a first storage area for storing programs or instructions and a second storage area for storing data, wherein the first storage area may store an operating system, applications or instructions required for at least one function (such as a sound playback function, an image playback function, etc.). In addition, the memory 1009 may include a volatile memory or a non-volatile memory, or the memory 1009 may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may be a random access memory (RAM), a static random access memory (SRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDRSDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a synchronous link dynamic random access memory (SLDRAM), and a direct memory bus random access memory (DRRAM). The memory 1009 in the embodiment of the present application includes but is not limited to these and any other suitable types of memory.

[0067] Processor 1010 may include one or more processing units. Optionally, processor 1010 integrates an application processor and a modem processor. The application processor primarily handles operations related to the operating system, user interface, and application programs, while the modem processor primarily processes wireless communication signals, such as a baseband processor. It is understood that the modem processor may not be integrated into processor 1010.

[0068] Corresponding to the above-mentioned embodiment of the open source software risk detection method based on the SBOM list, the embodiment of the present application also provides a readable storage medium, on which a program or instruction is stored. When the program or instruction is executed by the processor, the steps and various processes of the above-mentioned embodiment of the open source software risk detection method based on the SBOM list are implemented, and the same technical effect can be achieved. To avoid repetition, it will not be repeated here.

[0069] The processor is the processor in the electronic device described in the embodiment of the present application. The readable storage medium includes a computer-readable storage medium, such as a computer read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0070] It should be noted that, in this article, the terms "comprise", "include" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, an element defined by the statement "comprises a ..." does not exclude the presence of other identical elements in the process, method, article or device comprising the element. In addition, it should be noted that the scope of the methods and devices in the embodiments of the present application is not limited to performing functions in the order shown or discussed, and may also include performing functions in a substantially simultaneous manner or in the opposite order according to the functions involved. For example, the described method may be performed in an order different from that described, and various steps may also be added, omitted, or combined. In addition, the features described with reference to certain examples may be combined in other examples.

[0071] Through the description of the above implementation methods, those skilled in the art can clearly understand that the above-mentioned embodiment methods can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art can be embodied in the form of a computer software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), including a number of instructions for enabling a terminal (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.

[0072] It will be appreciated that the embodiments of the present application have been described above in conjunction with the accompanying drawings, but the present application is not limited to the above-mentioned specific embodiments, which are merely illustrative and not restrictive, and those skilled in the art will appreciate that various changes or equivalent replacements may be made to these features and embodiments without departing from the spirit and scope of the present invention. In addition, those of ordinary skill in the art may modify these features and embodiments to adapt to specific circumstances and materials under the inspiration or guidance of this application without departing from the spirit and scope of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed herein, and all embodiments falling within the scope of the claims of this application fall within the scope protected by the present invention.

Claims

1. The open source software risk detection method based on the SBOM list is characterized by: include: Obtaining the SBOM of the target software and parsing the component information therein; wherein the component information includes component name, version, license, vendor, and dependency information; Generate a feature character string according to the component information of each component, and calculate a feature hash value based on the feature character string using a hash algorithm; Based on known open source components, analyze their component information and vulnerability information, calculate their feature hash values, and store the component information, vulnerability information, and hash values ​​to form a feature database; Searching for a matching item in the feature database based on the feature hash value of the target software component; if a matching item is found, obtaining the corresponding license and vulnerability information; if not found, marking it as an unknown component, further manually determining and supplementing the data to the feature database; Construct a license compatibility matrix and check the compatibility between the obtained license and the overall license of the project through logical reasoning algorithms; The acquired vulnerability information is compared with the feature database, and the vulnerability severity is calculated using the CVSS scoring model to generate a priority repair report.

2. The open source software risk detection method based on the SBOM list according to claim 1 is characterized in that: The step of obtaining the SBOM of the target software and parsing the component information therein includes: Recursively traverse and extract the direct and indirect dependent components of each component, build a dependency tree, and parse the component dependencies.

3. The open source software risk detection method based on the SBOM list according to claim 2 is characterized in that: Before performing the step of parsing the component information, perform the following steps: Use the validation tool to check the contents of the SBOM and fix missing fields.

4. The open source software risk detection method based on the SBOM list according to claim 1 is characterized in that: The characteristic string is concatenated in the order of <component name|version|license|vendor|dependency>; a 64-bit hexadecimal hash value is generated using the SHA-256 algorithm and stored as the database primary key.

5. The open source software risk detection method based on the SBOM list according to claim 1 is characterized in that: The further manual judgment and supplementation of data to the feature database includes: Manually collect component information; including name, version, source, and functional description; Based on the collected information, determine the license type used by the component and evaluate its compatibility with the overall project license; If there is a compatibility relationship, query the public vulnerability database to check whether the component has known security vulnerabilities; If vulnerability information exists, its component information, vulnerability information and hash value are added to the feature database.

6. The open source software risk detection method based on the SBOM list according to claim 1 is characterized in that: The license compatibility matrix is: The rows and columns of the matrix represent different licenses, and each element Compatibility_Matrix[i][j] in the matrix represents the compatibility between license i and license j.

7. The open source software risk detection method based on the SBOM list according to claim 6 is characterized in that: Check the compatibility between the obtained license and the overall license of the project through a logical reasoning algorithm, including: Determine the type of license to obtain; Based on the determined license type and known open source licenses, determine the compatibility relationship between each license and the overall project license through the terms of each license; Match the obtained license with the license of the entire project. For each pair of component licenses, check the corresponding values ​​in the license compatibility matrix. If Compatibility_Matrix[i][j] = 0, it indicates that there is a license conflict.

8. An open source software risk detection device based on the SBOM list is characterized by: include: A component information parsing module is used to obtain the SBOM of the target software and parse the component information therein; wherein the component information includes component name, version, license, supplier and dependency information; A feature hash value calculation module, configured to generate a feature character string according to the component information of each component, and calculate a feature hash value based on the feature character string using a hash algorithm; A feature database construction module is used to parse component information and vulnerability information of known open source components, calculate their feature hash values, and store the component information, vulnerability information, and hash values ​​to form a feature database; A component matching and database update module is configured to search for a matching item in the feature database based on the feature hash value of the target software component. If a matching item is found, the corresponding license and vulnerability information are obtained. If not found, the component is marked as an unknown component and further supplemented with data to the feature database through manual judgment. A compatibility check module is used to construct a license compatibility matrix and check the compatibility between the obtained license and the overall license of the project through a logical reasoning algorithm; The vulnerability assessment module is used to compare the acquired vulnerability information with the feature database, calculate the vulnerability severity in combination with the CVSS scoring model, and generate a priority repair report.

9. An electronic device, characterized in that: The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. When the computer program is executed by the processor, the steps of the open source software risk detection method based on the SBOM list as described in any one of claims 1 to 7 are implemented.

10. A readable storage medium, characterized in that: The readable storage medium stores a program or instruction, and when the program or instruction is executed by the processor, the steps of the open source software risk detection method based on the SBOM list as described in any one of claims 1 to 7 are implemented.

Images