Software vulnerability detection method and device, equipment, medium and program product

Abstract

The invention provides a software vulnerability detection method and device, equipment, a medium and a program product, and relates to the technical field of software security, the method comprises the steps that a component knowledge graph is constructed according to a dependency relationship between full-amount component information and components, the component knowledge graph comprises a plurality of nodes and edges connecting the nodes, the node represents one component, and the edge represents a dependency relationship between two components; for to-be-detected software, acquiring direct dependency component information from a source code of the to-be-detected software, and acquiring indirect dependency component information from the component knowledge graph according to the direct dependency component information; according to the direct dependency component information and the indirect dependency component information, generating a software bill of material (SBOM) of the to-be-detected software; and obtaining a vulnerability detection result of the to-be-detected software according to the SBOM. According to the scheme, the generation efficiency of the SBOM is improved, and then the software vulnerability detection efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of software security technology, specifically to a software vulnerability detection method, apparatus, device, medium, and program product. Background Technology

[0002] Current software vulnerability detection technologies mainly include source code analysis-based software vulnerability detection technologies and Software Bill of Materials (SBOM) analysis-based software vulnerability detection technologies. However, source code analysis-based software vulnerability detection technologies suffer from high technical complexity, low detection efficiency, and accuracy issues caused by irrelevant characters in the code. SBOM analysis-based software vulnerability detection technologies are highly dependent on the environment when generating the SBOM and have many usage restrictions, resulting in low SBOM construction efficiency. Summary of the Invention

[0003] At least one embodiment of this application provides a software vulnerability detection method, apparatus, device, medium, and program product to address the problem of low SBOM construction efficiency in existing software vulnerability detection technologies based on SBOM analysis.

[0004] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a software vulnerability detection method, including: Based on the full component information and the dependencies between components, a component knowledge graph is constructed. The component knowledge graph includes multiple nodes and edges connecting the nodes, wherein a node represents a component and an edge represents the dependency between two components. For the software to be tested, information on directly dependent components is obtained from the source code of the software to be tested, and information on indirectly dependent components is obtained from the component knowledge graph based on the information on directly dependent components. Based on the information of the directly dependent components and the information of the indirectly dependent components, a software bill of materials for the software to be tested is generated; Based on the software bill of materials, obtain the vulnerability detection results of the software to be tested.

[0005] Optionally, in the software vulnerability detection method, obtaining the vulnerability detection results of the software to be tested based on the software bill of materials includes: The component information in the software bill of materials is compared with the component information in the vulnerability database to obtain the vulnerability detection result of the software to be tested. The vulnerability detection result includes the vulnerability component information and the patched version of the vulnerability component.

[0006] Optionally, in the software vulnerability detection method, after obtaining the vulnerability detection results of the software to be detected based on the software bill of materials, the method further includes: The vulnerability component information is matched one by one with the component information of each component in the source code of the software under test to obtain the components to be repaired in the software under test. Replace the current version of the component to be fixed with the fixed version of the vulnerable component.

[0007] Optionally, in the software vulnerability detection method, after replacing the current version of the component to be patched with a patched version of the vulnerable component, the method further includes: Based on the software to be tested and the component knowledge graph, obtain the transitive dependency version set of each component of the software to be tested; If the transitive dependency version set of the first top-level component to be upgraded includes the first indirect dependency component of the first version, and the transitive dependency version set of the second top-level component includes the first indirect dependency component of the second version, and the first version is lower than the second version, then perform one of the following: Obtain the first top-level component of the upgraded version corresponding to the first indirect dependent component of the second version from the component knowledge graph, and upgrade the first top-level component of the version to be upgraded based on the first top-level component of the upgraded version; Delete the first indirect dependent component from the transitive dependency version set of the first top-level component of the version to be upgraded or the transitive dependency version set of the second top-level component.

[0008] Optionally, in the software vulnerability detection method, the weight corresponding to the edge is positively correlated with the version update frequency and the search frequency of the component.

[0009] Optionally, the software vulnerability detection method, wherein constructing a component knowledge graph based on full component information and dependencies between components includes: Obtain full component information and dependencies between components related to vulnerability detection from the central repository; Based on the full component information, obtain the component set; Based on the component set and the dependencies between components, construct an entity set; Extract entity relationships from the entity set to construct a relationship set; A component knowledge graph is constructed based on the entity set and the relation set, wherein each entity in the entity set corresponds to a node, and each relation in the relation set corresponds to an edge.

[0010] Secondly, embodiments of this application also provide a software vulnerability detection device, comprising: The building module is used to construct a component knowledge graph based on the full component information and the dependencies between components. The component knowledge graph includes multiple nodes and edges connecting the nodes, wherein a node represents a component and an edge represents the dependency between two components. The first acquisition module is used to acquire direct dependency component information from the source code of the software to be tested, and acquire indirect dependency component information from the component knowledge graph based on the direct dependency component information. The generation module is used to generate a software bill of materials for the software to be tested based on the direct dependency component information and the indirect dependency component information. The second acquisition module is used to acquire the vulnerability detection results of the software to be tested based on the software bill of materials.

[0011] Thirdly, embodiments of this application also provide a software vulnerability detection device, including: a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the processor executes the program or instructions to implement the software vulnerability detection method as described in the first aspect.

[0012] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the software vulnerability detection method as described in the first aspect.

[0013] Fifthly, embodiments of this application also provide a computer program product, including computer instructions, which, when executed by a processor, implement the software vulnerability detection method as described in the first aspect.

[0014] Compared with existing technologies, embodiments of this application provide a software vulnerability detection method, apparatus, device, medium, and program product. The method includes: constructing a component knowledge graph based on full component information and dependencies between components. The component knowledge graph includes multiple nodes and edges connecting the nodes, where each node represents a component and each edge represents a dependency between two components; for the software to be detected, obtaining information on directly dependent components from the source code of the software to be detected, and obtaining information on indirectly dependent components from the component knowledge graph based on the information on directly dependent components; generating a Software Component Object Model (SBOM) of the software to be detected based on the information on directly dependent components and the information on indirectly dependent components; and obtaining the vulnerability detection result of the software to be detected based on the SBOM. Thus, without relying on an external environment or downloading components, the SBOM of the software to be detected can be generated based on the constructed component knowledge graph, improving the autonomy and efficiency of the SBOM generation process, thereby improving the efficiency of software vulnerability detection, while avoiding the risk of leakage of the source code of the software to be detected. Attached Figure Description

[0015] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart illustrating the software vulnerability detection method described in the embodiments of this application; Figure 2 This is a schematic diagram of the component knowledge graph described in the embodiments of this application; Figure 3 This is a schematic diagram of the process of constructing a component knowledge graph in an embodiment of this application; Figure 4 This is a schematic diagram illustrating the process of vulnerability repair based on vulnerability detection results in an embodiment of this application; Figure 5 This is an example diagram illustrating the component conflict relationships in the embodiments of this application; Figure 6 This is an example diagram of one embodiment of resolving component conflict relationships in this application. Figure 7 This is an example diagram illustrating another implementation of resolving component conflict relationships in the embodiments of this application; Figure 8 This is a flowchart illustrating one embodiment of the software vulnerability detection method described in this application. Figure 9 This is a schematic diagram of the structure of the software vulnerability detection device described in the embodiments of this application; Figure 10 This is a hardware block diagram of the software vulnerability detection device described in the embodiments of this application. Detailed Implementation

[0016] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such terms can be used interchangeably where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first" and "second" are generally of the same class, without limiting the number of objects; for example, the first object can be one or more. Furthermore, "or" in this application indicates at least one of the connected objects. For example, "A or B" covers three scenarios: Scenario 1: including A but not B; Scenario 2: including B but not A; Scenario 3: including both A and B. The character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0017] Please refer to Figure 1 This application provides a software vulnerability detection method, including: Step 101: Construct a component knowledge graph based on the full component information and the dependencies between components. The component knowledge graph includes multiple nodes and edges connecting the nodes, wherein a node represents a component and an edge represents the dependency between two components. In one implementation, optionally, a component knowledge graph is constructed based on the full component information and the dependencies between components, including: Obtain full component information and dependencies between components related to vulnerability detection from the central repository; Based on the full component information, obtain the component set; Based on the component set and the dependencies between components, construct an entity set; Extract entity relationships from the entity set to construct a relationship set; A component knowledge graph is constructed based on the entity set and the relation set, wherein each entity in the entity set corresponds to a node, and each relation in the relation set corresponds to an edge.

[0018] In this embodiment, the central repository includes, for example, Maven Central, npm, and PyPI. Component information includes, but is not limited to, at least one of the following: component name; component version number; license information; release date; developer; tags; and policies.

[0019] Optionally, obtain full component information related to vulnerability detection and the dependencies between components from the central repository, including: The system crawls full component information and dependencies between components from a central repository, and performs data cleaning and feature extraction operations on the crawled full component information to obtain full component information related to vulnerability detection. This reduces the impact of data and dimensions that are not related to vulnerability detection, and only retains data and dimensions that are relevant to vulnerability detection.

[0020] Optionally, the data cleaning operation is used to remove component information related to vulnerability detection from the full set of component information, including but not limited to at least one of the following: Information on components that depend on during the compilation phase; information on components that depend on during the testing phase; information on outdated components; information on components that are no longer maintained.

[0021] It should be noted that the component information from the compilation phase and the component information relied upon in the testing phase do not exist during software runtime and will not affect the vulnerability detection results obtained in subsequent steps; therefore, they can be excluded. The outdated component information and the component information that is no longer maintained have a low probability of use and can therefore be excluded.

[0022] Optionally, the feature extraction operation is used to extract component information related to vulnerability detection dimensions from the full component information, including but not limited to at least one of the following: component name; component version number; license information.

[0023] It should be noted that the component name and version number are used to match vulnerability component information in the vulnerability database in subsequent steps to identify vulnerabilities, and therefore need to be extracted. The license information is used to inform users of their rights and restrictions when using the software, ensuring that the software is used compliantly and legally. This is an important dimension affecting vulnerability detection, ensuring that the construction process of the candidate component knowledge graph is not affected by dimensions unrelated to vulnerability detection, and therefore also needs to be extracted.

[0024] Further, based on the full component information, a component set T is obtained. Based on the component set T and the dependencies between components, an entity set E = CREATE(T)z is constructed, where e = {x1, x2, x3, x4, ...} is an entity in the entity set, and each entity corresponds to a component. {x1, x2, x3, x4, ...} represents component information, where x1, x2, x3, x4, ... represent the component manufacturer, component name, component version number, and license information, respectively. After constructing the entity set, entity relationships are extracted from the entity set to construct a relationship set S, represented as follows: .

[0025] in, and Representing different entities, This refers to an entity relationship.

[0026] It should be noted that the entity relationships mentioned include dependencies between components.

[0027] Furthermore, a component knowledge graph is constructed based on the entity set and the relation set. Since the component knowledge graph is constructed based on the dependencies between components, it can be called a component dependency relationship knowledge graph. Here, the component knowledge graph is stored in a graph database, which uses a graph structure to store the entity set and the relation set.

[0028] Here, taking Java as an example, the constructed component knowledge graph is as follows: Figure 2 As shown, where, Figure 2 Directly dependent components are those found in the source code, while indirectly dependent components are those that are deeply dependent on the directly dependent components.

[0029] It should be noted that as component information increases with changes in component categories or versions, the component knowledge graph needs to be updated and merged regularly to ensure the accuracy and comprehensiveness of subsequent SBOM generation. This involves merging new components with older component knowledge graphs; the specific merging formula is as follows: .

[0030] in, Represents the existing component knowledge graph; E represents the fused component knowledge graph; E represents the fused entity set. Represents a set of relations that are merged; This represents a fusion function, used to instruct the fusion of new components into the existing component knowledge graph based on a dependency reinforcement mechanism. The fusion process can be as follows: Understandably, the merged component knowledge graph can also be stored in a graph database.

[0031] Define a weight model to assign an initial weight value to each edge in the component knowledge graph. Since higher version components are used more frequently, the initial weight value will increase with the component version number, that is, the higher the component version number, the higher the corresponding initial weight value.

[0032] There are two weight update strategies. First, when a new version of a component is added, the component knowledge graph is searched to find the n versions that are close to the component (n can be adjusted according to the generation effect of SBOM). The weight of the n close versions is increased, while the weight of versions other than the n close versions is decreased, thereby optimizing the structure of the component knowledge graph.

[0033] Secondly, based on the search frequency of the component knowledge graph, the component that is searched most frequently as an input parameter is usually a commonly used open-source component, and its weight can be increased, as shown in the following formula: .

[0034] in, The updated weights can be adjusted based on the above strategies; w is the weight before the update; let N(u) be the set of nearest-neighbor versions of component u. The weights between component u and component v before the update. The formula for increasing the weight between the updated components u and v is as follows: .

[0035] in, It is an adjustment factor. This refers to the update frequency or search frequency of component u. For non-adjacent versions, its influence is reduced through a weight decay mechanism, as shown in the following formula: .

[0036] Where β is the decay coefficient, used to control the extent to which the weight decreases over time or with version updates.

[0037] Therefore, optionally, the weight corresponding to the edge is positively correlated with the component's version update frequency and search frequency.

[0038] Figure 3 This is a schematic diagram illustrating the process of constructing a knowledge graph component in an embodiment of this application. For example... Figure 3 As shown, the method includes: Retrieve full component information from the central repository; perform data cleaning and feature extraction operations on the full component information to obtain full component information related to vulnerability detection; based on the full component information related to vulnerability detection, obtain a component set, and construct an entity set based on the component set and the dependencies between components; extract entity relationships from the entity set to construct a relationship set; construct a component knowledge graph based on the entity set and the relationship set; update the component knowledge graph with newly added components based on the dependency reinforcement mechanism; generate an SBOM based on the updated component knowledge graph.

[0039] Step 102: For the software to be tested, obtain the direct dependency component information from the source code of the software to be tested, and obtain the indirect dependency component information from the component knowledge graph based on the direct dependency component information. It should be noted that the dependency relationship between components refers to the mutual dependence between different components, including direct dependency and indirect dependency. If a component directly calls the interface or method of another component to complete its own function, the dependency relationship between the two components is a direct dependency. Therefore, the information of directly dependent components can be understood as the information of directly dependent components. If a component connects with another component through other intermediate components or layers, the dependency relationship between the two components is an indirect dependency. Therefore, the information of indirectly dependent components can be understood as the information of indirectly dependent components.

[0040] In this embodiment of the application, for the software to be detected, the direct dependency component information in the source code is identified. The direct dependency component information includes at least one of the following: unique identifier; component manufacturer; component name; component version number. The direct dependency component information is input into the component knowledge graph to obtain the indirect dependency component information. The indirect dependency component information includes at least one of the following: unique identifier; component manufacturer; component name; component version number.

[0041] Step 103: Generate the SBOM of the software to be tested based on the direct dependency component information and the indirect dependency component information; In this embodiment, each direct dependency is traversed, and the component information of indirect dependencies is directly extracted based on the dependency relationships between components. This operation is performed on each direct dependency. After extraction, an SBOM is generated for each indirect dependency corresponding to each direct dependency.

[0042] Existing SBOM generation technologies rely on a central repository and build tools. The build tools first need to run in an environment with the build tools installed. The build tools obtain the dependency tree and then download dependency packages from the central repository. Deep dependencies are then resolved from the dependency packages. The download process consumes a significant amount of bandwidth, resulting in time-consuming SBOM generation. Furthermore, the strong dependence on the environment also places certain technical requirements on the users of the tools, requiring prior environment installation and configuration. The overall process is quite cumbersome.

[0043] Therefore, compared to existing technologies that generate SBOMs based on a constructed component knowledge graph, the structured nature of the component knowledge graph makes data maintenance and updates easier. SBOMs can be generated from the component knowledge graph constructed using component entity information and dependency data, without relying on an external environment or downloading component packages. This method is simple and efficient. Furthermore, a dependency enhancement mechanism is introduced for the component knowledge graph. When a component version update is detected or a component is searched, the component's weight in the component knowledge graph is increased to improve the accuracy of component knowledge graph searches, thereby improving the accuracy of SBOM generation.

[0044] Step 104: Obtain the vulnerability detection results of the software to be tested based on the SBOM.

[0045] In one implementation method, optionally, obtaining the vulnerability detection results of the software to be detected based on the SBOM includes: The component information in the SBOM is compared with the component information in the vulnerability database to obtain the vulnerability detection result of the software to be tested. The vulnerability detection result includes the vulnerability component information and the patched version of the vulnerability component.

[0046] It should be noted that vulnerability detection is a key part of open-source software supply chain security. By comparing the detailed information of relevant components in the SBOM generated in the above steps, such as component name, component vendor, and component version number, with the corresponding component information in the vulnerability database one by one, the vulnerability detection results can be obtained. Thus, vulnerability detection can be achieved without source code parsing.

[0047] Optionally, the vulnerability database includes a complete set of vulnerability information, which is related to vulnerable components and includes component information of those components. The complete set of vulnerability information includes, but is not limited to, at least one of the following: vulnerable component information; vulnerable component version number; and patched versions of the vulnerable components. Therefore, the vulnerability detection results include all vulnerable components and their patched versions.

[0048] In one implementation, optionally, after obtaining the vulnerability detection results of the software to be detected according to the SBOM, the method further includes: The vulnerability component information is matched one by one with the component information of each component in the source code of the software under test to obtain the components to be repaired in the software under test. Replace the current version of the component to be fixed with the fixed version of the vulnerable component.

[0049] It should be noted that after completing vulnerability detection on the software to be tested and obtaining the vulnerability detection results, the method also includes vulnerability patching based on the vulnerability detection results.

[0050] Existing software supply chain security platforms typically hand over vulnerability detection to users for manual vulnerability patching. The whole process is quite cumbersome, requiring version modifications and encountering version conflict issues. Therefore, it is necessary to repeatedly resolve conflicts by modifying or excluding versions.

[0051] Compared to existing technologies, this application's embodiments repair vulnerabilities by replacing the version of the vulnerable component in the source code of the software under test, based on the vulnerability component information, thus avoiding the tediousness and inefficiency of manual operations. Specifically, this application's embodiments parse the source code of the software under test into structured data according to the language type, then match the vulnerability component information with the structured data one by one. If a match is found, the component to be repaired is obtained, and the repaired version of the vulnerability component replaces the current version of the component to be repaired.

[0052] In one implementation, optionally, after replacing the current version of the component to be patched with the patched version of the vulnerable component, the method further includes: Based on the software to be tested and the component knowledge graph, obtain the transitive dependency version set of each component of the software to be tested; If the transitive dependency version set of the first top-level component to be upgraded includes the first indirect dependency component of the first version, and the transitive dependency version set of the second top-level component includes the first indirect dependency component of the second version, and the first version is lower than the second version, it means that there is a component conflict relationship, which needs to be resolved by performing one of the following: Obtain the first top-level component of the upgraded version corresponding to the first indirect dependent component of the second version from the component knowledge graph, and upgrade the first top-level component of the version to be upgraded based on the first top-level component of the upgraded version; Delete the first indirect dependent component from the transitive dependency version set of the first top-level component of the version to be upgraded or the transitive dependency version set of the second top-level component.

[0053] It should be noted that after the replacement version, the new source code project often has problems such as component dependency conflicts. In order to solve such problems, this application embodiment uses a component knowledge graph to determine and resolve conflicts, resolves conflicts during the automatic repair process, and finally outputs a source code project that can be compiled.

[0054] Figure 4 This is a schematic diagram illustrating the process of vulnerability remediation based on vulnerability detection results in an embodiment of this application. Figure 4 As shown, the method includes: For the source code of the software to be tested, scan the feature files and parse them into different structured data according to the feature file type. For example, for a Java language pom.xml feature file, according to... <dependency>< / dependency> The parsed data is structured as follows: type Component struct { groupId String / / Component vendor artifactId String / / Component name version String / / Component version number }

[0055] The vulnerability is matched with the structured data of the source code based on the vulnerability component information in the vulnerability detection results. If a match is found, the component to be repaired is obtained, and the current version of the component to be repaired is replaced with the repaired version of the vulnerability component in the vulnerability detection results, thereby completing the vulnerability repair.

[0056] It should also be noted that after the above version replacement, version conflict issues may exist. In order to resolve version conflict issues, this application embodiment uses the component knowledge graph to resolve conflicts, so as to achieve a compileable state of the repaired code and improve the efficiency of software vulnerability repair.

[0057] Here, version conflict issues include different version dependencies and transitive dependencies.

[0058] Among them, different version dependencies: When different versions of the same library are introduced into a project, differences in method signatures, class structures or configurations may occur, which may lead to conflicts.

[0059] Transitive dependencies: A dependency may introduce other dependencies, and there may be conflicts between these transitive dependencies.

[0060] In this application embodiment, the method for resolving component conflict relationships includes: In dependency management, deep dependencies of a component can be excluded using tags; Upgrade the component version to ensure consistency when the same component is imported in multiple places.

[0061] Specifically, component conflicts are resolved using a component knowledge graph. First, component information from the source code of the software to be tested is input into the component knowledge graph, collecting a set of all transitive dependency versions for each component. , is the top-level component in the source code feature file, and the elements in the set are Where x1, x2, and x3 represent component information, and ver represents the component version, defined... and These are two components in the source code signature file. and They are respectively and The set of transitive dependency versions Defined as a set and The intersection of the two sets of components, where the components are identical but the versions are different. and There exists and To determine if there is a conflict between these two components, the component conflict function is defined as follows: .

[0062] That is, set and If there are different versions of the same component, then the component is considered... and There are conflicts, such as Figure 5 As shown, the first indirectly dependent component B has two versions, 1.1.0 and 1.1.1. Therefore, it is considered that the first top-level component A and the second top-level component F have a component conflict relationship. The version of the first indirectly dependent component B in the transitive dependency version set of the first top-level component A is 1.1.0, and the version of the first indirectly dependent component B in the transitive dependency version set of the second top-level component F is 1.1.1.

[0063] To resolve component conflicts, it is necessary to exclude one of the indirectly dependent components B or upgrade the version of the first top-level component A to ensure that the versions of the same first indirectly dependent component B are consistent.

[0064] The upgrade involves upgrading the version of the first top-level component A to ensure that all first indirectly dependent components B are version 1.1.1. The specific upgrade version of the first top-level component A can be obtained from the component knowledge graph. That is, the upgrade version of the first top-level component A is obtained from the component knowledge graph based on the 1.1.1 version of the first indirectly dependent component B. For example, if the component knowledge graph shows that version 1.1.2 of the first top-level component A includes version 1.1.1 of the first indirectly dependent component B, then the first top-level component A to be upgraded (version 1.0.0) is upgraded according to its upgrade version 1.1.2. The upgraded component dependencies are as follows: Figure 6 As shown.

[0065] Version exclusion involves removing the first indirect dependency component B from the transitive dependency version set of either the first top-level component A or the second top-level component F. Ideally, lower versions should also be excluded. Simultaneously, a deeper dependency is added to the top-level component to ensure dependency integrity. For example, removing the first indirect dependency component B from the transitive dependency version set of the first top-level component A and adding the second indirect dependency component D to the top-level component would result in the following component dependency relationships: Figure 7 As shown.

[0066] This is achieved by upgrading or excluding versions, modifying the component's structured data, and then regenerating the structured data into the feature file after the changes are complete and conflict-free. Ultimately, this ensures the source code is vulnerability-free and compiles successfully, improving the efficiency of software vulnerability scanning and remediation.

[0067] Figure 8 This is a flowchart illustrating one embodiment of the software vulnerability detection method described in this application. Figure 8 As shown, the method includes: Construct a component knowledge graph based on all component information and the dependencies between components; Based on the component knowledge graph and the source code of the software to be tested, the SBOM of the software to be tested is generated. The SBOM includes component information of multiple components. The vulnerability detection results of the software to be tested are obtained by matching the component information in the SBOM with the component information in the vulnerability database. The vulnerable component is patched based on the patched version of the vulnerability component, and component conflict relationships are resolved.

[0068] In summary, the software vulnerability detection method described in this application first obtains full component information and dependencies between components from a central repository to construct a component knowledge graph. A dependency strengthening mechanism is proposed: when a component version update is detected or a component is used in a component knowledge graph search, it indicates that the component has a high usage rate. The dependency relationship between this component and other components is automatically strengthened to increase the weight of the component's edges in the component knowledge graph. Then, based on the component knowledge graph, the direct dependency component information and indirect dependency component information in the source code feature files of the software to be detected are parsed, and a Substituent Name Module (SBOM) is generated. The component information in the SBOM is matched with the component information in the vulnerability database to obtain vulnerability detection results, including the patched versions of the vulnerable components. A reverse scan is performed based on the vulnerable components and their patched versions, and the original feature files are matched. The version of the vulnerable component to be patched is replaced with the patched version to complete the vulnerability patching. During the patching process, based on the aforementioned component knowledge graph, it is determined whether there are version conflicts. Based on the determination result, an appropriate version is selected for replacement or version exclusion to ensure that the automatically patched source code project can be compiled normally.

[0069] The software vulnerability detection method described in this application has the following beneficial effects: This paper proposes a component-based SBOM generation method, constructing a knowledge graph containing component dependencies. A dependency reinforcement mechanism is introduced into the component knowledge graph, which is continuously optimized for SBOM generation. This optimized graph is used to obtain component information and dependencies during SBOM generation, eliminating the need for external environments and component downloads, thus improving the autonomy and efficiency of the SBOM generation process. This, in turn, enhances the efficiency of subsequent software vulnerability detection and avoids the risk of source code leakage. Furthermore, a reverse-scanning technique for automatic vulnerability repair is proposed. After obtaining vulnerability detection results, it replaces vulnerable component versions to fix the vulnerability, replacing manual operations and significantly improving software vulnerability repair efficiency. The component knowledge graph is also applied to automatic vulnerability repair, analyzing for component conflicts during the repair process and assisting in conflict resolution through version replacement or component exclusion. This determines the optimal version for vulnerability repair, ensuring successful compilation of the source code after repair.

[0070] Please refer to Figure 9 This application also provides a software vulnerability detection device, including: The construction module 901 is used to construct a component knowledge graph based on the full component information and the dependencies between components. The component knowledge graph includes multiple nodes and edges connecting the nodes, wherein a node represents a component and an edge represents a dependency between two components. The first acquisition module 902 is used to acquire direct dependency component information from the source code of the software to be tested, and acquire indirect dependency component information from the component knowledge graph based on the direct dependency component information. The generation module 903 is used to generate the software bill of materials (SBOM) of the software to be tested based on the direct dependency component information and the indirect dependency component information. The second acquisition module 904 is used to acquire the vulnerability detection results of the software to be detected based on the SBOM.

[0071] Optionally, in the software vulnerability detection device, the second acquisition module 904 is specifically used for: The component information in the SBOM is compared with the component information in the vulnerability database to obtain the vulnerability detection result of the software to be tested. The vulnerability detection result includes the vulnerability component information and the patched version of the vulnerability component.

[0072] Optionally, the software vulnerability detection device further includes: The matching module is used to match the vulnerability component information with the component information of each component in the source code of the software to be tested one by one to obtain the components to be repaired in the software to be tested. Replace the current version of the component to be fixed with the fixed version of the vulnerable component.

[0073] Optionally, the software vulnerability detection device further includes: The third acquisition module is used to acquire the transitive dependency version set of each component of the software to be detected based on the software to be detected and the component knowledge graph; The execution module is configured to, in the case where the transitive dependency version set of the first top-level component to be upgraded includes the first indirect dependency component of the first version, the transitive dependency version set of the second top-level component includes the first indirect dependency component of the second version, and the first version is lower than the second version, execute one of the following: Obtain the first top-level component of the upgraded version corresponding to the first indirect dependent component of the second version from the component knowledge graph, and upgrade the first top-level component of the version to be upgraded based on the first top-level component of the upgraded version; Delete the first indirect dependent component from the transitive dependency version set of the first top-level component of the version to be upgraded or the transitive dependency version set of the second top-level component.

[0074] Optionally, in the software vulnerability detection device, the weight corresponding to the edge is positively correlated with the version update frequency and the search frequency of the component.

[0075] Optionally, in the software vulnerability detection device, the construction module 901 is specifically used for: Obtain full component information and dependencies between components related to vulnerability detection from the central repository; Based on the full component information, obtain the component set; Based on the component set and the dependencies between components, construct an entity set; Extract entity relationships from the entity set to construct a relationship set; A component knowledge graph is constructed based on the entity set and the relation set, wherein each entity in the entity set corresponds to a node, and each relation in the relation set corresponds to an edge.

[0076] It should be noted that the apparatus provided in this application embodiment can implement all the method steps implemented in the above software vulnerability detection method embodiment and can achieve the same technical effect. Here, the parts that are the same as those in the method embodiment and the beneficial effects will not be described in detail.

[0077] This application also provides a software vulnerability detection device, such as... Figure 10 As shown, it includes: The processor 1001, memory 1002, transceiver 1003, and a program or instructions stored in the memory 1002 and executable on the processor 1001; when the processor 1001 executes the program or instructions, it implements the various processes of the above-described software vulnerability detection method embodiments and achieves the same technical effect. To avoid repetition, these will not be described again here.

[0078] The transceiver 1003 is used to receive and send data under the control of the processor 1001.

[0079] Among them, Figure 10 In this context, the bus architecture can include any number of interconnected buses and bridges, specifically connecting various circuits of one or more processors represented by processor 1001 and memory represented by memory 1002. The bus architecture can also connect various other circuits such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and therefore will not be described further herein. The bus interface provides an interface. The transceiver 1003 can be multiple elements, including transmitters and receivers, providing a unit for communicating with various other devices over a transmission medium. For different user equipment, the user interface 1004 can also be an interface capable of connecting external or internal devices, including but not limited to keypads, displays, speakers, microphones, joysticks, etc.

[0080] The processor 1001 is responsible for managing the bus architecture and general processing, while the memory 1002 can store the data used by the processor 1001 when performing operations.

[0081] This application also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the various processes of the above-described software vulnerability detection method embodiments and achieves the same technical effects. To avoid repetition, it will not be described again here. The computer-readable storage medium may include, for example, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0082] This application also provides a computer program product, including computer instructions. When the computer instructions are executed by a processor, they implement the various processes of the above-described software vulnerability detection method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0083] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

[0084] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they 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 this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. The computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0085] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A software vulnerability detection method, characterized in that, include: Based on the full component information and the dependencies between components, a component knowledge graph is constructed. The component knowledge graph includes multiple nodes and edges connecting the nodes, wherein a node represents a component and an edge represents the dependency between two components. For the software to be tested, information on directly dependent components is obtained from the source code of the software to be tested, and information on indirectly dependent components is obtained from the component knowledge graph based on the information on directly dependent components. Based on the information of the directly dependent components and the information of the indirectly dependent components, a software bill of materials for the software to be tested is generated; Based on the software bill of materials, obtain the vulnerability detection results of the software to be tested.

2. The software vulnerability detection method according to claim 1, characterized in that, Based on the software bill of materials, obtain the vulnerability detection results of the software to be tested, including: The component information in the software bill of materials is compared with the component information in the vulnerability database to obtain the vulnerability detection result of the software to be tested. The vulnerability detection result includes the vulnerability component information and the patched version of the vulnerability component.

3. The software vulnerability detection method according to claim 2, characterized in that, After obtaining the vulnerability detection results of the software to be tested based on the software bill of materials, the method further includes: The vulnerability component information is matched one by one with the component information of each component in the source code of the software under test to obtain the components to be repaired in the software under test. Replace the current version of the component to be fixed with the fixed version of the vulnerable component.

4. The software vulnerability detection method according to claim 3, characterized in that, After replacing the current version of the component to be patched with the patched version of the vulnerable component, the method further includes: Based on the software to be tested and the component knowledge graph, obtain the transitive dependency version set of each component of the software to be tested; If the transitive dependency version set of the first top-level component to be upgraded includes the first indirect dependency component of the first version, and the transitive dependency version set of the second top-level component includes the first indirect dependency component of the second version, and the first version is lower than the second version, then perform one of the following: Obtain the first top-level component of the upgraded version corresponding to the first indirect dependent component of the second version from the component knowledge graph, and upgrade the first top-level component of the version to be upgraded based on the first top-level component of the upgraded version; Delete the first indirect dependent component from the transitive dependency version set of the first top-level component of the version to be upgraded or the transitive dependency version set of the second top-level component.

5. The software vulnerability detection method according to claim 1, characterized in that, The weights corresponding to the edges are positively correlated with the component's version update frequency and search frequency.

6. The software vulnerability detection method according to claim 1, characterized in that, Based on the full component information and the dependencies between components, a component knowledge graph is constructed, including: Obtain full component information and dependencies between components related to vulnerability detection from the central repository; Based on the full component information, obtain the component set; Based on the component set and the dependencies between components, construct an entity set; Extract entity relationships from the entity set to construct a relationship set; A component knowledge graph is constructed based on the entity set and the relation set, wherein each entity in the entity set corresponds to a node, and each relation in the relation set corresponds to an edge.

7. A software vulnerability detection device, characterized in that, include: The building module is used to construct a component knowledge graph based on the full component information and the dependencies between components. The component knowledge graph includes multiple nodes and edges connecting the nodes, wherein a node represents a component and an edge represents the dependency between two components. The first acquisition module is used to acquire direct dependency component information from the source code of the software to be tested, and acquire indirect dependency component information from the component knowledge graph based on the direct dependency component information. The generation module is used to generate a software bill of materials for the software to be tested based on the direct dependency component information and the indirect dependency component information. The second acquisition module is used to acquire the vulnerability detection results of the software to be tested based on the software bill of materials.

8. A software vulnerability detection device, characterized in that, include: A processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the processor, when executing the program or instructions, implements the software vulnerability detection method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the software vulnerability detection method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, It includes computer instructions that, when executed by a processor, implement the software vulnerability detection method as described in any one of claims 1 to 6.

Images