CN114611111A - Vulnerability repair method and computing equipment - Google Patents
Vulnerability repair method and computing equipment Download PDFInfo
- Publication number
- CN114611111A CN114611111A CN202210126375.7A CN202210126375A CN114611111A CN 114611111 A CN114611111 A CN 114611111A CN 202210126375 A CN202210126375 A CN 202210126375A CN 114611111 A CN114611111 A CN 114611111A
- Authority
- CN
- China
- Prior art keywords
- component
- information
- vulnerability
- determining
- interface
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 230000008439 repair process Effects 0.000 title claims abstract description 60
- 238000000034 method Methods 0.000 title claims abstract description 53
- 230000008859 change Effects 0.000 claims abstract description 59
- 238000004458 analytical method Methods 0.000 claims description 52
- 238000012545 processing Methods 0.000 claims description 14
- 238000012790 confirmation Methods 0.000 claims description 3
- 238000010586 diagram Methods 0.000 description 11
- 238000005516 engineering process Methods 0.000 description 7
- 238000012360 testing method Methods 0.000 description 5
- 238000004891 communication Methods 0.000 description 4
- 238000011161 development Methods 0.000 description 4
- 230000008569 process Effects 0.000 description 3
- 238000012795 verification Methods 0.000 description 3
- 238000012550 audit Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000001133 acceleration Effects 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000012512 characterization method Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000003062 neural network model Methods 0.000 description 1
- 230000002093 peripheral effect Effects 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000012552 review Methods 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/577—Assessing vulnerabilities and evaluating computer system security
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3604—Software analysis for verifying properties of programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
Landscapes
- Engineering & Computer Science (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Computing Systems (AREA)
- Stored Programmes (AREA)
Abstract
The embodiment of the invention provides a vulnerability repairing method and computing equipment. The vulnerability repairing method comprises the following steps: determining a first component with a vulnerability from a code base; determining a second component from a component library to replace the first component; determining compatibility change information of the second component relative to the first component according to interface implementation information of the first component and the second component; and generating a repair scheme aiming at the vulnerability according to the first component, the second component and the compatibility change information. The technical scheme provided by the embodiment of the invention can automatically determine the second component for repairing the bug for the user, and can also provide the compatibility change information of the second component relative to the first component, thereby ensuring the compatibility of bug repairing.
Description
Technical Field
The embodiment of the invention relates to the technical field of network information security, in particular to a vulnerability fixing method and electronic equipment.
Background
In the related art, many code items use open source technology. However, the open source technology brings a series of convenience for software writing and also hides a great deal of security risks. According to the audit, 75% of code libraries written by using the open source technology have bugs, 49% of which are high-risk bugs, and therefore, the bugs need to be repaired.
Disclosure of Invention
The embodiment of the invention provides a vulnerability repairing method and device and computing equipment.
In a first aspect, an embodiment of the present invention provides a vulnerability fixing method, including:
determining a first component with a vulnerability from a code base;
determining a second component for replacing the first component from a component library;
determining compatibility change information of the second component relative to the first component according to interface implementation information of the first component and the second component;
and generating a repair scheme aiming at the vulnerability according to the first component, the second component and the compatibility change information.
In a second aspect, an embodiment of the present invention provides a bug fixing device, including:
the first component determining module is used for determining a first component with a vulnerability from a code library;
a second component determination module for determining a second component for replacing the first component from a component library;
the compatibility determining module is used for determining compatibility change information of the second component relative to the first component according to interface implementation information of the first component and the second component;
and the scheme generating module is used for generating a repair scheme aiming at the vulnerability according to the first component, the second component and the compatibility change information.
In a second aspect, embodiments of the present invention provide a computing device, comprising a processing component and a storage component;
the storage component stores one or more computer instructions; the one or more computer instructions to be invoked for execution by the processing component;
the storage component stores one or more computer instructions; the one or more computer instructions are used for being called and executed by the processing component to realize the bug fixing method provided by the embodiment of the invention.
In the embodiment of the invention, a first component with a bug is determined from a code library; determining a second component for replacing the first component from a component library; determining compatibility change information of the second component relative to the first component according to interface implementation information of the first component and the second component; according to the first assembly, the second assembly and the compatibility change information, a technical scheme of a repair scheme aiming at the bug is generated, the second assembly used for repairing the bug can be automatically determined for a user, and the compatibility change information of the second assembly relative to the first assembly can be provided, so that the compatibility of bug repair is ensured, and the difficulty of bug repair is reduced.
These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, and it is obvious that the drawings in the following description are some embodiments of the present invention, and those skilled in the art can also obtain other drawings according to the drawings without creative efforts.
FIG. 1 is a flow chart of a bug fix method according to an embodiment of the invention;
FIG. 2 schematically illustrates a schematic diagram of a repair scenario output of an embodiment of the present invention;
FIG. 3 schematically illustrates a schematic diagram of the repair scenario output of another embodiment of the present invention;
FIG. 4 schematically illustrates a schematic diagram of a repair scenario provided by an embodiment of the present invention;
fig. 5 schematically illustrates a schematic diagram of a vulnerability fixing method provided in an embodiment of the present invention;
fig. 6 is a block diagram schematically illustrating a bug fixing device provided in an embodiment of the present invention;
FIG. 7 schematically illustrates a block diagram of a computing device provided by an embodiment of the invention.
Detailed Description
In order to make the technical solutions of the present invention better understood, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention.
In some of the flows described in the present specification and claims and in the above figures, a number of operations are included that occur in a particular order, but it should be clearly understood that these operations may be performed out of order or in parallel as they occur herein, with the order of the operations being indicated as 101, 102, etc. merely to distinguish between the various operations, and the order of the operations by themselves does not represent any order of performance. Additionally, the flows may include more or fewer operations, and the operations may be performed sequentially or in parallel. It should be noted that, the descriptions of "first", "second", etc. in this document are used for distinguishing different messages, devices, modules, etc., and do not represent a sequential order, nor limit the types of "first" and "second" to be different.
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
It should be noted that the bug fixing method provided in the embodiment of the present invention may be generally executed by a computer device with certain computing capability, and the computer device may include, for example: a terminal device, which may be a user equipment, a mobile device, a user terminal, a cellular phone, a Personal Digital Assistant (PDA), a handheld device, a computing device, or a server or other processing device. In some possible implementations, the bug fix method may also be implemented by a processor calling computer readable instructions stored in memory.
According to industry analysis reports, over 99% of organizations have used open source technology. The advantages of technical communication and collaboration on the shoulders of giant people, reduction of development cost, acceleration of iteration cycles, improvement of software quality and the like brought by using components developed by open source technology become common knowledge in the industry. However, the utilization of open source components brings a series of convenience to the development of open source software, and simultaneously, a great deal of security risks are hidden. According to the audit, 75% of code libraries written by using the open source technology have bugs, and 49% of the code libraries are high-risk bugs.
Developers generally feed back that bug fixes are difficult and are unwilling or difficult to deal with. The inventor finds that vulnerability repair is difficult, and a compatible repair component version cannot be quickly and conveniently determined.
In the related art, for the determination of the compatible repair version, a method of periodically checking for updating is generally adopted, and specifically, when it is determined that an unsafe component exists in the code library by polling the current code library of a user, a separate code review is initiated to upgrade the component. The basis for judging whether the upgrade is compatible is based on the background of the open source community, and suggestions are provided by summarizing the passing rate of unit tests of the upgrade of the historical version, for example, when the A component is upgraded from the 1.1.12 version to the 1.1.14 version, the compatibility of the bug repair is informed to the user by counting and summarizing the passing rate of the unit tests of all the code libraries aiming at the component A in the open source community.
Because the technical scheme in the related technology depends on the number of users executing the same repairing operation and the quality of the user code base, enough users are required to configure more complete unit tests, and the method is not applicable to enterprise-level vulnerability repairing scenes with higher requirements on the security of the code base.
Therefore, in order to reduce the difficulty of bug fixing, the embodiment of the present invention provides a bug fixing method.
Fig. 1 schematically shows a flowchart of a vulnerability fixing method according to an embodiment of the present invention, and as shown in fig. 1, the method includes the following steps:
101, determining a first component with a vulnerability from a code base.
According to an embodiment of the invention, the code library may be a code library of the target item. The target item may be, for example, a JAVA item, a Python item, or the like written in any programming language.
According to some embodiments of the invention, the codebase may include a codebase generated using an open source technique.
According to the embodiment of the invention, the first component with the bug can be determined by traversing all components in the code base.
A second component for replacing the first component is determined from the component library 102.
According to an embodiment of the invention, when the target item is a Maven item, the component library may be a Maven warehouse.
According to embodiments of the present invention, the first component and the second component may be different versions of the same component, for example, the first component may be the 1.1.2 version of the a component, the second component may be the 1.1.4 version or the 1.1.1 version of the a component, and so on.
According to the embodiment of the invention, after detecting the first component with the bug, the maven warehouse can be searched to obtain the second component, the second component can be the first component with the upgraded version, and the bug existing in the version of the first component is repaired in the version of the second component.
According to the embodiment of the present invention, in some possible cases, the second component determined in step 102 may not be compatible with the code base in the actual repair process, although the bug existing in the first component may be theoretically repaired by the second component.
And 103, determining compatibility change information of the second component relative to the first component according to the interface implementation information of the first component and the second component.
According to the embodiment of the invention, whether the second component is compatible with the code base relative to the first component or not can be determined at least partially according to the implementation information of the interface packaged in the first component and the interface packaged in the second component, and the compatibility change information representing the compatibility degree can be generated.
And 104, generating a repair scheme aiming at the vulnerability according to the first component, the second component and the compatibility change information.
According to the embodiment of the invention, the bug fixing scheme can be output to the user for indicating the bug existing in the first component, and the bug fixing scheme can be fixed by using the second component.
According to the embodiment of the invention, because the compatibility change information can represent the compatibility influence on the code base after the first component is replaced by the second component, after the user obtains the repair scheme, whether the second component is used for repairing the bug can be determined based on the compatibility change information. For example, when the compatibility change information represents that the compatibility of the second component on the code library is less affected, the second component can be directly used for replacing the first component so as to repair the bug; when the compatibility change information represents that the compatibility of the second component on the code base is greatly influenced, the user can perform secondary development on the code base and/or the second component based on the incompatible part indicated by the compatibility change information so as to eliminate the compatibility influence of the second component on the code base, and repair the vulnerability by using the secondarily developed second component, so that the difficulty in repairing the vulnerability can be reduced.
In the embodiment of the invention, a first component with a vulnerability is determined from a code base; determining a second component for replacing the first component from the component library; determining compatibility change information of the second component relative to the first component according to interface implementation information of the first component and the second component; the technical scheme of the bug repairing scheme is generated according to the first assembly, the second assembly and the compatibility change information, the second assembly used for repairing the bug can be automatically determined for a user, and the compatibility change information of the second assembly relative to the first assembly can be provided, so that the bug repairing compatibility is guaranteed, and the bug repairing difficulty is reduced.
According to the embodiment of the present invention, determining the compatibility change information of the second component with respect to the first component may specifically be implemented as:
acquiring first interface implementation information of a first component and second interface implementation information of a second component;
determining difference interface information of the first interface realization information and the second interface realization information;
based on the codebase and the difference interface information, compatibility change information is determined.
According to the embodiment of the present invention, the first interface implementation information and the second interface implementation information may be interface implementation lists respectively, all interfaces packaged in the first component may be shown in the first interface implementation list, and all interfaces packaged in the second component may be shown in the second interface call list.
According to an embodiment of the present invention, the difference interface information may include interface difference information and/or interface implementation difference information.
According to an embodiment of the present invention, the interface difference information may characterize the interface difference encapsulated by the first interface implementation list and the second interface implementation list. For example, the first interface implementation list may include interface a, interface B, interface C, and interface D. The second interface implementation list may include interface a, interface C, interface D, and interface E. By comparing the first interface implementation list with the second interface implementation list, it can be determined that the second interface implementation list lacks an interface B and adds an interface E to the first interface implementation list. Thus, the interface difference information can be the interface difference information by 'lacking the interface B and adding the interface E'.
According to the embodiment of the present invention, the interface implementation difference information may represent the implementation difference of the interfaces existing in the first interface implementation list and the second interface implementation list at the same time. For example, interface B exists in both the first interface implementation list and the second interface implementation list, and for convenience of distinction, interface B existing in the first interface call list is referred to as B1, and interface B existing in the first interface call list is referred to as B2. After obtaining B1 and B2, the configuration lists of B1 and B2 may be compared, so as to obtain interface implementation difference information.
According to an embodiment of the present invention, the configuration list may include, for example, number and type of methods, number of method parameters, type of method parameters, and the like.
According to an embodiment of the present invention, by comparing the configuration lists of B1 and B2, a method change, a method parameter type change, etc. of B2 with respect to B1 can be determined.
According to the embodiment of the invention, in some possible scenarios, although the interface implementation information of the second component and the second component is not completely consistent, the interface implementation difference of the second component relative to the first component is not actually called in the code library, and thus the interface implementation difference of the second component relative to the first component does not have compatibility influence on the code library.
According to the embodiment of the present invention, after determining the difference interface information between the first interface implementation information and the second interface implementation information, the compatibility change information may be determined based on the code library and the difference interface information, and the step may specifically be implemented as:
carrying out syntactic analysis on the code base to generate an abstract syntactic tree;
determining interface calling information in an abstract syntax tree;
and generating compatibility change information according to the interface calling information and the difference interface information.
According to the embodiment of the invention, the code base can be parsed by using a javaspaser code analysis tool, and the source code of the code base can be parsed into an Abstract Syntax Tree (AST). The syntax analysis of the javaspaser on the code base is the prior art, and the embodiment of the invention is not described again.
According to the embodiment of the invention, after the AST is generated, all the actually called interfaces in the code base can be searched from the AST, and the interface calling information is generated.
According to the embodiment of the invention, after all the actually called interfaces in the code library are determined, the interface calling information and the interface difference information can be compared, so that the actually called and changed interfaces in the code library can be determined. For example, the difference interface information indicates that the second component lacks interface B relative to the first component and thus may have a compatibility impact on the code library, however, by comparing the interface difference information with the interface call information, interface B is not actually called in the code library and thus, the difference interface information does not have a compatibility impact on the code library. For another example, the difference interface information indicates that the second component lacks an interface C relative to the first component, and the interface C also exists in the interface call information, that is, the interface C is actually called in the code library, so that the lack of the interface C may have a compatibility influence on the code library, and thus the lack of the interface C may be written in the compatibility change information.
According to the embodiment of the invention, the interface implementation difference information in the difference interface information characterizes that the interface packaged in the first component and the interface packaged in the second component have difference at an interface definition level, but the difference at the interface definition level does not necessarily characterize that the compatibility influence on the code base is generated on the program execution. Therefore, after determining the difference between the interface encapsulated in the first component and the interface encapsulated in the second component at the interface definition level, the abstract syntax tree is used to determine the actually called interface in the code library, so that the difference between the definition level and the actually called interface can be compared to determine whether the difference between the interface encapsulated in the first component and the interface encapsulated in the second component at the interface definition level will actually affect the code library.
According to the embodiment of the present invention, the determining of the first component having the bug from the code library may specifically be implemented as:
scanning the code base to determine at least one component to be tested;
and matching the at least one component to be tested with the vulnerability knowledge base, and determining the first component and the vulnerability of the first component from the at least one component to be tested.
According to the embodiment of the invention, the header file, the library description file and the packet path of the code library can be scanned, so that at least one component to be tested is determined.
According to the embodiment of the invention, the vulnerability knowledge base can be downloaded to the local in advance for offline matching, but the method is not limited to the method, and the matching between the component to be tested and the vulnerability knowledge base can be performed online.
According to the embodiment of the invention, the vulnerability knowledge base can contain known vulnerability and security information, and each vulnerability can have a unique identification code so as to be convenient for query.
According to the embodiment of the present invention, the Vulnerability knowledge base may include a chinese National Security Information Vulnerability base (CNNVD), Common Platform Enumeration (CPE), Common Vulnerability Scoring System (CVSS), and the like.
According to the embodiment of the invention, the first component can be determined in a mode of traversing and matching at least the component to be tested and the vulnerability information disclosed in the vulnerability knowledge base. In the process of traversing and matching, all bugs which have a matching relation with the component to be tested in the bug knowledge base can be extracted to serve as bugs of the first component.
According to the embodiment of the invention, the first component has at least one vulnerability and vulnerability description information.
According to the embodiment of the invention, each vulnerability of the first component can have corresponding vulnerability description information, and the vulnerability description information can represent the error form and the existing version of the vulnerability.
For example, a first component may have three vulnerabilities: CVE-2016-100031, CVE-2016-3092 and CVE-2013-2186, wherein the CVE-2016-100031, the CVE-2016-2092 and the CVE-2013-2186 can be vulnerability numbers in a vulnerability knowledge base. The vulnerability CVE-2016 — 100031 may have the following vulnerability description information: the version of the component before 1.3.3 has an access control error vulnerability resulting from a network system or product not properly restricting access to resources from unauthorized roles; the vulnerability CVE-2016-: this component has a verification error vulnerability 1.3.2 ago that results from the network system or product not properly verifying the incoming data.
According to an embodiment of the present invention, determining the second component for replacing the first component from the component library may specifically be implemented as:
semantic analysis is carried out on the vulnerability description information to generate a semantic analysis result;
and determining a second component for simultaneously repairing at least one vulnerability from the component library according to the semantic analysis result.
According to the embodiment of the invention, the vulnerability description information can be subjected to semantic analysis by using the neural network model trained in advance to generate a semantic analysis result, but the semantic analysis result is not limited to the semantic analysis result, and related personnel can perform manual analysis to generate the semantic analysis result.
According to the embodiment of the invention, the semantic analysis is performed on the vulnerability description information to determine the version of the component in which the vulnerability corresponding to the vulnerability description information exists, that is, the semantic analysis result represents the final existing version of the vulnerability.
According to the embodiment of the invention, the first component can have a plurality of vulnerabilities, and the vulnerabilities can be repaired in components of different versions. For example, the first component may have three vulnerabilities: CVE-2016 100031, CVE-2016 3092, and CVE-2013 2186, wherein the version 1.1.4 component can be used to repair the vulnerabilities CVE-2016 100031, and the version 1.1.5 component can be used to repair vulnerabilities CVE-2016 3092 and CVE-2013 2186.
According to the embodiment of the invention, semantic analysis results of vulnerability description information of a plurality of vulnerabilities can be summarized, and a second component capable of repairing all vulnerabilities of a first component at the same time is searched from a component library.
According to the embodiment of the present invention, determining the second component for repairing at least one vulnerability simultaneously from the component library according to the semantic analysis result may specifically be implemented as:
predicting at least one candidate component according to the semantic analysis result;
searching candidate components from the component library to generate a search result;
and in the case that the retrieval result characterizes that the candidate component exists in the component warehouse, taking the candidate component as a second component.
According to the embodiment of the invention, for example, according to the semantic analysis result, the component of the 1.1.5 version is predicted to be used for repairing all bugs of the first component, so that whether the component of the 1.1.5 version exists can be searched in the component library, and if the component of the version exists, the component of the 1.1.5 version can be determined as the second component. If the component library does not have the component of the version 1.1.5, the detected first component, the bugs existing in the first component and the bug description information of each bug can be directly output, so that the user can carry out bug fixing based on the acquired information.
According to the embodiment of the invention, the vulnerability description information is used for describing the vulnerability of the first component of at least one version.
According to the embodiment of the present invention, predicting at least one candidate component according to the semantic analysis result may be specifically implemented as:
determining a candidate component by using a version number corresponding to the version number represented by the first description mode under the condition that the semantic analysis result comprises the first description mode;
and under the condition that the semantic analysis result comprises a second description mode, changing the version number represented by the first description mode, and determining the candidate component by using the changed version number.
According to the embodiment of the invention, the semantic analysis result of the first description mode can indicate the version number of the component with the repaired bug. For example, the first description manner may include that the vulnerability B of the component a has been fixed in the version 1.1.2, the vulnerability B has been fixed in the component a of the version 1.1.2, and the like.
According to the embodiment of the invention, through the semantic analysis result of the first description mode, the version in which the vulnerability is repaired can be known, so that the component version indicated by the semantic analysis result can be directly used as the version of the second component.
According to the embodiment of the invention, the semantic analysis result of the second description mode can indicate the existence version number of the vulnerability. For example, the second description may include: vulnerability B of component a exists before version 1.1.2, and vulnerability B of component a still exists until version 1.1.2.
According to the embodiment of the invention, since the semantic analysis result of the second description mode can indicate the existence version number of the vulnerability, under the condition that the semantic analysis result includes the second description mode, one or more version numbers after the version number indicated by the semantic analysis result can be determined as the version number of the second component. For example, when the semantic analysis result is that the vulnerability B of the component a exists before the version 1.1.2, it can be considered that the vulnerability B is fixed when the version 1.1.3 is reached, and it can be determined that the version number of the second component is 1.1.3.
According to the embodiment of the present invention, generating a bug-specific fix scheme according to the first component, the second component, and the compatibility change information may specifically be implemented as follows:
determining an effective position of the first component, and generating first position information;
generating a repair patch according to the first position information and the second component;
and taking the repair patch and the compatibility change information as a repair scheme.
According to the embodiment of the invention, for example, an mvn hellp instruction-effective-ppm-output-effective-xml instruction can be used to acquire all effective components in the code library, then determine a first component from all effective components, and determine first position information of the first component according to a packet path.
According to the embodiment of the invention, the repair patch generated according to the first location information and the second component can indicate the actual effective location of the second component, that is, when the repair patch is used for repairing the vulnerability, the second component can replace the first component at the location indicated by the first location information. But not limited thereto, in case that a plurality of first components are included in the code base, it is also possible to replace all the first components with the second components.
According to the embodiment of the invention, the bug fixing method further comprises the following steps:
outputting prompt information determined based on the repair scheme;
and responding to the confirmation operation initiated aiming at the prompt information, and repairing the vulnerability by utilizing the repairing scheme.
According to the embodiment of the present invention, the prompt message may be, for example, a summary of the repair solution, that is, only the information of the component with the problem and the repair method for the component, and in the embodiment of the present invention, for example, "there is a bug in the first component, it is suggested to replace the first component with the second component, please confirm! ".
According to the embodiment of the invention, the repair scheme can also be directly output to the user as prompt information. The repair scheme may include location information of the first component, vulnerability description information existing in the first component, information of the second component, compatibility influence information of the second component represented by the compatibility change information on the code base, and the like.
FIG. 2 schematically shows a schematic diagram of the repair scenario output of an embodiment of the present invention.
In some embodiments of the invention, as shown in fig. 2, the bug fix method may be performed by the server 200, and thus, the fix scheme may be generated in the server 200. On the basis, the server can query developers related to the first component and output the repair scheme to the electronic devices 201 of the related developers, so that the developers can perform vulnerability repair work on the first component based on the repair scheme.
Fig. 3 schematically shows a schematic diagram of the repair scheme output of another embodiment of the present invention.
In some embodiments of the invention, as shown in FIG. 3, the bug fix method may be performed by an electronic device 300 of a developer associated with the first component, and thus, a fix scenario may be generated in the electronic device 300. On this basis, after the processor 301 of the electronic device 300 generates the repair solution, the repair solution may be output to the display 302 of the electronic device 300, so that the developer can know the repair solution in the display 302.
Fig. 4 schematically shows a schematic diagram of a repair scheme provided by an embodiment of the invention.
As shown in fig. 4, the subject name of the repair scheme may be "upgrade a component from version 1.2 to version 1.3.3", where the version 1.2 component may be a first component that may have a bug, and the version 1.3.3 component may be a second component, and the bug that exists in the first component may be repaired by upgrading the first component to the second component.
The repair solution further includes vulnerabilities existing in the first component, such as permission permissions and access control vulnerabilities, input verification code error vulnerabilities, access control error vulnerabilities, and the like. The vulnerabilities can be repaired by upgrading the first component to the second component.
On the basis, the compatibility influence of the second component on the code base, which is indicated by the compatibility change information, is also included in the repair scheme. Specifically, the interface may be used and changed, and the result may be unused and changed.
In the embodiment of the present invention, the interface of the second component changed with respect to the first component may be a change in a definition level, for example, the a interface called by the first component may accept 3 parameters, and the a interface called by the second component may accept two parameters, but the change in the definition level does not represent certain incompatibility in program execution, the compatibility change information is used to describe a possible influence, and a developer may perform functional verification on the second component by compiling whether the second component is normal, a unit test result, an integration test result, and the like.
Through the restoration scheme, developers can visually know the existing bug restoration through which mode, and can also know the compatibility influence of the bug restoration on the code library through the compatibility change information, and the adverse influence can be eliminated through a secondary development mode for the used and changed interfaces, so that after the developers obtain the restoration scheme, the developers only need to develop some called interfaces, the compatibility of the bug restoration can be ensured, the complexity of the bug restoration is reduced, and the compatibility of the bug restoration is ensured.
According to the embodiment of the invention, the vulnerability repairing method further comprises the following steps:
acquiring a library description file of a code library;
determining a dependency relationship between components of the code library based on the library description file;
in the case that the dependency characterization first component is a component directly called by the code library, compatibility change information of the second component relative to the first component is determined.
According to the embodiment of the invention, since some vulnerabilities are not introduced by a component directly called by the code library but are introduced by other components depended by the directly called component, in this case, the dependency relationship of the first component may be determined first, that is, the dependency relationship between the components may be obtained from the library description file of the code library, for example, A, B, C, D, E, five components are in total in the code library, wherein the dependency relationship is as follows { a [ B ], B [ C, D ], E }, that is, the component a, the component B, and the component E are components directly called by the code library, wherein the component a needs to depend on the component B, and the component B needs to depend on the component C and the component D. In this example, the vulnerability may not be introduced by component A, which is called directly by the code library, but by component B, which component A depends on.
According to the embodiment of the invention, after the dependency relationship of each component of the code library is determined, whether the first component is a directly called component of the code library or not can be determined, and the compatibility change information of the second component relative to the first component is determined only under the condition that the first component is the directly called component, and if the first component is not the directly called component, the information of the first component and the vulnerability existing in the first component can be output, so that a developer can repair the vulnerability existing in the first component.
Fig. 5 schematically illustrates a schematic diagram of a vulnerability fixing method provided by an embodiment of the present invention.
As shown in fig. 5, a vulnerability knowledge base may be obtained first, and the vulnerability knowledge base may include, for example, CNNVD, CPE, CVSS, etc., and may be downloaded locally to facilitate offline vulnerability matching.
After the vulnerability knowledge base is obtained, the code base component of the project can be detected. For example, all components (purl) of the current code library may be inferred by analyzing a header file management, a library description file pom. xml, and a package path of the code library by using an OWASP Dependency-check component detection engine, and then all detected purl may be matched with a vulnerability knowledge base, so as to determine a first component purl1 where a vulnerability exists and vulnerability description information of the vulnerability from all purl, where there may be a plurality of first components.
After the first component is determined, semantic analysis can be performed on vulnerability description information of the vulnerability, version information related to the vulnerability description information is detected, and the minimum public safety version of the vulnerability is predicted according to the version information.
Xml may generate a dependency relationship of all components of the code library according to pom of the code library, determine whether the first component is a directly called component according to the dependency relationship, retrieve the candidate component from the Maven repository in the case that the first component is the directly called component, and verify whether the candidate component actually exists in the Maven repository.
In the case that the candidate component really exists in the Maven warehouse, the candidate component is taken as the second component, and the compatibility change information of the second component relative to the first component is determined according to the interface implementation information of the first component and the second component, and the compatibility change information can be obtained by, for example, mvn dep: the get instruction, the japicmp component comparison tool, and the javaparser code analysis tool make the determination.
After the compatibility change information is determined, a repair scheme for the vulnerability can be generated according to the first component, the second component and the compatibility change information, and the repair scheme is output.
Fig. 6 schematically shows a block diagram of a bug fixing device provided in an embodiment of the present invention.
As shown in fig. 6, the bug fixing device 600 may include a first component determining module 601, a second component determining module 602, a compatibility determining module 603, and a scheme generating module 604.
A first component determining module 601, configured to determine, from a code library, a first component with a vulnerability;
a second component determination module 602 for determining a second component for replacing the first component from the component library;
a compatibility determining module 603, configured to determine compatibility change information of the second component with respect to the first component according to interface implementation information of the first component and the second component;
and a scheme generating module 604, configured to generate a repair scheme for the vulnerability according to the first component, the second component, and the compatibility change information.
According to an embodiment of the present invention, the compatibility determining module 603 includes a first obtaining sub-module, a first determining sub-module, and a second determining sub-module.
The first obtaining submodule is used for obtaining first interface realization information of the first component and second interface realization information of the second component;
the first determining submodule is used for determining difference interface information of the first interface implementation information and the second interface implementation information;
and the second determining submodule is used for determining compatibility change information based on the code base and the difference interface information.
According to an embodiment of the present invention, the second determination submodule includes a syntax analysis unit, a first determination unit, and a first generation unit.
The syntax analysis unit is used for carrying out syntax analysis on the code base to generate an abstract syntax tree;
the first determining unit is used for determining interface calling information in the abstract syntax tree;
and the first generating unit is used for generating compatibility change information according to the interface calling information and the difference interface information.
According to an embodiment of the present invention, the first component determination module 601 includes a scanning sub-module and a matching sub-module.
The scanning submodule is used for scanning the code base and determining at least one component to be detected;
and the matching sub-module is used for matching the at least one component to be tested with the vulnerability knowledge base and determining the first component and the vulnerability of the first component from the at least one component to be tested.
According to the embodiment of the invention, the first component has at least one vulnerability and vulnerability description information;
according to an embodiment of the invention, the second component determination module 602 includes a semantic analysis sub-module, a second component determination sub-module.
The semantic analysis submodule is used for performing semantic analysis on the vulnerability description information to generate a semantic analysis result;
and the second component determining submodule is used for determining a second component for simultaneously repairing at least one vulnerability from the component library according to the semantic analysis result.
According to an embodiment of the present invention, the second component determination submodule includes a prediction unit, a retrieval unit, and a second component determination unit.
A prediction unit for predicting at least one candidate component based on the semantic analysis result;
the retrieval unit is used for retrieving the candidate components from the component library and generating a retrieval result;
and the second component determination unit is used for taking the candidate component as the second component if the candidate component exists in the component warehouse according to the retrieval result.
According to the embodiment of the invention, the vulnerability description information is used for describing the vulnerability of the first component of at least one version.
According to an embodiment of the present invention, the prediction unit includes a first candidate component determination subunit, a second candidate component determination subunit.
A first candidate component determination subunit, configured to determine, when the semantic analysis result includes the first description mode, a candidate component using a version number corresponding to the version number characterized by the first description mode;
and the second candidate component determining subunit is used for changing the version number represented by the first description mode under the condition that the semantic analysis result comprises a second description mode, and determining the candidate component by using the changed version number.
According to an embodiment of the present invention, the scheme generation module 604 includes a location determination unit, a patch generation unit, and a repair scheme determination unit.
The position determining unit is used for determining the effective position of the first component and generating first position information;
the patch generating unit is used for generating a repair patch according to the first position information and the second component;
and the repair scheme determining unit is used for taking the repair patch and the compatibility change information as a repair scheme.
According to an embodiment of the present invention, the vulnerability fixing apparatus 600 further includes an output module and a fixing module.
The output module is used for outputting prompt information determined based on the repair scheme;
and the repairing module is used for responding to the confirmation operation initiated aiming at the prompt message and repairing the vulnerability by utilizing the repairing scheme.
According to an embodiment of the present invention, the bug fixing apparatus 600 further includes a file obtaining module, a dependency relationship determining module, and a compatibility change information determining module.
The file acquisition module is used for acquiring a library description file of the code library;
the dependency relationship determining module is used for determining the dependency relationship among the components of the code library based on the library description file;
and the compatibility change information determining module is used for determining the compatibility change information of the second component relative to the first component under the condition that the dependency relationship represents that the first component is a component directly called by the code library.
The bug fixing device shown in fig. 6 may execute the bug fixing method shown in the embodiment shown in fig. 1, and the implementation principle and the technical effect are not described again. The specific manner in which each module, sub-module, and unit of the bug fixing device in the above embodiments perform operations has been described in detail in the embodiments related to the method, and will not be described in detail herein.
In one possible design, the vulnerability fixing apparatus in the embodiment shown in fig. 6 may be configured in a computing device, as shown in fig. 7, and the embodiment of the present application further provides a computing device, which may include a storage component and a processing component;
the storage component stores one or more computer instructions, where the one or more computer instructions are invoked by the processing component for execution, so as to implement the bug fixing method according to the embodiment shown in fig. 1.
Among other things, the processing component 702 may include one or more processors to execute computer instructions to perform all or some of the steps of the methods described above. Of course, the processing elements may also be implemented as one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), controllers, micro-controllers, microprocessors or other electronic components configured to perform the above-described methods.
Of course, a computing device may also necessarily include other components, such as input/output interfaces, communication components, and so forth.
The input/output interface provides an interface between the processing components and peripheral interface modules, which may be output devices, input devices, etc.
The communication component is configured to facilitate wired or wireless communication between the computing device and other devices, and the like.
The computing device may be a physical device or an elastic computing host provided by a cloud computing platform, and the computing device may be a cloud server, and the processing component, the storage component, and the like may be a basic server resource rented or purchased from the cloud computing platform.
An embodiment of the present invention further provides a computer-readable storage medium, in which a computer program is stored, and when the computer program is executed by a computer, the vulnerability repair method according to the embodiment shown in fig. 1 may be implemented.
It is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. One of ordinary skill in the art can understand and implement it without inventive effort.
Through the above description of the embodiments, those skilled in the art will clearly understand that each embodiment can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware. With this understanding in mind, the above-described technical solutions may be embodied in the form of a software product, which can be stored in a computer-readable storage medium such as ROM/RAM, magnetic disk, optical disk, etc., and includes instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments.
Finally, it should be noted that: the above examples are only intended to illustrate the technical solution of the present invention, but not to limit it; although the present invention has been described in detail with reference to the foregoing embodiments, it will be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and such modifications or substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present invention.
Claims (11)
1. A vulnerability fixing method is characterized by comprising the following steps:
determining a first component with a vulnerability from a code base;
determining a second component for replacing the first component from a component library;
determining compatibility change information of the second component relative to the first component according to interface implementation information of the first component and the second component;
and generating a repair scheme aiming at the vulnerability according to the first component, the second component and the compatibility change information.
2. The method of claim 1, wherein the determining compatibility change information for the second component relative to the first component comprises:
acquiring first interface implementation information of the first component and second interface implementation information of the second component;
determining difference interface information of the first interface implementation information and the second interface implementation information;
determining the compatibility change information based on the code base and the difference interface information.
3. The method of claim 2, wherein the determining the compatibility change information based on the codebase and the difference interface information comprises:
carrying out syntactic analysis on the code base to generate an abstract syntactic tree;
determining interface calling information in the abstract syntax tree;
and generating the compatibility change information according to the interface calling information and the difference interface information.
4. The method of claim 1, wherein determining from the code library that the first component has the vulnerability comprises:
scanning the code base to determine at least one component to be tested;
and matching the at least one component to be tested with a vulnerability knowledge base, and determining the first component and the vulnerability of the first component from the at least one component to be tested.
5. The method of claim 1 or 4, wherein the first component has at least one vulnerability and vulnerability description information;
said determining a second component from a library of components for replacing said first component comprises:
performing semantic analysis on the vulnerability description information to generate a semantic analysis result;
and determining the second components for simultaneously repairing the at least one vulnerability from the component library according to the semantic analysis result.
6. The method according to claim 5, wherein the determining, from the component library, the second component for repairing the at least one vulnerability at the same time according to the semantic analysis result comprises:
predicting at least one candidate component according to the semantic analysis result;
searching the candidate components from the component library to generate a search result;
in the event that the search result characterizes the presence of the candidate component in the component repository, treating the candidate component as the second component.
7. The method of claim 6, wherein the vulnerability description information is used to describe vulnerabilities of at least one version of the first component;
the predicting at least one candidate component according to the semantic analysis result comprises:
determining the candidate component by using a version number corresponding to the version number represented by the first description mode under the condition that the semantic analysis result comprises the first description mode;
and under the condition that the semantic analysis result comprises a second description mode, changing the version number represented by the first description mode, and determining the candidate component by using the changed version number.
8. The method of claim 1, wherein generating a fix for the vulnerability from the first component, the second component, and the compatibility change information comprises:
determining an effective position of the first assembly, and generating first position information;
generating a repair patch according to the first position information and the second component;
and taking the repair patch and the compatibility change information as the repair scheme.
9. The method of claim 1, further comprising:
outputting prompt information determined based on the repair scenario;
and responding to a confirmation operation initiated aiming at the prompt message, and repairing the vulnerability by utilizing the repairing scheme.
10. The method of claim 1, further comprising:
acquiring a library description file of the code library;
determining a dependency relationship between components of the code library based on the library description file;
and determining compatibility change information of the second component relative to the first component under the condition that the dependency relationship characterizes that the first component is a component directly called by the code library.
11. A computing device comprising a processing component and a storage component;
the storage component stores one or more computer instructions; the one or more computer instructions to be invoked for execution by the processing component;
the storage component stores one or more computer instructions; the one or more computer instructions to be invoked and executed by the processing component to implement the bug fix method of any of claims 1 to 10.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210126375.7A CN114611111A (en) | 2022-02-10 | 2022-02-10 | Vulnerability repair method and computing equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210126375.7A CN114611111A (en) | 2022-02-10 | 2022-02-10 | Vulnerability repair method and computing equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN114611111A true CN114611111A (en) | 2022-06-10 |
Family
ID=81859301
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210126375.7A Pending CN114611111A (en) | 2022-02-10 | 2022-02-10 | Vulnerability repair method and computing equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114611111A (en) |
-
2022
- 2022-02-10 CN CN202210126375.7A patent/CN114611111A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Muske et al. | Survey of approaches for handling static analysis alarms | |
| US11720334B2 (en) | Inductive equivalence in machine-based instruction editing | |
| US8954930B2 (en) | System and method for reducing test effort by object risk analysis | |
| CN107451474B (en) | Software bug fixing method and device for terminal | |
| CN103473506A (en) | Method and device of recognizing malicious APK files | |
| US11307975B2 (en) | Machine code analysis for identifying software defects | |
| CN109871319A (en) | Item code scan method, device, computer equipment and storage medium | |
| CN112883342A (en) | Component management and control method, device and equipment | |
| CN115391230A (en) | Test script generation method, test script penetration method, test script generation device, test penetration device, test equipment and test medium | |
| CN112419057A (en) | Method, device, equipment and storage medium for generating and storing logs of intelligent contracts | |
| US11868465B2 (en) | Binary image stack cookie protection | |
| Hao et al. | E&v: Prompting large language models to perform static analysis by pseudo-code execution and verification | |
| CN117493188A (en) | Interface testing method and device, electronic equipment and storage medium | |
| CN110990833B (en) | SDK safety detection method and related equipment | |
| CN109684205B (en) | System testing method, device, electronic equipment and storage medium | |
| CN116415258A (en) | Vulnerability detection method, device, equipment, medium and program product | |
| Cox | Our software dependency problem | |
| CN116541847A (en) | Security detection method and device for application program | |
| CN115543838A (en) | Code scanning rule processing method and device, storage medium and electronic equipment | |
| CN114611111A (en) | Vulnerability repair method and computing equipment | |
| CN113568834A (en) | SDK code compatibility detection method, device, computer equipment and medium | |
| Xiao et al. | Performing high efficiency source code static analysis with intelligent extensions | |
| WO2020121075A1 (en) | System and method for quality assessment of a product | |
| CN111428238A (en) | Android component-based denial of service test method, detection terminal and medium | |
| CN117234765B (en) | Automatic binary positioning method for kernel performance degradation patch of domestic operating system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |